Plan Information - Project Manager Settings

General Information

Display Plan As – Use this field to display a plan with a name different than the type of plan it is. For example, community has a plan that is a declining dollar plan from FullCount’s perspective, but they want to call it points for the resident’s sake. This is most commonly used to mask declining dollar plans. To utilize this field, type the name you want to mask with. In the example given, type points.

Issue Credit – This is rarely used. This field is used in conjunction with a CREDIT_INFORMATION table in the database. The issue credit option is used when a community gives a credit for a resident to eat in another dining room.  For example, a HC resident can eat in the IL dining room. If they do, they get up to a certain amount of money to spend in the venue for their meal. The system charges them for the food and then creates a credit equal to the amount they get ‘for free’. Any food in the IL dining room goes to the charge account, but the credit covers all or a portion of the cost of what they eat. If they then go and eat in their HC dining room, then they lose the credit.

Use Plan Information for Issue Credit – This is only used if Issue Credit is set to Yes. This specifies whether the system should only create credits for things that are allowanceable under the plan. This will be used even rarer than Issue Credit. This allows us to meet the need to specifying what items can have a credit issued for them.

Report Message – This is rarely used. If the community wants to provide a message on the Plan Utilization Detail report, they can use the Report Message field to do so. The only implementation of this was a community that wanted to put a note on the report that states residents can only carry over 5 meals. However, this could be used for any other static message that the community wanted to put on their Plan Utilization Detail reports on a continual basis.

Order by Clause – For the month end close, the system automatically sorts transactions by date to process. This means that their overage is made of the last items consumed. If there should be a different sort order to how the meals are processed (least expensive counted first, most expensive counted first, residents counted first, etc.), the order by clause should be used to sort the transactions in the order they should be processed. If the residents get billed for their least expensive items, then chronologically, the value of the field would be TAXED_AMOUNT DESC, TRANSACTION_DATE. Common examples include:

Add On Value – This is rarely used.  If the community has a plan that is X per Day/Period + Y, the add-on value is used to add the plus Y. For example, a community may offer 1 meal per day plus 15 meals. The plan would be set up as a 1 meal per day/period plan and the add-on value would be 15. The add-on value will always be on the same type (dollars, meals, etc.).

Rounding Bit – This is rarely used. The rounding bit can be used when a plan needs to be rounded to a decimal place other than the default. The only common use for this would be if a community is using a points plan that typically rounds to two decimal places, but the community wants to have rounded to a whole number. In this case, the rounding bit would be 0.

Prorate Plan – This is rarely used. If the community has a meal plan that they do not want prorated based on the resident’s start date, this flag should be set to No. In its only implementation, a community offers 12 free deliveries per year, regardless of when the resident moves in. This setting overrides any proration based on account or customer information and gives the full value of the plan.

Overage Multiplier - This is rarely used. This is used if a community wants to charge a percentage on top of the amount of an overage. The only implementation of this is a community that wants to charge 1.03 for each dollar is over on their meal plan. Please consult a developer before using this feature.

First Cycle Start Date - This is rarely used. This is used if a community has a yearly or quarterly plan and does not want to use the preconfigured periods (January - March, April - June, July - September, October - December / January - December). This is also used for weekly plans. The first cycle start date is the date of the first period. All subsequent periods will be created by the system.

Accrue Allowance -  This is rarely used. This specifies if the allowance for the plan should be available at the start of the period or accrue each day throughout the period. Typically, communities will want their allowance to be available at the start of the period, which is the default. Some communities might want the allowance to accrue each day throughout the the period and be added to the previous days balance within the period. If that is the case, the value should be set to each day of period.

Period Duration Value - This is only used to the Plan Type is dollars per N months. This specifies what the N value is on a dollars per N months plan. For example, if a plan is every 4 months, the value would be 4. When that plan type is selected, this value is required.

Carryover

