Rounding Factors

In certain jurisdictions (e.g., Singapore, Australia, New Zealand, Slovakia, etc.), monetary amounts must be rounded by a standard factor due to the fact that the use of certain lower denomination coins has been discontinued. To meet this requirement, OPERA provides a Rounding Factor feature that allows the property to automatically apply a designated rounding factor to monetary amounts.

The Rounding Factor feature is available when the Cashiering>Rounding Factor application parameter is set to Y. When this parameter is active, two additional application settings are available.

• Cashiering>Rounding Multiple allows you to set the rounding factor that is to be used. Available factors are 5, 10, 50, 100, 1000, and 10000. (See Rounding Examples, below, for details on how these rounding factors are applied.)
• Cashiering>Rounding Multiple Code allows you to choose the transaction code that will be used for posting the rounding difference.

  Note: The rounding functionality is executed prior to any rounding required by the decimal setting.

Rounding factors are applied to the Payment type transaction codes that you designate for rounding. This flexibility allows you to handle those situations where one payment method is not rounded (e.g., EFT credit card payments) while another payment method is rounded (e.g., cash payments).

Rounding Examples

1. Rounding factor = 5

Value Before Rounding	Value After Rounding	Notes*
80.01 80.03 80.07 80.08	80.00 80.05 80.05 80.10	Rounds up or down to the nearest multiple of 5.

In a zero decimal environment, where the rounding factor = 5:

Value Before Rounding	Value After Rounding	Notes*
120.57 120.47	121 120	The rounding functionality is executed prior to rounding due to the decimal setting.

2. Rounding Factor = 10

Value Before Rounding	Value After Rounding	Notes*
14 26	10 30	Rounds up or down to the nearest multiple of 10.

3. Rounding factor = 50

Value Before Rounding	Value After Rounding	Notes*
121 256 144 277	100 250 150 300	Rounds up or down to the nearest multiple of 50.

4. Rounding Factor = 100

Value Before Rounding	Value After Rounding	Notes*
22 144 211	0 100 200	Rounds down to 0 or the nearest multiple of 100.
166 88	200 100	Rounds up to 100 or the nearest multiple of 100.

5. Rounding Factor = 1000

Value Before Rounding	Value After Rounding	Notes*
1311 3192 1712	1000 3000 2000	Rounds up or down to the nearest multiple of 1000.

6. Rounding Factor = 10000

Value Before Rounding	Value After Rounding	Notes*
12453 5192 78911	10000 10000 80000	Rounds up or down to the nearest multiple of 10000.

*This feature uses a computational function similar to MROUND which is used by Excel spreadsheets.

MROUND(number,multiple)

where number is the number to round and multiple is the multiple to round the number to.

MROUND(10,3) rounds 10 to the nearest multiple of 3, or 9.

MROUND rounds up, away from zero, if the remainder after dividing the number by multiple is greater than or equal to half the value of multiple.

Rounding Factors Setup

Following are guidelines for setting up Rounding Factors functionality.

Application Settings

Set the following application settings.

Cashiering>Rounding Factor - Set to Y. The following two application parameters become available.

Cashiering>Rounding Multiple - Select the rounding multiple to be used for the property.

Cashiering>Rounding Multiple Code - Select the transaction code to be used for posting the rounding difference. A Rounding Multiple Code transaction code assigned to this setting may be of consumption type or a payment type. The determination can be made by the property.

The rounding transaction code, once selected, cannot be edited and it is no longer available for manual posting. The Rounding Multiple Code application setting cannot be changed to another transaction code once difference amounts are posted against it.

Rounding Multiple Code Setting Using Consumption Transaction Code Type

• The transaction code must be marked as “Revenue Group”.
• Once a rounding difference posting is made to this transaction code, if editing the transaction in configuration, OPERA prompts with a message that it cannot be edited.

Rounding Multiple Code Setting Using Payment Transaction Code Type

