# Epicor's Formula for ABC Calculation

Can anyone advise the specific formula Epicor uses to calculate ABCs in ERP 10? Looking for the details including where the set-up fields are utilized in the formula so I can duplicate the calculation and get the same results in a spreadsheet. Thank you!

I actually did a LOT of homework on this for some reason.

The basic idea is (qty used) x (cost ea) per part in the timeframe. BUT there is a big flaw in how it does that.

The report shows you some of its math, but when I did this in 2019, I was REALLY confused at why one part had almost double the â€śusageâ€ť of another - because we never use one part without the other. They were a special engine and its special fuel tank.

In practice, serialized parts had half the usage of backflushed parts.

The reality is more complicated. Usage is based on REALLY specific transaction types AND the method to achieve them. See pic of Excel.

After a long ticket with support, we figured out that it comes down to the fact the the reportâ€™s algorithm omits transactions (PartTran table) where Plant1 = Plant2. Howâ€™s that for obscure? Iâ€™m guessing the idea was to avoid STK-STK transactions. So why not just omit STK-STK transactions?!

Reportâ€™s math

Thanks so much for all the info, Jason! In my experience, the formula should be as simple as unit cost x usage, and then you apply the desired percentages for your ABC assignments. But I cannot make sense of that in the results I am getting. When I run the Calculate ABC Codes, I am including only historical usage â€“ no projected usage and no on-hands. We do not perform STK-STK transfers, as we have just one site, one warehouse and one plant. This should be simple, but I just cannot figure it out. Sure wish Epicor would simply state the formula in their help screens.

@Jackie_Braith you donâ€™t do bin in bin transfers in a single warehouse (STK-STK)?

I would argue that the calculation SHOULD be based on â€śUsageâ€ťâ€¦ and that the definition of usage is sometimes fluid (based on some companyâ€™s practices). Some companies only want usage to be considered only the Customer SHIPMENT and JOB Material Issuesâ€¦ while others want ADJUSTMENTS to be considered usage (for badly controlled backflushed parts). Some MIGHT want to consider outgoing transfer orders as part of the local siteâ€™s â€śusageâ€ť.
All that said, Epicorâ€™s usage calculations in ERP10 are hard coded. The ABC Code considers the current (Qty + Usage) * UnitCost to determine the total value of the partâ€¦ it then ranks those values from largest to smallest, and the first â€śxâ€ť percent of the parts are â€śA itemsâ€ť, the next percent are â€śBâ€ť and so on. Note that you are NOT limited to A, B, and Câ€¦ you could only have two (A & B) or have 5 (A, B, C, D, E) with different %'s than most. Also, you can manually control the ABC Codes for some parts and assign a â€śNâ€ť (No Count) so that those parts are skipped during physical/cycle counting.

1 Like

Yeah, itâ€™s not a formula so much as an algorithm. And it doesnâ€™t work the way they expect, anyway.

They created PRB0213695 to fix it in June 2019 after my case. It was â€śacceptedâ€ť by Development and it is categorized as â€ś2 - Defect, no workaround.â€ť It is not resolved nor does it have a target release, etc.

And, uh, I am not holding my breath for them to fix it.

@timshuwy is right (of course), you might as well develop your own algorithm, using a BAQ on PartTran.

Personally, I donâ€™t care enough to bother. We only have A B and C, so the number of B parts that should have been A parts or whatever has got to be miniscule, and itâ€™s all a bit subjective anyway.

The built-in wizard gets us close, and thatâ€™s good enough.

2 Likes

@JasonMcD makes a great point. Sometimes we worry about the â€śexactâ€ť nature of things, but when it comes down to it, all the ABC Code is calculating is how often an item gets automatically counted. If you have an item that is borderline between an A & B, it might flip/flop every time you run the report. If you want, you can always manually override it at the warehouse level.
But also note, Epicor controls ABC at the WAREHOUSE levelâ€¦ an A item in warehouse 1 could be a C item in another warehouse. This could (and often is) appropriate. My â€śFinished Goodsâ€ť warehouse has â€śAâ€ť itemsâ€¦ the value of items in finished goods might be \$1000s of dollars each. The â€śRaw Materialsâ€ť warehouse has a bunch of items and all of them are less than \$10 each. If we applied ABC Across the entire site, then none of my A items would be in Raw Materials.

Donâ€™t forget there is a hierarchy for assigning codes too. Sometimes we think Epicor is doing something wrong only to trace it through and find an override somewhere (Company Config, Warehouse, Part Site Warehouse).

Makes it really interesting when people want custom reports/dashboards but donâ€™t account for that hierarchy. Things wonâ€™t reconcile because â€śEpicor is wrongâ€ť, when it turns out Epicor automatically figures some of that stuff out in the background.

Jenn

1 Like

I just found an interesting glitch on a multi-tenant customer.
We have set up ABC codes as follows

When I ran calculate ABC codes and used the PDF format

It took all of the parts that had no usage or inventory and made them â€śXâ€ť
when I ran calculate ABC and used the CSV or ExcelData only, it did not assign the â€śXâ€ť code.
Big difference because there were 20,000 parts out of 27,000 that we didnâ€™t want to cycle count.

So was MT the reason? Are you thinking itâ€™s looking at all sites in all companies and doing the math that way? (Even different MT customers?) Yikes if so.

True to form
When I tested this in a Public cloud customer the results were reversed.
The PDF did not assign the â€śXâ€ť but the CSV did.

Iâ€™m going to test this on an on premises installation.

Hi Bruce. Any update on this issue? I have a similar one in 10.2. I have the same ABC definition you have and when I run the Calculate ABC, all parts that should be X are C, only for one plant, whatever the report format I select. There is no site/warehouse ABC config.

the way that ABC Code is calculated, if your C has 100%, then the balance of all the parts that are not A or B already will become C items.
I believe that you need to do something like:
A = 80%
B = 95%
C = 99%
X = 100%
This will cause the last 1% of the product value to fall into the X category.

BUTâ€¦ that would mean that SOME of the items in X would actually have value, which i think you are trying to avoid.