Carryover – Specifies whether a community allows carryover. Carryover allows communities to have their residents to ‘carry over‘ their unused allowance to the next month. For example, a community might have a $100 carryover rule. If the resident has a remaining balance at the end of the month, they get to ‘carry over’ up to $100 to use in the next month. If the community has a $200 monthly allowance and the resident had the max carryover, the resident would have a $300 allowance.

Prepaid Carryover – Specifies whether a community allows customers to pre-pay a carryover value. This feature allows customers to put extra money on their account which will automatically get used if they go over their allowance. There is no expiration on the value added. The adding of value to prepaid carryover is similar to adding funds for prepaid accounts.

Max Carryover – This is only used if Carryover is set to Yes. The amount of carryover allowed per person. If the community allows unlimited carryover, leave the field blank. The system will automatically multiply the maximum carryover by the number of people on the account.

Max Carryover To Be Added Per Period - This is only used if Carryover is set to Yes. The maximum amount that can be added to the current account carryover per person. If the community allows does not limit carryover by period, leave the field blank. This is used in conjuction with Max Carryover to determine the amount of carryover assigned to an account. The system will automatically multiply the maximum carryover by the number of people on the account. For example, a community may have unlimited carryover, but want to limit the amount that can be added each month to $100 so that the resident does not build carryover too quickly and encourage the residents to spent at least some of their declining dollar balance each month. The Max Carryover to Be Added Per Period would be set to 100 and Max Carryover would be blank in this case.

Carryover Duration – This is only used if Carryover or Prepaid Carryover is set to Yes. This field represents how often the carryover is rolled over/reset. The majority of the time this will be monthly. The only iteration of yearly is for a community on a dollars per year plan and the residents get to carryover a value at the end of the year. The only iteration of the quarterly carryover is a community where carryover rolls over every month, but is reset once a quarter.

First Carryover Start Date – This is only used for quarterly/yearly carryover. This specifies the start of the quarters for quarterly carryover plans.- t

Display Carryover As - This specifies what will display as the label for carryover on the touchscreen and reports. Default value is Carryover.

Display Prepaid Carryover As - This is only used if Prepaid Carryover is set to Yes. This specifies what will display as the label for prepaid carryover on the touchscreen and reports. Default value is Prepaid Carryover.

Prepaid Carryover Reset - This is only used if Prepaid Carryover is set to Yes. This specifies that any prepaid carryover will be set to zero at the end of the period.

Assign Balance as Carryover to Plan - This is rarely used. This allows the balance of a plan to be assigned as carryover for the next period to another plan.

Carryover Multiplier - This is rarely used. This allows a community to have the carryover value assigned to customers during the month end close to be a percentage of the customer’s remaining balance. For example, a community may only want to give users 50% of their remaining balance in carryover to encourage usage of the use of the balance during the month and lessen the amount they would owe customers in the future. The carryover multiplier would be set to .5 to implement this request.

Declining Dollar

Create Allowance Transaction – For declining dollar balance plans, some communities will choose to bill all the transactions and then have the system create a credit equal to the amount of the plan utilized (if plan is underutilized) or the allowance of the plan (if the plan is over utilized). For example, the community has a $200 plan. Mrs. Smith consumes $150. The system would bill all her transactions and then create a credit equal to $150 (her utilization of the plan). Therefore, the total amount billed would be $0. Mr. Jones consumes $250. The system would bill all his transactions then create a credit equal to $200 (max amount covered by plan). Therefore, the total amount billed would be $50. This is typically used when the community is attempting to budget by different accounting buckets (resident, guest, alcohol, etc.) and don’t want the handful of transactions in actual overage to affect their budget numbers.

Credit Department – This is only used if Create Allowance Transaction or Meal Minimum is set to Yes. This is the department to be used for the allowance transaction.

Credit Customer Type – This is only used if Create Allowance Transaction or Meal Minimum is set to Yes. This is the customer type to be used for the allowance transaction.

Credit Item– This is only used if Create Allowance Transaction or Meal Minimum is set to Yes. This is the item to be used for the allowance transaction.

