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 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.
MatchTaxCalculation Logic When Enabled (set to 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.
| Note |
|---|
IMPORTANT: DO NOT set MatchTaxCalculation to TRUE if:
|
Split Taxes when MatchTaxCalculation is enabled
When an RTP component is set up with split taxes, as long as the overall tax collected for a component when all tax rates are summed up is equal to the tax collected for the product in Aspenware Commerce (and other rules that are detailed below are also followed), resorts using Unity should be able to successfully sell components that have multiple tax rates on a single component. For example, a product configured in Aspenware Commerce would be configured with an 8% tax in nopCommerce, but when it goes into RTP, Unity checks the RTP component setup to see that it should actually send in a 6% AND a 2% tax for the product’s component rather than an 8% tax (which was shown to the guest), but the total tax amount collected is equal, so it’s a supported configuration.
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.
| Info |
|---|
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
Tax scenarios NOT SUPPORTED
Unity only supports one tax rate per Aspenware Commerce product, and this is not changing, so even with this change to Unity, we DO NOT support multiple tax rates assigned to various components of a single product header. We do not support multiple components in the same product header that each have unique total tax rates, as RTP setup must match nopCommerce for the amount of taxes collected.
Work around suggestion: If you want to set up a product in RTP and sell it in Aspenware Commerce and cannot alter RTP tax allocation, consider breaking out the uniquely taxed component into a separate product header with it’s desired tax rate, and then in Aspenware Commerce, create a separate product for that uniquely taxed NEW product header with it’s desired unique tax category. Now, on the original product, setup the NEWLY created separate tax amount product as a hidden add-on that is preselected and taxed at its unique rate.
All components associated with a product header sold through Aspenware Commerce that have revenue allocation must have tax rates assigned that add up to or are equal to the tax rate defined on the product in Aspenware Commerce, so that the amount of tax collected and displayed to the guest in Aspenware Commerce equals the amount expected in RTP.