When you set OrderHed.TaxRegionCode, Epicor creates an OrderRelTax for each OrderRel using the tax rate associated with the tax region. If you go into the OrderRelTax row in the Order Entry UI, under Releases/Tax/Detail, there’s a “Manual Tax Calculation” checkbox. When checked, you can override the tax rate from the tax region:
The new rate is correctly reflected in the tax amount and order total on the order summary page. But when we invoice the order, it seems to only consider the default tax rate for the tax region. The tax amount on the invoice is incorrect. Alternatively, if we don’t set OrderHed.TaxRegionCode and create the OrderRelTax manually, again it’s reflected correctly on the order, but the invoice doesn’t include any tax at all.
Is there a trick to making this work? We’re on 10.2.100.
Does the tax rate to be changed for every sales order ?
Because, what i have observed is, selection of manual tax calculation in sales order will not have any effect on the invoice booking. The tax is calculated in invoice based on the tax liability assigned in the customer master.
It may need to be changed for every sales order. Every city in California has a different tax rate, and we don’t want to set up codes and rates for all of them. We also have websites on different platforms with different levels of sophistication in their ability to collect the correct tax amount at checkout. The same customer ordering from one site may be charged a different tax rate when ordering from another site. And it shouldn’t be tied to the customer anyway, because legally speaking it’s tied to the shipping address. (Usually. It’s complicated…) The goal is for each sales order and invoice to reflect the tax that was actually collected, not what Epicor thinks the tax should have been.
And some tax jurisdictions have rates that depend on the good or service. Or may not even be a rate based on the price.
For example:
Pennsylvania has a 6% sales tax (some things are excluded, like food and clothing).
The city of Philadelphia (which is in Pennsylvania), has its own 2% sales tax (with the same exceptions).
Philadelphia also has a $0.018 per ounce tax on soda (and other “sweetened” drinks)
So if your order was like:
Line-Rel PartNum Descprition ShipToCity Qty UOM Unit Cost Ext Cost
======== ========== =========== ========== ===== === ========= =========
1-1 JOLT-001 Jolt Cola PHILA, PA 14400 OZ 0.05 $720.00
1-2 JOLT-001 Jolt Cola PITT, PA 14400 OZ 0.05 $720.00
2-1 JACKET-01 Coat PHILA, PA 1 EA 125.00 $125.00
2-2 JACKET-01 Coat PITT, PA 1 EA 125.00 $125.00
3-1 RACK-01 Display rack PHILA, PA 1 EA 500.00 $500.00
3-2 RACK-01 Display rack PITT, PA 1 EA 500.00 $500.00
Line 1-1 would have tax of:
6% of $720 = $43.20 (PA sales tax)
2% of $720 = $14.40 (Philly sales tax)
$0.018 x 14400 = $259.20 (soda tax)
Line 1-2 would just have (i’m assuming Pittsburgh doesn’t have any special taxes like Philly):
6% of $720 = $43.20 (PA sales tax)
Lines 2-1 and 2-2 would have no tax (clothing exempt)
Line 3-1 would have tax of:
6% of $500 = $30.00 (PA sales tax)
2% of $500 = $10.00 (Philly sales tax)
Line 3-2 would have tax of:
6% of $500 = $30.00 (PA sales tax)
Avalera is the way to go. It takes care of all this (well, not sure about the qty based taxes like Philly’s soda tax). But it does take care of the taxes based on the specific good or service.
Avalara might be great if we were entering orders directly in Epicor. But again, we want to record the tax actually collected on the websites, not what Epicor thinks is correct. I wonder how Avalara controls the tax that appears on invoices. Does it create a huge number of codes and rates on the fly?
We only want to change the tax percentage. Whether OrderRel.TaxRegionCode is inherited from OrderHed.TaxRegionCode or set directly on the release, the invoice ignores OrderRelTax.Manual and OrderRelTax.Percent and uses the default rate for the TaxRegionCode. This looks an awful lot like a bug.
I can confirm that what you are trying to do is not supported as of now and is considered an enhancement.
I’m not really sure about the process but I would recommend you contact support and create a case to be added to enhancement ERPS-84482 so it can be tracked.
It seems it has been a while since it was requested and it needs to be reviewed, it cannot be simply added and forced onto everyone, it would need to be optional and need to be defined at what level it can be configured(customer, order, company?) among other things related to tax configuration.
Wow. So this has been reported by multiple customers at least as far back as 2012, and it’s still not fixed? What’s the use case for not calculating the same tax on the invoice as on the order? A fix probably wouldn’t force a change on anyone, because I doubt anyone can use the manual tax rate feature in its current state.
I mean that is the last time someone reported this as far as I know, maybe there are more requests on Service Now which I don’t know how to track down.
I guess the question would be if they are not using manual tax on the order because it doesn’t flow to the invoice or because it is not needed. Taxes can change between the order and invoice and I think that is why it cannot just be copied from the order.
Maybe now it makes more sense to have the option for business scenarios like yours which is why is good to report it so it can be reviewed.
For now maybe some kind of customization to copy the rates/amounts from the order tax to the invoice is required, not sure what else can be done, hopefully someone else has something for this.
Sorry if I came off as angry. I perhaps unfairly interpret everything from Epicor as a lack of interest in improving the software since being told directly by a CSR that they’d confirmed an issue but the devs would probably not even look at it because a workaround exists.
Here’s what I’m thinking:
OrderRelTax is many-to-one with OrderRel.
OrderRel is typically one-to-one with ShipDtl, although in rare cases it’s one-to-many.
On a SHP invoice, ShipDtl is one-to-one with InvcDtl.
InvcDtl is one-to-many with InvcTax.
Ultimately what I want (and expected as default behavior) is a one-to-one correspondence between OrderRelTax and InvcTax, at least in the normal case where OrderRel is one-to-one with ShipDtl. I may attempt to implement this with a BPM.
That is how it works for non-manually entered taxes … kind of. I think the taxes on the invoice are just recalculated using the same rules as it was done on the Order. So they end up being the “same”.
One reason that Epicor recalculates them instead of just copying from the order, is that the taxes are based on the Ship To address. If the packer was created with a different Ship To than the release specified, then the taxes may be different. Again, all of this is from the automated processes - not the manual.
It sounded more like frustration than anger and it is understandable.
ShipDtl can also be many to one with InvcDtl if you use the option to combine packing slips lines.
At the end of the day there is a finite amount of time and resources that can be used for any number of bugs/enhancements/performance/cloud/kinetic/technical debt in a given release, so there needs to be a priority. Not sure how this is all reviewed but this is why it is recommended to always contact support so it can be tracked which features are most requested, there is also the Epicor Ideas site that could be used to submit this and let others vote.
I thought that each Pack Slip / Line Combo would make it own Invoice line. And that Combine Packers allowed you to have multiple [packers per invoice, not per invoice line.