Meal Minimum – This is rarely used. Some communities do not offer a traditional declining dollar plan. Instead they offer a plan where the resident has to spend a certain amount of money in their dining venues. If the residents fail to eat the minimum amount required, they are billed for the difference. For example, a community requires residents to spend at least $50 in the dining room. Mrs. Smith spends $45 in the dining room. The system will bill all her transactions and will also create a transaction of $5 to meet the $50 minimum. Mr. Jones spends $55 in the dining room. The system will bill all his transactions, but will not create any additional transactions because he has met the minimum.

Overages Allowed - For declining dollar plans, state whether the plan can go into a state of overage on the touchscreen. If this value is set to No, the touchscreen application will not allow users to go into a state of overage on their account and will force the customer to pay for anything not covered with an additional form of payment. This setting will appropriately split any non-covered transactions onto a separate check to be close separately.

Daily Maximum -  This is rarely used, currently built for Tandem Living.  For declining dollar plans, state whether the maximum dollar amount that can be applied to the plan on a given date. Anything over this amount will go to a state of overage to be billed at the end of the period.

Maximum Overage -  This is rarely used, currently built for Tandem Living. For declining dollar plans, state the maximum amount the plan can go into a state of overage on the touchscreen. When the customer has reached this maximum overage, the system will appropriately split any non-covered transactions onto a separate check to be close separately.

Meal/Points

Bill Me Later – This is used when the community offers a resident the choice of being billed ala carte or using a meal. The system will prompt the user at closing to either choose to use a meal or to have the resident be billed ala carte. For example, a resident can come to the dining room for lunch and just orders a cup of soup. Rather than using one of their meals for the month at lunch, the resident elects to have the cup of soup be forced to their charge account so they can use the meal at some other point during the period. This option should be used with caution since a resident has the ability to choose ‘wrong’. They could decide to be billed for the cup of soup and then never fully utilize their meal plan. If this is the case, the system is still going to bill the resident for the cup of soup since this is what they elected to do.

Bill Me Later Text –This is only used with Bill Me Later is set to Yes. This is the text that will appear in the button for the user to choose from when closing the order. Ala Carte or Force to Charge Account would be common examples of what might be in this field.

Auto Bill Me Later - This is only used with Bill Me Later is set to Yes. This setting will automatically send any transactions to be forced to the charge account when the resident is over their meal plan. Mrs. Smith has already fully utilized her meal plan and comes in for a sandwich and bag of chips. With this setting, Mrs. Smith will automatically be charged for the sandwich and bag of chips at an ala carte price since she has utilized her meal plan. Use caution with this method of billing because if transactions are removed from the back office that give them a remaining balance after this auto bill me later is already in effect, a resident may have transactions that were forced to the charge account that shouldn’t be.

Price on Auto-Generated Item – This is rarely changed. This setting determines whether transactions created via Close Check Config should have the price automatically assigned to it. If the system creates a lunch transaction at the close of the order, the system will automatically put the price of lunch on the transaction created. By default this is set to Yes and should remain this way. This setting is in place from some old legacy plans and should not be set to No for any new implementations.

Partial Points Allowed – This is rarely used. This setting is set to Yes by default and should remain this way. There is one community where this is set to No. For this community’s set-up, if a resident has less remaining points than the amount of points on the transaction, they are billed for the whole transaction during the month end close. For example, resident has a 1 point balance remaining. The next transaction processed by the month end close is 3 points. Since the 1 point remaining does not cover the transaction’s 3 points, the resident will be billed for the whole transaction. Typically, in these types of scenarios, the community would have the resident be billed for 2/3 of the amount since they did have 1 point to cover part of the meal. However, in the community mentioned above, residents are required to have a balance that covers the whole transaction.

