I actually got another update from Epicor on this. The reason they can’t/won’t automate it is because of the provision in the fee where at least one item on the order is being delivered by motor vehicle. Avalara doesn’t know whether or not something is being delivered by motor vehicle so they can’t automatically apply the fee. I still believe it would be better to have a checkbox that we could use to indicate this (for us it would always be true), than to have to add a part to every Colorado order to tell Avalara that the order will be delivered by motor vehicle.
1 Like
@aosemwengie1 - That’s a cop-out answer from Epicor. If there’s a shipvia that’s not customer pick-up, then it’s going to be delivered by motor vehicle… Worst case, Epicor has us all add the same UD field to the ship-via’s to designate them as motor vehicle deliveries.
@josecgomez - Is the offer still there to show a quick and dirty BPM / function to add the misc header charge? That first step would help us low-coders a ton! We’ve got our salespeople adding the misc header charge manually now when they remember, and will run a report at end of month to catch the rest… Thanks so much!
Yes I can do that give me a bit.
1 Like
It’s a total cop out!!!
I would like a function that adds the part to the sales order if somebody is offering to help. Adding a misc charge doesn’t break out the tax properly which is a requirement specified in the law.
@josecgomez - Thanks!
@aosemwengie1 - Does it matter if it’s a part (Line>0) or misc header charge (Line 0)? Both the SO Ack and Invoice show the CORD miscellaneous charge, which should be $0 per the KB article, so the $.27 would need to be shown in part/misc description or broken out another way.
The $.27 gets aggregated in the Total Tax amount from Avalara… We’ll change the CORD description to show ‘CO RtlDelivFee, $.27 Incl In Tax’ or whatever will fit in the character limit we get. I’m not sure how much time we want to spend getting fancy with SSRS to catch that separate $.27 from Avalara and break out the tax line.
I really don’t want to put dozens of hours into an elegant solution for this hack legislation from Colorado, but mark my words, California will think this is better than sliced bread, and do it next. It’ll probably be a Prop65 fee for every item that has a warning. 
1 Like
I have tested this with a part (not a misc charge) and the .27 does show up properly broken out in the taxes section. I don’t know if it comes out correctly with a misc charge but from reading Epicor’s KB article it sounds like it may not.
Avalara does add the $.27 correctly to the taxes, when it’s triggered through the $0 CORD misc header charge.
2 Likes
Nice Andris, thanks for validating.
Right - but does it get listed separately?
Sort-of. The std ssrs report shows misc charges separately and displays the misc charge description. That can be edited within the to show the $.27, but we’re limited to 30 characters… Use something like ‘CO RTL DLV FEE $.27 APPLIED’ and adjust your SSRS Report to not clip the description.
Also, it seems the SOAck’s Std SSRS tax breakdown doesn’t match the Avalara Tax Connect Results, but the total amount does. AvaTax is burying the $.27 in there somewhere…
SOAck Std SSRS:
1 Like
I know Colorado has said they don’t plan any enforcement effort on this (yet) but if I am going to try to automate it I think I will build it the way that the .27 fee prints properly (adding the part).
We opted for the misc charge solution, as it is more seamless and can actually be set up to automatically charge once per order. Now I’m reconsidering this, since we cannot break out the tax.
For those of you who decided to use a $0.00 part, how are you making sure that this part is “packed out”? We had previously had a program to include marketing materials, and to make sure they went in the appropriate shipments, we added the line automatically.
What happened then was:
- Sometimes it was the only item “available to ship”, and we printed a pick slip with only the brochure
- Sometimes the shipper neglected to pack out the item in Epicor, and it left an open order with only this unimportant $0.00 item on it.
- When processed correctly, it was extra time and aggravation for the shippers
Most of the time when our shipping department is using customer shipment entry, they are doing a mass shipment so that is how it gets picked up. I think if they miss it for some reason, it will still get caught later on in the process because somebody will wonder why the order did not close, but I need to keep an eye on this to validate that.
All of your points are valid - this is why Epicor and Avalara need to fix this implementation. All of this headache would be unnecessary if they would properly implement the fee. PLEASE vote for the idea on kinetic ideas so they can place some urgency on this. @askulte had a great suggestion of flagging the Ship Via method as motor vehicle or not. Since Ship via is already required on the sales order header, that should be a painless way for Avalara to know whether the fee applies and add it to the sales tax automatically without all of this misc charge/part nonsense.
2 Likes
Attached is a function that takes an OrderNumber and either adds or removes the MISC CHARGE “CORD” if needed.
It is mostly no code though there are some minor things that I couldn’t do without code. My version is 2021.2.10 so anyone on or above that should be able to use it.
Assumptions:
Assumes there is a valid Misc Code in the system called “CORD”
EFX: ColoradoRetailTax.efxb (738.4 KB)
Input: OrderNum
Output: ChargeAddedRemoved (boolean) returns True if it made a change to the order
Flow:
Checks if the Fee is Needed by Looking at (ShipTo.State=“CO” OR OTS.State="CO) and DocTotalTax > 0
If the above is true it determines if the order already has the charge by looking for an existing OHMiscHed charge MiscCode=“CORD”
IF Needed and Doesn’t have it (Adds it)
IF Not Needed and Has it (Removes it)
The two bits of custom code are because Epicor still hasnt’ provided an easy way to to set RowMod using widgets particularly for new rows.
//1
ods.OHOrderMsc.Where(r=>r.MiscCode=="CORD").FirstOrDefault().SetRowState(IceRowState.Deleted); //Sets the "CORD" to Deleted State so its removed with the Update
//2
ods.OHOrderMsc.Where(r=>r.Added()).FirstOrDefault().MiscCode="CORD";
//Sets the Misc Code of the Newly added Row
I did some minimum testing on this so if you find any issues let me know.
I offer no guarantees, test this stuff in your system thoroughly before you just put it in production. Seriously if it breaks and deletes all your orders don’t call me.
3 Likes
It looks like Epicor will be reviewing the Epicor idea that was submitted for this in more detail with Avalara according to an email that I received this morning from Patricia Aparicio (Epicor).
1 Like
Thanks Jose, were you affected by the tax change?
Are you using this function in your production environment?
We are affected we do deliver to colorado.
No we aren’t using this function (yet) waiting for prime directive from above
2 Likes
Same here. At first I thought it was about Retail but its really about the end-customer… If you are selling to someone who isn’t reselling it, it is considered “Retail” even for B2B.
I thought Retail meant “Consumer” (a person not a corporation). As well as a ecommerce store front.
Same here, we are waiting for directives if we can wash it off and pay it annually or charge Customers.
2 Likes
Thank you Jose! I was able to import it into my 2021.2.8 environment, and start kicking the tires. Curious - Why start by setting the ‘ChargeAddRemoved’ argument to false, and finish the flow by setting it to true? I didn’t see it referenced inside any of the other widgets.
1 Like
It only gets set to true if you get through adding or deleting something otherwise it never gets to the end it exits / aborts on some of the conditions
So it’s only true if something was added / deleted