• The transaction code must be marked as “Others” payment type using the Others radio button on the Transaction Code setup screen.
• Once a transaction code has been assigned to the Rounding Multiple Code setting, before any posting is made using this transaction code, it can be edited. OPERA will not prompt as in the case of a consumption code; however, the following attributes cannot be selected: AR Account, Cashier / AR / Deposit / COMP / Inter Hotel Payment, Paidout, InterHotel Deposits, Revenue Group, Round Factor, or Membership. If there are any posting against this transaction code, OPERA will prompt as such and prevent making any changes.

  Note: Postings against the Rounding Multiple Code transaction code using a Payment transaction code type are included in the Miscellaneous Payments Cashier Report.

Round Factor Payment Transaction Codes

Rounding factors are applied to the Payment type (PAYMENT Group) transaction codes that you designate for rounding. This flexibility allows you to handle those situations where one payment method is not rounded (e.g., EFT credit card payments) while another payment method is rounded (e.g., cash payments).

To designate that a payment type is to be rounded, select the Round Factor check box on the Transaction Code Setup screen. (This option is available only when the Cashiering>Rounding Factor application parameter is set to Y. It is only available on Payment type transaction codes.)

When a payment is made using the transaction code marked as Round Factor, the rounded amount will be returned as the payment amount.

Feature Behavior

At settlement (Check Out, Early Departure, Quick Check Out) or payment posting, OPERA applies the rounding factor (as appropriate for the payment method being used) before displaying the Amount field in the Payment screen.

Please note that the rounding difference is actually posted only in the event that the balance due is an amount that needs to be rounded and is being fully paid off (e.g., 25.22 in the below example is rounded to 25.20 for the bill being paid in full).

Note: Payments posted in foreign currency are not subjected to rounding.

If the payment method is (or is changed to) a payment method that does not use the rounding factor, OPERA displays the unrounded payment Amount. When rounding is applied, the Billing screen displays the rounded difference along with the rounded payment.

Note: When performing folio settlement and posting partial payments using various payment methods, in the event that the last amount due is .02 or .01, OPERA will automatically post a rounding difference irrespective of the payment method(s) used earlier. This is because amounts such as .02 or .01 cannot be paid using credit card or cash, besides the fact that OPERA will always round down to 0.00 and 0.00 amounts cannot be posted in OPERA.

For example: If a billing window has a balance of .01 or .02, upon selecting Payment or Settlement, the Payment screen will not be displayed and a rounding difference will be posted automatically. This is applicable for Passerby, AR , POST IT, etc.

The rounding difference posting cannot be edited / deleted / transferred by itself/ adjusted/ split. If the payment that posted a rounding difference is moved, the rounding difference posting also moves along with it.

The folio that is generated will show the rounded amount and amount paid, as applicable for the payment method being used. The TOTAL_ROUNDING merge code may be added to the folio footer to show the net rounding applied to the charges shown on the folio.

Other areas where the rounding factor is applied include:

• Passerby payments
• Post It payments
• Currency exchange
• End of Day processing automatic checkout payments
• Paidouts.

In Accounts Receivable, the invoice will be modified to cover any rounding difference due to the payment method, thereby avoiding mismatches between the amount owed and the payment. For example, assume the Rounding Multiple is 5 and cash payments are subject to rounding. If an invoice has a total of 133.44 owed and the user makes a cash payment, the invoice amount is automatically rounded to 133.45 at the time the Payment screen is displayed. The cash payment of 133.45 closes the invoice. If EFT credit card payments are not rounded, the invoice amount and the payment remain as 133.44.

The currency exchange receipts display the rounding difference amount if there is any posted when performing currency exchange.

A merge code for displaying the rounding factor amount has been provided for sample payment and sample deposit receipts.

Scenarios Illustrating Rounding Postings in AR

• When the rounding multiple code is of Payment type, the rounding is posted to the account and is applied as a payment to the last invoice.
• When the rounding multiple code is of Revenue/Consumption type, the rounding is posted to the invoice. For multiple invoices, the rounding is posted to the last invoice in the list. The rounding posting can then be seen in the invoice details screen.

