Differences between how Nopcommerce calculates taxes and charges customers and how RTP calculates taxes can lead to .01 cent discrepancies when open orders are opened inside of the RTP POS leading to additional reconciliation overhead for onsite staff when online orders are not auto-fulfilled.
Aspenware has introduced an optional MatchTaxCalculation setting to alleviate these onsite fulfillment issues for orders that are not auto-fulfilled, ensuring that when there is a tax discrepancy between Nopcommerce (what the customer paid in tax) and what RTP recalculates as the tax amount, the order placed into RTP via Unity always matches RTP’s method of tax allocation. This setting does not make Nopcommerce tax and RTP tax calculation match, so while it can alleviate issues with onsite order discrepancies, accounting and other groups will need to be alerted to 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.
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 as 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 wait to 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.
Your accounting department is not comfortable with or equipped to handle the several centmismatch between RTP and Nopcommerce (see below.)
Explanation of "Add a Penny" Logic
Add a penny logic is used when there is more than one component on a product header that both have tax.
RTP and Unity calculate tax in two ways and compare: "sum then round" and "round then sum," both using bankers rounding rules.
“Sum then round” is calculated by determining the sum of the individual line item taxes and then rounding the resulting total.
“Round then sum” is calculated by rounding the taxes at each individual line item to two decimal places, 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