OPERA's Generates feature automatically calculates additional charges such as taxes that are added to a guest's bill when a particular transaction code is selected for a posting. For example, a room charge might always generate a room tax charge. The room tax charge may be set up as a percentage of the room charge; as a specific flat amount that is posted each time the room charge is posted; as a user-defined formula; or as a "tax type" which is controlled by several variables that determine if and how the generate will be applied.
You can specify generates for individual transaction codes, all transaction codes within a transaction subgroup, or all transaction codes within a transaction group. When assigning a generate to a group or subgroup, the generate will always post to each transaction code within that group or subgroup.
If any generates are already configured for the current group/subgroup/transaction code, they will be shown here. The following information fields are available.
Note: During an OPERA upgrade, if there is an existing configuration where a transaction code has a generate configured with the same transaction code, OPERA will allow the user to edit and view the generate, but they will not be able to change anything until they select a different transaction code.
Subtotal Buckets. Subtotal buckets hold amounts during the computation of generates. You may designate one or more of the subtotal buckets (S1, S2, and/or S3) to hold the transaction amount on which the generates are based (called the base transaction) by selecting the 1, 2, and/or 3 check box at the top of the screen. When the base transaction amount is stored in a subtotal bucket in this way, it is available throughout generate computation. (The description of the base transaction is shown in the text line to the left of the check boxes.)
This feature allows you to create generates that are based on a previous generate. For example, assume that the property applies separate taxes of 5% (bed tax) and 7% (state tax) on the room revenue. They also levy a 3% power surcharge on the room revenue, and the power surcharge is itself subject to the 5% and 7% taxes. The base amount can be stored in S1 at the start of the calculations. The bed tax, state tax, and power surcharge can be computed and added to the base transaction amount in S1. The power surcharge can also be placed in S2, and the bed tax and state tax can be computed again using the S2 value. To get the total amount, the amount in S1 is added to the bed tax and the state tax applied to the power surcharge. See Show Me, below, for a demonstration.
Code. The transaction code that has been selected for the generate.
Description. The generate transaction code description.
Rule. How the generate is to be applied: Percentage, Amount, Tax Type or User Defined Formula (UDF). One of these options is selected when the generate is set up. (See Create or Edit a Generate, below, for details.)
Level. The level at which the generate is to be applied: Group, Subgroup, or Transaction Code. If the level is Group or Subgroup, the generate is applied to all transaction codes in the group or subgroup. For example, a generate applied to the F&B group would be calculated for all postings using a transaction code in the F&B group, regardless of the subgroup or the specific individual transaction code. If the level is Transaction Code, the generate is applied only to the specific transaction code.
Inactive. An X in this column indicates that the transaction code assigned to this generate (shown in the Code column) has been set to Inactive on the Transaction Code - Edit screen.
Note: A generate transaction code cannot be made inactive if the generate is attached to a main (posting) transaction code. In the event there is a transaction code with inactive generates attached (this is a possibility if the generate was inactivated prior to the restriction made in V5.0.01.04), such generates will not be posted when the main transaction code is posted.
To edit an existing generate, highlight your choice and select the Edit button. To create a new generate, select the New button. Depending on the function button you select, the Generates>New screen or the Generates>Edit screen appears. (See Create or Edit a Generate, below, for details.)
Once a generate is set up, you may check the calculations it performs by highlighting your choice and selecting the Test button. (See Test and Calculate, below, for details.)
When you select the New or Edit button from the Generates screen, the Generates - New screen or the Generates - Edit screen appears, depending on your choice.
You may add as many generates to a transaction code, transaction group, or transaction subgroup as necessary. Furthermore, you can use the result of one generate calculation as a factor when calculating subsequent generates. For example, you would need to do this if you wished to calculate an occupancy tax that is based on the total that results from the posted charge plus a city tax. In this situation, the total posted amount resulting from the addition of the city tax can be stored in a "bucket" as a subtotal for calculation of the occupancy tax. If you plan to use subtotals in this way, the order in which you create generates will be important in order to ensure subtotals from one generate calculation are available for the next calculation.
Three subtotal "buckets" are available: Subtotal 1, Subtotal 2, and Subtotal 3. To store the result of a generate calculation in one of these buckets for use in a later generate calculation, select the appropriate Subtotal check box. The value of a specific Subtotal bucket will be cumulative if following generate calculations also store their results in the same Subtotal bucket. The base amount of the posting is held in each bucket that has been flagged to include the transaction amount. If the bucket has not been flagged to include the transaction amount, the starting amount of that bucket is zero.
You can always know what value is in a given bucket by using the Test Generated Transaction Codes screen. (See Test and Calculate, below, for details.) The "W" (OPERA thin client) or the diamond symbol (OPERA fat client) appears next to a Subtotal amount that is updated by a given generate.
Provide the following information on this screen.
Transaction Code. Select the down arrow to display the List of Transaction Codes. From the list, choose the transaction code for this generate. When you have made your selection, the description for that code appears to the right of the field. The transaction code that you are adding the generates to, will not be available for selection in the list of values.
The radio buttons allow you to select the rule for this generate. The rule determines how the generate is applied.
Tax Type. Use the tax types defined on the Transaction Code Tax Types screen to calculate the amount to be charged to the guest. Select the ellipsis button to configure tax types for this generate.
Note: Set the Cashiering application function TAX TYPES to Y to activate the Tax Types feature.
Note: For inclusive generates (generates that are included in the posted amount for the transaction code) OPERA can calculate and internally store up to 12 decimal places. Whether OPERA stores the Full Decimals or the number of decimals configured for the Property (see Property Configuration for details), depends on the Cashiering>Decimal Calculation application setting. Because using Full Decimals can result in apparent discrepancies in tax amounts on the folio, the Full Decimal setting can only be selected if Cashiering>Deferred Taxes is set to Y. This way, tax amounts are not calculated until the time the guest checks out.
Note: The amount entered here is not carried over as a default amount when manually posting directly to the generate transaction code on the Transaction Posting screen.
In Subtotal 1, In Subtotal 2, In Subtotal 3. Select one or more check boxes to store the results of a calculation in a "bucket" for use by a subsequent generate calculation. The value of a specific Subtotal bucket will be cumulative if following generate calculations also store their results in the same Subtotal bucket. The base amount of the posting is held in each bucket that has been flagged to include the transaction amount. If the bucket has not been flagged to include the transaction amount, the starting amount of that bucket is zero.
You can always know what value is in a given bucket by using the Test Generated Transaction Codes screen. (See Test and Calculate, below, for details.) Unless a generate subtotal is explicitly stored in a Subtotal bucket, the base value (that is, the original amount posted) is stored in a bucket by default.
Select Test from the Generates screen to test your current generate setup. The Test Generated Transaction Codes screen appears. This screen allows you to "post" a hypothetical charge to the transaction code to which the generates apply, along with any other pertinent information (such as a tax type, balance, and room type), and see the generates that result from the configuration.
Provide the following information, as appropriate, and select the Calculate button. The results of the calculation will appear in the grid, and the Total Posted Amount will display beneath the grid.
Transaction Code. The transaction code with which the generates you wish to test are associated. By default, the transaction code for which you are creating or editing generates appears here, but you may select the down arrow and choose a different transaction code to test its generates.
Amount to Post. Enter the base amount of the test posting. The number of decimals that can be entered is based on the number of decimal places that are configured for the property. Entering more than the configured decimal places will generate a message stating that the value needs to be entered in the correct format.
Tax Type. If the generate is a tax type generate, enter the tax type code in this field.
Balance. If the generate calculation is based on the guest balance (as may be the case for user defined function generates), enter a balance in this field. For example, to test the generates for a room
Room. Type. If the generate calculation is based on room type (as may be the case for user defined function generates) select the down arrow to choose a room type.
The grid shows the following information for each generate attached to the transaction code, group, or subgroup.
No. The order in which the charges will be posted. The base posting will always be 0 (zero). This is followed by the generates associated with the transaction code, in the order in which you created them.
Group. The transaction group if the generates are based on the group.
Subgroup. The transaction subgroup if the generates are base on the subgroup.
Transaction Code. The transaction code if the generates are based on the transaction code.
Transaction Code Description. The description of the transaction code that will be posted.
Amount. The amount that will be posted for the transaction. The number of decimals that are displayed is based on the number of decimal places that are configured for the property.
Formula. The formula that is used to calculate the generate (for example, Amount, Percentage, etc.).
S1-S3. The amount that would be stored in the Subtotal 1-3 buckets following posting of the generate. The base amount of the posting is held in each bucket by default until it is overwritten by a calculated amount. The "W" (OPERA thin client) or the diamond symbol (OPERA fat client) appears next to a Subtotal amount that is updated by a given generate.
Total Posted Amount. The full amount that would be posted (total of the posted amount plus all applicable generates). The number of decimals that are displayed is based on the number of decimal places that are configured for the property.
Total Base / Transaction amount -> 50.00
Inclusive Tax 1 -> 2.67
Inclusive Tax 2 -> 2.89
Net Amount -> 44.44
For the example above, OPERA calculates the amounts like this:
1. 50.00 (Tax1 6.0%, Tax2 6.5%)
2. 50.00/1.125 (add 6.0% + 6.5% =>12.5%; to get the inclusive amount, divide by 1.125) = 44.44444444 (base amount)
3. (44.44444444 * 1.06) - 44.44444444 => 2.666666666667
4. (44.44444444 * 1.065) - 44.44444444 => 2.888888888889
5. 44.44444444 + 2.666666666667 + 2.888888888889 => 50.00
OPERA provides properties with the ability to stop posting generates (taxes) for End of Day Process postings after a specific period for promotional reasons or long night stay reasons. This functionality applies to postings made through the End of Day posting process (including Room and Tax Postings, Fixed Charges).
When an adjustment is made for generates based on the Do Not Post After setting, OPERA uses the adjustment transaction code associated with the generate transaction code. If there is no adjustment transaction code, the main transaction code is used. As tax types are used to determine the tax generates of each posting, the changing of a guest tax type will not affect the already existing postings. If the guest has a rate code change during the stay, there is no difference in the calculation of the adjustments.
OPERA allows the user to define when a generate should stop posting. This is done by specifying the number of days the guest must have stayed (i.e., the number of consumed nights) before the generate will no longer be posted. Properties can indicate how the system should handle previous postings once the stop postings days are reached for a particular generate.
Note: For these fields to be displayed, the Cashiering>Advanced Generates application function must be set to Y and the Transaction Code must not be marked as “Generates Inclusive.” When these requirements are met, the Generates screen will allow the configuration of Do Not Post After Days and Adjustment Types.
Do Not Post After. The value in this field indicates that this generate will stop posting after this specified number of days. The example above shows 30. On the 31st day this generate would not post. Entering 0 is the same as making no entry (blank) — stop posting will not be enabled.
During End of Day. Automatically adjust any posting with this transaction code used as the generate on the 31st day, during the End of Day Process. When an adjustment is made for this adjustment type, OPERA automatically inserts a Checkout alert for you. The message indicates an adjustment has been completed for this guest. If the Do Not Post After Days field is set to 30 and the adjustment type is set to During End of Day, the adjustment will only be made for any posting of that generate within those 30 days. Stopping of generates will take place during the End of Day Sequence on the day after the stop days when the adjustment level type is During End of Day. If the generate indicates Do Not Post After Days of 30 the generate will not post during the End of Day Sequence on the 31st day.
Prompt at Checkout. If the Checkout button is selected in the Billing screen, or if an Early Departure is performed, you are prompted accordingly. OPERA also tracks the adjustments that are already made. That way you do not receive the message to adjust twice if there is nothing to adjust.
During the checkout process when you select the Checkout button, if the generate is marked as Prompt at Checkout, the Adjust Generates screen appears with the prompt, The following generates have been evaluated for adjustment. Please select/unselect and press OK to continue.
Mark the generates you wish to adjust in the X column and select the OK button.
The adjustment prompt appears before the Payment screen is displayed or the checkout process is completed. If the guest bill is 0.00, and there are adjustments, the prompt displays before the guest checkout process starts.
No Adjustment. The adjustment is not made automatically, and you will not be prompted with a message during checkout. This is the default type.
OPERA calculates the number of days for the generate, not the number of times the generate was posted. Each transaction code generate is calculated separately.
Example: If tax transaction code 8000 is attached to transaction code 1000 with 30-day stop posting, and 8000 is also attached to transaction code 1010 which doesn't have a stop day, OPERA adjusts only the 8000 charges that are attached to 1000 and does not consider the 8000’s that were posted against 1010.
Charges transferred from one guest to another will not be considered when calculating generate days. This avoids the scenario where one guest might avoid paying tax by routing room charges to another guest (for example, Guest B, who is staying only 10 days, routs his charges to Guest A, who is staying more than 30 days).
If there are generates on the guest bill (any window) that have a Do Not Post After Days number specified, the generate is set to Prompt at Checkout; if the adjustment has not already been completed, you receive the adjustment message when Checkout or Early Departure is selected.
If you select No to adjust the generates and close out of the Payment screen when doing a checkout, the message displays every time you select the Checkout button.
If the bill equals 0.00, you are still prompted with a message, if applicable.
Q: If Guest A is staying 30 days, but, 25 of those days are transferred to Guest B or a company, the number of days is only 5 not 30. Would OPERA adjust only the 5 days that are still on the guest bill and all charges from now on, or are only charges remaining on the guest to be adjusted?
A: No charges would be adjusted as OPERA is looking at consecutive postings.
Q: When does the Generates for No Posting or Adjustments functionality start working?
A: It will start working immediately, just as if you changed the configuration during the guest stay. If a guest stays 40 nights, and then the functionality is activated, and the configuration shows 30 stop posting days, the guest would only have the 30 days adjusted (or prompted), and you must manually adjust the remaining 10 days if needed.
Q: Can a user transfer, correct, delete, or adjust the adjusted transaction?
A: Yes. Once the adjustment is made, it will be treated like a regular posting. To delete, adjust, etc., the message and/or adjustment would not happen again.
Q: If an allowance for today (for example, Dinner) has the generate, should this be considered?
A: Yes. This should also be classified as an End of Day Process posting, because the actual package price will be posted during the End of Day Process.