About Rounding Factors

In certain jurisdictions around the world, monetary amounts must be rounded by a standard factor due because of the discontinued use of lower denomination coins. To meet this requirement, OPERA Cloud provides a rounding factor feature that allows properties to automatically apply a designated rounding factor to monetary amounts.

Rounding factors are applied to payment type transaction codes that you designate for rounding. This flexibility allows you to handle situations where one payment method is not rounded, such as EFT credit card payments, while another payment method is rounded, such as cash payments.

• When the rounding multiple code is of Payment type, the rounding is posted to the account and applied as a payment to the last invoice.

• When the rounding multiple code is of Revenue/Consumption type (revenue producing transaction code), 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.

The OPERA Controls Cashiering>Rounding Factor allows you to set the rounding factor to use. Available factors are 5, 10, 50, and 100.

Rounding Multiple Code Setting Using Consumption Transaction Code Type

• The transaction code must be marked as Revenue Group.

• After making a rounding difference posting to this transaction code, you cannot edit the transaction code in configuration.

Rounding Multiple Code Setting Using Payment Transaction Code Type

• The transaction code must be marked as Others payment type using the Transaction Type drop-down on the Transaction Code setup screen.

• Note, after assigning a transaction code to the Rounding Multiple Code setting, before any posting is made using this transaction code, you can edit the transaction code. OPERA Cloud will not prompt as in the case of a consumption code; however, the following attributes cannot be selected: AR Account, Cashier / AR / Deposit, Paidout, Revenue Group, Round Factor, or Membership. If there are any posting against this transaction code, OPERA Cloud 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 situations where one payment method is not rounded (for example, EFT credit card payments) while another payment method is rounded (for example, cash payments).

To designate that a payment type is to be rounded, select the Rounding Factor check box on the Transaction Codes Edit 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 Cloud applies the rounding factor (as appropriate for the payment method being used) before displaying the Amount field in the Payment screen.

The rounding difference is posted only if the balance due is an amount that needs to be rounded and is being fully paid off, for example, 25.22 is rounded to 25.20 for a bill being paid in full.

Note:

Payments posted in foreign currency are not subject to rounding.

If the payment method is (or is changed to) a payment method that does not use the rounding factor, OPERA Cloud 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, if the last amount due is .02 or .01, OPERA Cloud will automatically post a rounding difference irrespective of the payment methods used earlier. For example: If a billing window has a balance of .01 or .02, selecting Payment or Settlement will post the rounding difference automatically. This applies to Passerby, AR, POST IT, and so on.

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 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 payer makes a cash payment, the invoice amount is automatically rounded to 133.45 at the time the Payment screen opens. 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 any are posted when performing currency exchange.

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

See related topic – OPERA Controls