Subtract Discount From Amount - During the month end close, use the discount amount to subtract from the transaction amount. For example, the community wants to give residents a set dollar discount for any guest meals that are consumed within the meal plan where the price of the guest meal varies. Mrs. Smith can use her meal plan to pay for guest meals in the café up to $10 dollars. Anything over $10 is an additional charge, in addition to using one of her meals. Her meal plan is set up to ‘roll up’ transactions (via Meal Creation Config) in the café to the dollar amount consumed and she has one guest consume $15 worth of food. The system would count one meal utilized and also charge her $5 ($15 of food consumed minus the $10 allowed). This discount amount is set on the item level and turned on at a community/item type/customer type level.

Meal Discount Allowed – This is rarely used. It is currently only being utilized by one community. During month end close, the system will give a discount on all meals when the allowance number has been reached. For this community, they give a $.50 discount on all meals if at least 20 meals have been consumed for period. The allowance for this meal plan is set to 20 and this flag to set to Yes.

Meal Discount Amount – This is only used when Meal Discount Amount is set to Yes. This is the amount of the discount applied to all meals if the allowance is met. In the example mentioned above, the value of this field would be .50.

Bill Until Allowance - This is rarely used. This setting changes the billing so that all items are billed until the allowance is reached and then all items are free. This is currently used for a community where residents pay for X number of tray services if they use them. Once X is reached, any additional tray services are free.

Overage Replacement Item - This is rarely used. This setting allows overage items to be changed to a different item. This would be used when a community has multiple meal plans (one meal/points and one declining dollar) and the overages on the meal plan can be covered by the declining dollar plan. This allows an overage item to be changed to an item with an item type that is allowanceable under a different meal plan.

Guest Meals

Guest Meals Separate – This setting is used when a community allows residents to use a certain portion of their meal plan for guest meals. For example, a resident receives 1 Meal Per Day/Period and can use 4 of those meals for guest meals. If there are more than 4 guest meals, the system will bill those as overages during the month end close. This must be used with Separate Guest Meals Value. Please note that if the plan associated with this setting is a declining dollar plan, the system will force to charge account any guest transactions over the allowance instead of billing via the month end close.

Separate Guest Meals Value – This is only used when Guest Meals Separate is set to Yes. This is the number of guest meals allowed. In the example above, the value of this field would be 4.

Guest Meal Duration - This is only used when Guest Meals Separate is set to Yes and Plan Type is not declining dollar. This setting specifies the period in which the guest meals must be used. This is typically set to Month and coincides with the period of the meal plan. There is only one community where this is set to Daily or Day–Hour. At this community, the community allows resident to bring in X number of guests per day or per meal. Anything beyond this automatically goes to the resident’s charge account. When this field is set to Month, the overages are billed as part of the month end close.

Guest Meal Days Not Allowed - This is only used when Guest Meals Separate is set to Yesand Plan Type is not declining dollar. This setting specifies a number of days at the end of the period when a resident cannot use their remaining meals for guest meals. This is typically left blank. The logic behind this is that the community wants to avoid an end of the month rush of guest meals by specifying that residents can’t bring in for the last X days of the month. This is only utilized in one community. For this community, they do not allow residents to bring in guests for the last 4 days of their meal plan and have it count towards their allowance. Any guests brought in during the last 4 days of their meal plan have them billed automatically to them.

Show Guest Balance on Receipts - This is only used when Guest Meals Separate is set to Yes. The setting determines whether the guest balance information should be shown on receipts.

Subset Limit

Subset Limit – This setting is used when a community allows residents to use a certain portion of their declining dollar plan for specific item type/customer type combinations. For example, a resident receives 500 dollars per month and can use 50 of those dollars for salon charges. If there are more than 50 dollars in salon charges, the system will bill those as overages during the month end close. This must be used with the subset limit fields below.

Subset Limit Name  – This is only used when Subset Limit is set to Yes. This is the name of the subset limit plan.

Subset Limit Value  – This is only used when Subset Limit is set to Yes. This is the maximum value allowed by the subset limit plan. In the example above, the value of this field would be 50

