Avalara Design Principles
Date Revised: 10/4/23
When to Call Avalara to Calculate Taxes
CLS
Version: 8.6 and Above
Issues Related to Running Versions 8.5 and 8.6 Side by Side
While we allow users to run versions 8.5 and 8.6 side by side, if users turn on the Avalara interface then applications that interface with Avalara are subject to special restrictions. Avalara only works in version 8.6. If users run Avalara-related programs in version 8.5, that can cause an issue. Therefore, for those Avalara-related programs if the user is running version 8.5 and Avalara is enabled, the application will provide the user with an error message. For those programs that have a user interface, a message will be displayed stating that the application must be run under version 8.6. For those programs that do not have a user interface, such as printing and posting applications, an error message is printed on the report. For those programs not related to sales tax, you can continue to run them in 8.5 or 8.6. For example, General Ledger, Accounts Payable, Payroll, Bank Book, Most Inventory Module, Purchase Order, Bill of Material and Production Work Order.
Use Elliott Attribute to Store Additional Data
Since additional database space is required to store Avalara-related data, Elliott attributes are used to store Avalara data. See Elliott Attribute Support for more information.
Avalara Taxes Are Calculated in Customer Order Processing (COP) Module Only
If a user should go to A/R Cr/Dr Memo Processing A/R Service Invoice Processing to enter transactions for taxable customers, the application will force the tax amounts 1, 2 and 3 to be zeroes. A message to the side of tax amounts will show the message "A/R does not support taxes. Use COP Invoices and Credit Memo for taxable transactions." This limitation is mainly due to Avalara sales tax calculation require tax code for the line items. There's no ability to enter line item information in A/R Cr/Dr Memo Processing.
Make the User Interface (UI) as Simple as Possible
Our objective is to make Avalara UI as simple as possible to the users so they won't notice there are user interface differences.
- The use code or tax code will be stored in the attribute for customer, ship-to, item…etc. so you won't notice the user interface difference. Also, the use code for the customer attribute will be inherited by the ship-to automatically unless it is overridden at the ship-to level.
- Use code indicate if the customer is taxable or non-taxable. If non-taxable, what type of user code? Reseller, Government...etc. to cause the exempt? The use code attribute (exemption reason) for customer type will be inherited to the customer. If no use code attribute is designed for customer type, ship-to, or customer, then the default use code in Global Setup will be used. You can take advantage of this hierarchy structure to reduce the number of use code entries required for setup.
- Tax code is used to indicate the type of items. It is very possible that your entire organization sells items under only one or few type of tax code. You can take advantage of the fact that the tax code attribute for product category, user-defined code will be inherited to the item. If there is no tax code attribute designated for product category, user-defined code or item, then the default tax code in Global Setup will be used. See Item Tax Codes for more information.
Elliott Will Need to Continue Operation if Internet is Down
Avalara is a cloud based solution. The integration is designed to assume that the internet is not up all the time. The following changes were made to support this concept:
- Download Zip Codes Tax Table from Avalara – Avalara provides tax rate by zip codes. You should download Avalara Zip Codes Tax Table through Elliott's implemented UI on a monthly basis. This will allow Elliott to use Avalara tax information by zip code to determine tax rate when the internet is down. In addition, excessively calling Avalara cloud services can incur additional cost. Therefore, in many cases, Elliott only estimate tax based on zip Codes Tax table. There may be small discrepancy, but this should be close to the final calculation.
- Separate Commit to Avalara Step After Invoice Posting – Posting invoices in COP Sales Journal to Accounts Receivable does not communicate with Avalara to commit the transaction. This is to avoid a crash in invoice posting if the application is unable to communicate with Avalara. Instead, the invoice posting application will update the to be committed Avalara data to the new Tax Queue file (AVTAXQUE). The queue file data will be committed to Avalara in a separate step, preferably through deferred processing after invoice posting has completed.
- Tax Reconciliation Report – It is possible from the entire time from order entry to invoice printing, the internet is down. In that case, the tax amount posted in Elliott is estimated based on Zip Codes Tax Table. To commit from Tax Queue file to Avalara requires internet. At that time, it is possible the estimated and posted tax in Elliott may not match Avalara, A reconciliation report is provided to show if there’s any difference between Elliott’s invoice tax amount vs Avalara's final tax amount.
At time of O/E, Sales Desk, or other applications with a user interface, since the order may still subject to change, we only estimate the tax amount in Elliott UI based on Zip Codes Tax Table. At this moment, our primary objective is to make sure the address is valid. This can be accomplished by enabling Address Validation which is very helpful if you drop ship. Address Validation is available in Customer File Maintenance, Ship-To File Maintenance, Order Entry, Sales Desk, Recurring Orders, etc. Address validation require UI so Elliott can suggest the correct address. Orders that are not created with a user interface -- such as Sales Order Import -- will not perform address validation. If address validation is not enabled, the address will not be validated until taxes are calculated.
System call Avalara to calculate sales tax when the picking tickets are printed, It implies the order is going to be shipped soon. Since user may back order line items and adjust the order total amount during billing selection, the final tax calculation for the invoice will occur when invoices are printed.
Typically, additional costs like freight and miscellaneous charges are determined by the warehouse, which is added to the order at the time of billing selection. Since we support payment window in the billing selection screen, it is possible the user may require the order be fully paid before shipment. Therefore, when the payment window is shown, tax should be calculated before displaying the window in order to charge the full amount to a credit card.
The order must be placed on hold if there is an issue printing the picking ticket. For example, if there’s a problem with an order -- like the address is not valid. Avalara will not be able to calculate the sales tax correctly and therefore, we need to place the order on hold. For this reason, you should turn on Credit Check and Release feature in Elliott if you want to use Avalara interface. Someone like the credit manager needs to find out the correct address before the order can be shipped.
Address Validation
If Address Validation is enabled per global setup:- If the customer or ship-to already has the address validated and it matches the order ship-to address, then there is no need to call address validation again at order entry.
- If the address is a drop ship or has a ship-to address that was changed manually, then the application will validate the address.
- To prevent duplicate data that can cause confusion, the customer/ship-to attribute _CALCAVALARA is not copied to the order. It is verified from the original source.
- If there is no _CALCAVALARA attribute on file for the customer and ship-to but the order ship-to address matches the customer or ship-to address, the address will be validated and the _CALCAVALARA attribute will be created for either the customer or ship-to level to make it reusable in the future.
- The attribute is only created at order level if this is a drop ship address where the order ship-to address is being overwritten.
- Programs without user interface, such as Sales Order Import and Web Services, will not perform address validation. Validation will occur when the order is brought up in Change mode.
- Finally, the address will be validated at the time of pick ticket and billing payment window via tax calculation, which will stop the order with an invalid address.
If Address Validation is disabled:
- Even if address validation is not enabled, maybe due to the cost concerns, Elliott still need to ensure the address be accurate to certain extent by applying the principles in this section. The strategy is to piggy back address validation at time of calculating sales tax with Avalara and save associated address resolution info to _CALCAVALARA attribute which can be reused later on.
- During O/E, Sales Desk...etc. or any other application where there is a user interface, tax calculation will be performed when the payment screen is accessed. If the tax calculation is successful and there is no _CALCAVALARA attribute on file for the customer and ship-to but the order ship-to address matches the customer or ship-to address, the address will be validated and the _CALCAVALARA attribute will be created for either the customer or ship-to level to make it reusable in the future.
- If the tax calculation fails, the user will be given a reason why the calculation failed so that the issue can be addressed.
- Otherwise, for those programs that do not have a user interface, the Avalara tax calculation will be deferred to printing of picking tickets, or when the payment screen is accessed.
- Pick Ticket will put the order on hold if it fails Avalara requirements – During the time of pick ticket printing, Elliott will check if the order meets all the requirements for the Avalara interface.
Sales Desk & Order Entry Add/Change Customer on The Fly
In Sales Desk & Order Entry, users can add/change customers on the fly without going to Customer File Maintenance. Up to 15 fields can be set up in the window per Global Setup. The Avalara interface will make sure of the following:
City, State & Zip Code must be part of the 15 fields since they are required for Avalara interface.
Tax Code 1, 2 & 3 must not be defined in the list since they are not user definable with Avalara interface.