Differences between how Nopcommerce calculates taxes and charges customers and how RTP calculates taxes can lead to .01 cent discrepancies when orders are opened inside of the RTP POS leading to additional reconciliation overhead for onsite staff. Aspenware has introduced a MatchTaxCalculation setting to ensure that in the case of tax discrepancies between Nopcommerce (what the customer paid in tax) and what RTP recalculates as the tax amount, that Unity order placement always matches RTP’s method of tax allocation so that this reconciliation overhead is alleviated. This setting does not make Nopcommerce tax and RTP tax calculation match, so while this setting change can alleviate issues with onsite order discrepancies, accounting and other groups will need to be aware of the fact that NOP and RTP will be out of balance slightly if this new setting is set to true.
Explanation of MatchTaxCalculation When TRUE
When the MatchTaxCalculation setting is set to 'TRUE,' tax calculations in Unity will align with RTP calculations, RTP uses bankers rounding in most cases (see “Add a Penny Logic” exceptions below). This ensures a $0 balance when comparing orders in Unity and tax calculations in RTP.
Please note that this might result in a difference between the deposit in RTP and what the user was charged in nopCommerce due to tax differences between the two systems. RTP uses bankers rounding and applies custom logic for rounding when necessary (see “Add a Penny” below).
IMPORTANT: DO NOT set MatchTaxCalculation to TRUE if:
Your resort uses or plans to use Square’s Linked Refunds functionality, which requires that the amount placed in RTP and nopCommerce match.
Your resort uses payment plans or subscriptions.
The tax logic for placing payment plan payments is in a separate function. This code will be updated to respect the setting in an upcoming release, but if your resort uses Aspenware Payment Plan functionality, you should not set MatchTaxCalculation to true until this is available.
Your resort uses Siriusware. This advanced tax logic is is unique to RTP advanced tax logic and should not be enabled for Siriusware resorts.
Explanation of "Add a Penny" Logic
Add a penny logic is used when there are more than one component on a product header that both have tax.
RTP and Unity calculate tax in two ways and compares: "sum then round" and "round then sum," both using bankers rounding rules.
“Sum then round” is calculated by determining the sum of the individual live item taxes and then rounding the resulting total.
“Round then sum” is calculated by rounding the taxes at each individual line item, and then adding these rounded amounts for a total.
To determine whether to "add a penny," both methods are compared when deciding the tax for an RTP Order line item. If the "sum then round" value is greater than the "round then sum" value, a penny is added to one of the line item's taxes based on the tax apply order. Apply order is an RTP configuration assigned to dictate the priority of items for accounting if in the same order.
NOTE: nopCommerce does not use bankers rounding nor does it have this “add a penny” logic. nop tax logic is used to calculate what the customer actually pays in tax rather than the logic explained above, which is only used by Unity when placing the order into RTP.
If MatchTaxCalculation is set to TRUE, your resort’s accounting team should be prepared for there to be a discrepancy in the form of a penny or few pennies for some orders orders due to this mismatched logic. If a resort’s accounting team is not able to reconcile this difference given the explanation, then you should set MatchTaxCalculation to FALSE.
When MatchTaxCalculation is FALSE
When the MatchTaxCalculation setting is set to 'FALSE,' Unity calculates tax in the same way as nopCommerce, using 'away from zero' rounding.
When there is more than one tax, nopCommerce and RTP taxes will always match due to RTP's "add a penny" logic. However, if there is only one tax, differences between taxes in nopCommerce and RTP may arise because of the different rounding algorithms, and in this case, RTP doesn't add a penny. These differences can result in a -$0.01 balance.
Additional Notes
The TransactionProduct and TransactionProductTax tables obtain their values by querying the OrderProduct and OrderProductTax tables (instead of recalculating these values).
To understand how deposits are calculated, we are analyzing SQL traces, which may be a complex task.
Open Question
There is an open question regarding inclusive/exclusive tax support, which may require further consideration