Subset Limit Prorate  – This is only used when Subset Limit is set to Yes. If the community has a meal plan that they do not want prorated based on the resident’s start date, this flag should be set to No.

Show Subset Limit Balance on Receipts - This is only used when Subset Limit is set to Yes. The setting determines whether the subset limit balance information should be shown on receipts.

Show Subset Limit on Receipts - This is only used when Subset Limit is set to Yes. The setting determines whether the subset limit allowance an information should be shown on receipts.

Carryover Unused Limit  – This is only used when Subset Limit is set to Yes. Specifies whether a community allows carryover on the subset limit. Carryover allows communities to have their residents to ‘carry over‘ their unused allowance to the next month. For example, a community might have a $100 carryover rule. If the resident has a remaining balance at the end of the month, they get to ‘carry over’ up to $100 to use in the next month. If the community has a $200 monthly allowance and the resident had the max carryover, the resident will have a $300 allowance.

Subset Limit Display Carryover As - This is only used when Carryover Unused Limit is set to Yes. This specifies what will display as the label for subset limit carryover on the touchscreen and reports. Default value is Carryover.

Subset Limit Max Carryover – This is only used if Carryover Unused Limit is set to Yes. The amount of carryover allowed per person. If the community allows unlimited carryover on the subset limit, leave the field blank. The system will automatically multiply the maximum carryover by the number of people on the account.

Application for Subset Limit (on Plan Information) - This is only used when Subset Limit is set to Yes. This specifies whether the item type – customer type combination is applicable for the subset limit.

Pre-Paid Accounts

Bill Prepaid Accounts – For prepaid accounts, state whether overages should be billed as part of the month end close. Some communities allow residents to go into negative territory and allow the residents to ‘catch up’ after the fact. If this is the case, the field should be set to No and the month end close will ignore the overage. Other communities do not allow residents to play catch up and want anything over utilized to be billed as part of the month end close. In this case, the field should be set to Yes.+

Note: If value can be added to a pre-paid account via the touchscreen, then the Prepaid Account Item should be populated on the Communities page.

HL7 Integration

HL7 Query – This is only to be utilized if a community has ADT integration.  The HL7 query field specifies the conditions in which a resident created through ADT would be set up with this plan. This would be the value of a where clause. For example, if any resident who has a last name starting with A – H would have this meal plan, the value of the field would be LAST_NAME >= ‘A’ and LAST_NAME < ‘I’.

Share Meal Plan - This is only to be utilized if a community has ADT integration and has a value in HL7 Query. This field whether residents who qualify for the meal plan via the HL7 query should share this meal plan with a spouse. The qualification for spouse is someone who shares the same apartment as the resident being processed.

End Date Shared Accounts On Customer Discharge - This is only to be utilized if a community has ADT integration. This field determines whether shared accounts with this plan should be end dated when one of the customers on this plan is end dated. When the field is set to Yes, the system will end date the shared account and create a new account for the non-end dated customer on the account. When the field is set to No, the system will not put an effective end date on the shared account.

Sales Tax

Create Sales Tax Transaction – This is rarely used. This setting will have the system generate a separate sales tax transaction as part of the month end close. This is used if the community doesn’t want to have tax on transactions during the transaction creation, but wants sales tax to be created on any transactions billed during the month end close. For example, Mrs. Smith has over utilized her meal plan by $5 and the community wants to charge tax of 10% on the $5. The system will create a transaction of $0.50 for the sales tax owed. This setting should be used with caution because it can be confusing to residents who have receipts which state a pre-tax amount, but receive a bill including sales tax.

Sales Tax Item – This is only used when Create Sales Tax Transaction is set to Yes. This is the item for the sales tax transaction created.

Sales Tax Department – This is only used when Create Sales Tax Transaction is set to Yes. This is the department for the sales tax transaction created.

Sales Tax Customer Type – This is only used when Create Sales Tax Transaction is set to Yes. This is the customer type for the sales tax transaction created.