1. Rounding Multiple Code is set to use transaction code of Payment type

A) Apply Payment

INV#	AMOUNT
547	22.22

Select Cash as the payment method > Amount changes to 22.20 > Apply Payment Radio button > Post. When returning to the Account Maintenance screen the invoice should be paid in full. You'll see the rounding for 0.02 is posted as payment and automatically applied against the invoice.

B) Unallocated Payment

INV#	AMOUNT
548	22.22

Select Cash as the payment method > Amount changes to 22.20 > Unallocated Payment Radio button > Post. When returning to the Account Maintenance screen, an unallocated payment of 22.20 would have been posted, leaving the invoice as is and the account with a balance.

C) Apply Payment to Oldest Charges

INV#	AMOUNT
549	22.22

Select Cash as the payment method > Amount changes to 22.20 > Apply Payment to oldest charges > Post. When returning to the Account Maintenance screen, the invoice should be paid in full. You'll see the rounding for 0.02 is posted as payment and that payment is then automatically applied against the invoice.

D) Apply Payment Selectively

INV#	AMOUNT
550	22.22

Select Cash as the payment method > Amount changes to 22.20 > Apply Payment selectively > Post > Apply Payment selectively screen appears > Apply 22.20 and Post. When returning to the Account Maintenance screen, the invoice will be shown with a 0.02 balance. The user can use the functionality from E below to pay off the invoice.

E) Auto Rounding Apply Feature

After the action from scenario D above, the balance of the invoice is 0.02. Following the same logic as in Billing and Passerby, when the last balance due is 0.00 due to rounding, OPERA will automatically post the rounding difference posting without a payment being required. To test, press the Payment button on invoice 550 (after it has been left with a 0.02 balance) and the rounding amount will be automatically posted to the account and then applied to the invoice.

F) Apply Payment to Marked Charges

INV#	AMOUNT
550	22.22
551	33.41

Mark both invoices > Payment > Select Cash as the payment method > Amount changes to 55.65 > Apply Payment to marked charges > Post. When returning to the Account Maintenance screen, the invoice should be paid in full. You'll see the rounding for 0.02 is posted as payment and automatically applied against the last invoice.

2. Rounding Multiple Code is set to use transaction code of Revenue/ Consumption type

A) Apply Payment

INV#	AMOUNT
556	22.22

Select Cash as the payment method > Amount changes to 22.20 > Apply Payment Radio button > Post. When returning to the Account Maintenance screen, the invoice should be paid in full. You'll see the rounding for 0.02 is posted as consumption against invoice 556.

B) Unallocated Payment

INV#	AMOUNT
557	22.22

Select Cash as the payment method > Amount changes to 22.20 > Unallocated Payment Radio button > Post. When returning to the Account Maintenance screen, an unallocated payment of 22.20 would have been posted, leaving the invoice as is and the account with a balance.

C) Apply Payment to Oldest Charges

INV#	AMOUNT
558	22.22

Select Cash as the payment method > Amount changes to 22.20 > Apply Payment to oldest charges > Post. When returning to the Account Maintenance screen, the invoice should be paid in full. You'll see the rounding for 0.02 is posted as consumption to the invoice and that payment is then automatically applied against that invoice.

D) Apply Payment Selectively

INV#	AMOUNT
559	22.22

Select Cash as the payment method > Amount changes to 22.20 > Apply Payment selectively > Post > ARPOSTAPP > Apply 22.20 and Post. When returning to the Account Maintenance screen, the invoice will be shown with a 0.02 balance. The user can use the functionality from 1. E) above to pay off the invoice.

E) Apply Payment to Marked Charges

INV#	AMOUNT
560	22.22
561	33.41

Mark both invoices > Payment > Select Cash as the payment method > Amount changes to 55.65 > Apply Payment to marked charges > Post. When returning to the Account Maintenance screen, the invoice should be paid in full. You'll see the rounding for 0.02 is posted as consumption against the last invoice.