Does anyone know of a way to handle the new CO Retail Delivery Fee ($.27 beginning July 1, 2022) either with Avatax or without?
Avalara had sent out communications regarding this which stated to perform the following:
Merchants subject to this fee will need to add a $0 line item to their orders with the OF400000 tax code.
I’m unsure as to how this would be done in Acumatica. Perhaps someone from Acumatica may know if there will be something released in a new build perhaps?
Page 1 / 2
Hi @Nicole Ronchetti
I’d like to follow this as well not only for Avalara but Vertex also. We have a few clients on Vertex that this will affect.
You would just set up a tax category with a Tax Category ID of “OF400000” and apply it to a 0$ non-stock item. The tax category id gets sent to Avalara as the tax code.
@markusray17 - ok that helps. However, doing it this way would then require that users entering the orders need to remember to add the $0 item to the order in the case where its applicable no?
Trying to find a way that this could be automated, and based on the suggestion I’m still not understanding how this could be accomplished without a customization or additional feature in the system.
@markusray17 - Have you been able to get this to work with Avatax? I tested your suggestion with Avatax and the system did not add an additional tax charge. Is this because it is not in effect yet?
I cant speak to that(we don’t do business in Colorado we use custom tax codes for special tax exemptions), I would just make sure that the line is showing with the correct tax code in Avatax.
As far as automating it I don’t think that is possible without a customization or at least I can’t think of a way.
We would also like to know what the recommended solution would be for this capture.
Seems strange that the Commerce Connector wouldn’t consume all ‘Tax’ lines from Shopify.
Maybe we can use the <<AUTOMATIC» mapping in the connector?
The solution we came up with to automate this was to create a business event that triggers on the creation of the SO Invoice that runs an import scenario to add the $0 item with the tax category ID OF400000 to the invoice for all invoices that have a corresponding shipment record with the ship to state of “CO”. Once the the item is added by the import scenario the invoice is sent back to Avalara and Avalara return the $0.27 under the Tax ID ‘RETAIL DELIVERY FEE’ in the tax details.
Then per Colorado’s requirement to have this listed as a separate line on our invoices, since Acumatica is including this Retail Delivery Fee in the Tax Total and we don’t not include the tax details on our invoices, we updated our invoice reports to calculate the total tax and retail delivery fee using a subreport
We did a similar thing...although i have never really had faith in the “business event” functionality, so I created a GI that isolates the transactions (ship to = CO, Open Status, UDF is not checked), then I created an import scenario with the GI as the data provider that updates our SO with a non-stock item worth $0 (OF400000 category) on a new line, and I created a UDF checkbox that then gets checked as part of the Import Scenario so that I don’t pick this invoice back up in my GI the next go around...
I then schedule the Import Scenario to run every 5 minutes.
Nice, but it does not address the issue where customers are using Shopify, Big Commerce, or other Acumatica supported commerce platform. The majority of commerce orders are authorized or captured with credit cards so the sales orders need to have the line item for the fee when imported from the commerce platforms. Four13 kindly provided links for BC and Shopify. The Shopify solution is incorrect because it is not a tax, but a fee that needs to be a line item.
Avalara seems to have a solution but I could not find a solution for the other tax providers supported by Acumatica because you need to have an account to access support.
Avalara is the tax engine for Shopify. We have Avalara as well for Acumatica and their recommendation was to add a non-stock item at 0 cost to the SO on import from Shopify. The problem is that Acumatica does not bring over the line of a non-stock (0 qty, $0) SO line to the invoice, so there’s that.
Yes, it has to be a line on the sales order and not a tax. And if order was authorized or paid with a credit card you just can’t add the line in Acumatica,
Yes, it has to be a line on the sales order and not a tax. And if order was authorized or paid with a credit card you just can’t add the line in Acumatica,
All of our Shopify SO’s sync via the connector as paid by CC or other means, and I can add a line with my automated process as long as the SO lands in OPEN status (which it does).
I may be a little late to the party here, but why would one Avalara connector in Shopify recognize this and calculate the $.27 and the calculations coming from Avalara through Acumatica not recognize this?
On top of that, if the customer is exempt, the “fee” still needs to be charged as this isn’t a tax, it’s a fee per shipment from what I see, not per order.
And if the customer is tax exempt, Avalara won’t recognize this either and not charge even the initial fee. This fee is regardless of a customer being tax exempt.
I may be a little late to the party here, but why would one Avalara connector in Shopify recognize this and calculate the $.27 and the calculations coming from Avalara through Acumatica not recognize this?
we can only ponder! we get rounding errors all the time too, which you’d think couldn’t be possible if both systems are using the same tax engine.
I may be a little late to the party here, but why would one Avalara connector in Shopify recognize this and calculate the $.27 and the calculations coming from Avalara through Acumatica not recognize this?
we can only ponder! we get rounding errors all the time too, which you’d think couldn’t be possible if both systems are using the same tax engine.
All the time. Boggles my mind. What makes this more complex is that it’s per invoice. Not per order. So if you have multiple shipments, each one needs to be charged the $.27. No one seemed to catch that part of this tax. and it needs to be itemized.
I may be a little late to the party here, but why would one Avalara connector in Shopify recognize this and calculate the $.27 and the calculations coming from Avalara through Acumatica not recognize this?
we can only ponder! we get rounding errors all the time too, which you’d think couldn’t be possible if both systems are using the same tax engine.
All the time. Boggles my mind. What makes this more complex is that it’s per invoice. Not per order. So if you have multiple shipments, each one needs to be charged the $.27. No one seemed to catch that part of this tax. and it needs to be itemized.
yup, and the automation I setup can’t really handle the split ships at all...luckily most our shopify activity is one item at a time, but in case of backorders….not really catching it.
This is supposed to be addressed relatively soon via avalara…because we had to turn on Tax sync on the connector and initially we had the ‘fee’ set as a qty of 0, then it woundn’t convert to the invoice... The rounding errors are still a mystery. Are you part of the CAB (commerce activity board)? You should join. We get very good visibility to the development team.
I am defiantly late to this party.
So our situation is somewhat different in that we create a quote for everything and then flip to an SO. We do not process past a quote without a Purchase order from our customer. Well in order to get the PO to match the quote we must have the delivery fee on the quote otherwise we have to add it and then request a revised PO.
We sell B to B and B to C. We have a webstore that is not connected to Acumatica so dodged a bullet there in a sense.
Someone said that the fee needs to be charged to exempt customers but that is not what I read.
(No, wholesale sales are not subject to the retail delivery fee.)
I am working with my team in the short haul to add the line item from a stock part for retail sales only priced at .27 coded in Avatax to OF400000. Avatax will see the part and product code and enable us to file the return.
Long haul I want to build a customization to look at Colorado ship to quotes, determine if it is taxable and if so automagically add the line item. Then the problem might be solved.
Thoughts anyone?
I am defiantly late to this party.
So our situation is somewhat different in that we create a quote for everything and then flip to an SO. We do not process past a quote without a Purchase order from our customer. Well in order to get the PO to match the quote we must have the delivery fee on the quote otherwise we have to add it and then request a revised PO.
We sell B to B and B to C. We have a webstore that is not connected to Acumatica so dodged a bullet there in a sense.
Someone said that the fee needs to be charged to exempt customers but that is not what I read.
(No, wholesale sales are not subject to the retail delivery fee.)
I am working with my team in the short haul to add the line item from a stock part for retail sales only priced at .27 coded in Avatax to OF400000. Avatax will see the part and product code and enable us to file the return.
Long haul I want to build a customization to look at Colorado ship to quotes, determine if it is taxable and if so automagically add the line item. Then the problem might be solved.
Thoughts anyone?
Couldn’t you use the same methodology I employed just make your initial Generic Inquiry filtered for Quote Order Type only, that have a ship-to of CO? Have the import scenario add the row to the quote and then check a UDF that says it’s complete. Make sure the original GI filters out the Quotes that have a checked UDF?
Can anyone provide the step by step instructions to set up the CO Retail Delivery Fee who has been successful? Are there still issues or has this been resolved by now?
@bjeter78 Are you using Avalara or Vertex for your integration?
Avalara
@bjeter78 Currently, the way to do this is a bit manual for Avalara. We are working with the Avalara team to determine a more seamless way to capture the Colorado Retail Delivery Fee. Timing is TBD. Avalara published documentation on what to do for ERP use cases vs e-commerce site use cases where the customer can complete the transaction on their own.
The requirement for this fee is to add at the Invoice level. If you have multiple shipments/SO’s that relate to one invoice, you’d have to add it once.
Create a new Tax Category ID with the Tax Code: OF400000
Next, create a $0.00 Non-Stock Item associated with that Tax Category
Check if order has taxable items, if it does:
Check if it is an address in Colorado that’s not a Will Call type Ship Via
You will need to add the non-stock item from the Step 2 to the Invoice. Once you do that, under the Taxes tab for the Invoice, you should see the Retail Delivery Fee returned by Avalara and appearing as a Tax ID
Step 1 and 2 are done once. Step 3 would be done for every invoice.
@bjeter78 Currently, the way to do this is a bit manual for Avalara. We are working with the Avalara team to determine a more seamless way to capture the Colorado Retail Delivery Fee. Timing is TBD. Avalara published documentation on what to do for ERP use cases vs e-commerce site use cases where the customer can complete the transaction on their own.
The requirement for this fee is to add at the Invoice level. If you have multiple shipments/SO’s that relate to one invoice, you’d have to add it once.
Create a new Tax Category ID with the Tax Code: OF400000
Next, create a $0.00 Non-Stock Item associated with that Tax Category
Check if order has taxable items, if it does:
Check if it is an address in Colorado that’s not a Will Call type Ship Via
You will need to add the non-stock item from the Step 2 to the Invoice. Once you do that, under the Taxes tab for the Invoice, you should see the Retail Delivery Fee returned by Avalara and appearing as a Tax ID
Step 1 and 2 are done once. Step 3 would be done for every invoice.
@bjeter78 - we used this setup as well. One clarification I will call out is that a SO will not automatically add the non-stock CO FEE line, unless entered manually or via system process. AND we also DON’T bill this to our Resellers or tax exempt customers due to this clause:
The Colorado Retail Delivery Fee (CRDF) is a state-imposed fee (not a tax) that applies to every order (not invoice) when there is an item of tangible personal property that is delivered by the retailer or a third party via roads and the item is taxable. A “retail” transaction is not limited to what is commonly thought of as a retailer but rather includes any sale that isn’t for resale or otherwise exempt. If an order has anything taxable that is tangible, the fee applies!
Also Shopify does not pass this fee to the SO on order import. So in order to account for this at the SO level, automatically (for shopify and in case our sales folks forget), I actually created a UDF on the sales order that is a simple checkbox called “CO Fee”. Then I have a GI that tries to collect all transactions that are shipping to CO that are not resellers or tax exempt where the UDF is NOT checked... Then I have an automation schedule that kicks off an IMPORT SCENARIO based on the GI. This import scenario does 2 things: 1) it adds the non-stock item to the SO (with a qty of 1 otherwise it will not push to the invoice after shipment). 2) It checks the UDF box to signal that CO Retail Fee has been applied to the order, excluding it from the GI above.
This is the ONLY way we can literally try and capture this fee without accounting having to manually add it to hundreds of invoices each month. Hoping Avalara fixes this soon...Shopify captures it, but it is not getting passed to ACU.
Once the tax category and non-stock are setup, Avalara will pick up the delivery fee from the sales order? Nothing needs connected or activated?