Sales Tax Rate – This is only used when Create Sales Tax Transaction is set to Yes. This is the tax rate that should be applied to the sales tax transaction created. This will typically be a system use only tax rate.

Sales Tax Reversal Item – This is only used when Create Sales Tax Transaction is set to Carryover Only (Declining Dollar Plans). This is the item for the sales tax reversal transaction created to offset the balance.

Custom Defined Fields

Display Balance When – This will determine if a balance custom field is applicable for this plan. It can set balance custom fields to be displayed always, never, overage only, or within X of balance.

Display Balance Value – This is only used when Display Balance When is Within X of Balance. This is the X value for within X of balance. This is the number that will be used to compare to the plan's balance for whether a balance custom field is appliable.

Close Check Config

This table is used to set up auto-generated items at close per mode. For example, the community wants to charge residents a meal at the close of the order, if they order items that are allowanceable. The community might have several different modes to cover different types of meals. For example, a lunch mode might create a lunch transaction upon close. This table is typically used when auto-generating an accounting item at the start of the order is not applicable. This might be because guest meals are ala carte, employees use the same mode for meals, only certain types of items should generate a meal (alcohol only order should not count as lunch), etc. The system will create one transaction for each seat on the check being closed.

Mode – This is the touchscreen mode where these setting should be utilized.

Item – This is the item that should be auto-generated.

Auto Create – This is only applicable if Bill Me Later is set to Yes. The system will ignore the Bill Me Later setting as an option and automatically create the meal transaction. For example, the community wants to give the user an option of ala carte for every meal except Sunday Brunch. For Sunday Brunch, the user has to use one of their meals and/or the community does not want to slow down meal service by asking each resident who checks in for Sunday Brunch if they want to use a meal.  For the Sunday Brunch mode, this field would be set to Yes. For all other modes for this community (Lunch, Dinner, etc.), this setting would be set to No, which would prompt the user to choose.

Use Guest Meals Days Not Allowed – This is only applicable if Guest Meal Days Not Allowed is set to Yes. If guest meal days not allowed is set to Yes for the plan, this setting can override this setting to No for a particular mode. For example, a resident cannot use one of their 4 guest meals on holidays. Therefore, a Holiday Meal mode would have this value set to No, which would force any guest meals rung up during this mode to be charged regardless of how many days are remaining in the period.

Minimum Balance to Display Item - This is only applicable if Additionally Use These Plans for Close Check Config is populated. This setting determines if an item should display for Close Check Config based on the balance of the plan. For example, if a balance of 1 meal is required to be used later on in the day, a lunch mode might have the value set to 1 to stop a user from using a lunch meal since one is required for dinner.

Additionally Use These Plans for Close Check Config is populated

This table is used only in conjuction with Close Check Config. This is used to handle cases where items that are applicable for different plans should be available at the close of a check. The system will look at any rows in Close Check Config for the parent plan and any rows in Close Check Config for the child plans specified to give a list of items to the user that are available to be closed to. The rows in the child plan rows will override the rows in the parent for the same mode if a balance is still available for the child plan.

Plan - This is the plan that should be checked for addtional close check config rows.

Meal Creation Config

This table is used to set up plans where the food items on a seat roll-up to a single transaction. This can be used for several reasons.  For each seat on a check, this setting sets the amount on all allowanceable transactions to be zero and create a new transaction representing either a maximum amount or value of the food items being rolled up.

One reason is that the community has a maximum charge per meal on a declining dollar plan. For example, a resident can eat any amount of food in the dining room and be charged a maximum of $10. If they consume less than $10, they are charged the value of the food consumed. Mrs. Smith consumes $15 worth of food for lunch. The maximum amount she can be charged is $10 per meal. The system will zero out the amount on all the allowanceable transactions being rolled up (sandwich, chips, desserts, etc.) and then create a ‘meal’ transaction with a value of $10. Mr. Jones consumes $7 worth of food for lunch. The maximum amount he can be charged is $10 per meal. The system will zero out the amount on all the allowanceable transactions being rolled up (sandwich) and then create a ‘meal’ transaction with a value of $7, since it is less than the maximum.  The ‘meal’ transaction item would have a price set to $10.

Another reason might be if there is a set price for resident meals that utilize a maximum, but guest meals are charged at an ala carte rate. The ‘meal’ item used for roll-up would have a price of $10 for residents and a price of $10000 or some other large amount for guests. The system will use the price per customer type to set what the maximum should be. This would allow any overages of resident meals to be charged at $10 or less and any overages of guest meals to be equal to the ala carte value of the items consumed.

Mode – This is the touchscreen mode where these setting should be utilized.

Description – This is the item that should be auto-generated. This price per customer type of the item will determine the maximum amount allowed on the transaction.

Applicable for Meal Creation Config - This setting is located under Plan Information. This allows control over what allowanceable item type - customer type configurations can be rolled up into a meal transaction. This might be used when an item type is allowanceable, but it should be charged separate than the cost of a meal. By default, the value of the field is set to Yes and will very rarely be set to No.

Credit Information

This table is used to issue credits to residents on this meal plan. This is used in situations where the community does not cover meals in a different venue, but residents can spend up to X dollars if they choose to dine there. The items in the other venues are typically non-allowanceable, as is the credit. The credit can also be set up so if the resident eats in their typical venues for the same time period, they do not qualify for the credit.

For example, AL residents can eat in IL venues and can receive up to 5 dollars for breakfast, 7 dollars for lunch, or 9 dollars for dinner to spend.  If a resident has already eaten breakfast in the AL dining room, but then purchases breakfast at the IL dining room, they do not receive the credit. If a resident receives a credit in an IL dining venue, but then eats their meal in the AL dining room, the credit is reversed.

Start Time – This is the start time for the meal period to be checked

End Time – This is the end time for the meal period to be checked

Department Logged Into – The resident must have an order in this department to be eligible for the credit. This is typically an IL dining venue.

Item to Create – This is the credit or reversal item to be created.

Max Amount – This is the max amount of the credit or reversal to be created.

Item to Check For – This is the item that would force a reversal or stop a credit from being created initially. This is typically an accounting item.

Department to Check – This is the department where the Item To Check For was created. This is typically an AL/HC dining venue.

Overage Replacement Items

This is rarely used. This setting allows overage items to be changed to a different item. This would be used when a community has multiple meal plans (one meal/points and one declining dollar) and the overages on the meal plan can be covered by the declining dollar plan. This allows an overage item to be changed to an item with an item type that is allowanceable under a different meal plan.

Item – This is the item that should be auto-generated. This price per customer type of the item will determine the price on the order item.

Mode – This is the touchscreen mode where this setting should be utilized.

Discount Amount

Discount amount is utilized when a community wants to charge a minimum for an item and also use one of the resident's meals. This is only used for meals/points plans. During the month end close, if the resident is still within their allowance, the system will use the discount amount to be billed. For example, the community wants to charge residents a set dollar amount for any guest meals that are consumed within the meal plan. Mrs. Smith can use her meal plan to pay for guest meals, but is charged $5 for any guests that she has. When the month end close encounters one of these meals, the system would count one meal utilized and also charge her $5 (discount amount). This discount amount is set on the item level and turned on at a community/item type/customer type level. This can be used in conjunction with Subtract Discount From Amount, which uses the discount amount in a slightly different way as documented above.

To turn on discount amount

1. On Communities, under Billing, set Discount Amount Allowed to Yes.
2. Under Customer Types and Item Types, set which ones the discount is allowed for. This is typically for the Guest customer types and Accounting Item item type.
3. On the items that should charge the discount amount, set the discount amount on the appropriate price rows. Any item that should not charge a discount amount should have the value set to 0. For example, a LUNCH item might have a discount amount set the following way: Resident - 0, Guest - 5, Employee - 0.