Why the running total is nonzero on the first transaction in Part Transaction History Tracker (and why I boycott Refresh PartBin QOH From PartTran)

Kinetic ERP
1

I finally wrote this up and I’ll submit it to support. Wish me luck.

So, if you have ever seen something like this, where the starting balance is not zero, naturally you conclude Epicor is stupid.

In fact, there is a perfectly logical reason for this. If a part spends some amount of its life as non-quantity-bearing and some of it as quantity-bearing, Part Transaction History Tracker (PTHT) simply cannot discern what transactions took place during the non-qty-bearing period and which were from the qty-bearing time, since PartTran does not record this.

And FYI, all of these in this picture are from a non-qty-bearing experiment. Even the STK-MTL. There is no such transaction as UKN-MTL. Same is true for STK-CUS; there is no UKN-CUS.

After doing all of these transactions, I switched the part to be qty-bearing, and it thinks I started with 20 on hand.

image
image815×477 124 KB

Support’s recommendation is that clearly something went wrong, and you must run Refresh PartBin QOH From PartTran to “fix” it.

This is what it looks like after being “fixed.” Now I’ve lost 20, and with no GL activity, which really, really irks me.

image
image782×514 137 KB

Oddly, I actually don’t hate the implementation as is - except for one critical problem: Support doesn’t even understand this (see KBs referenced in the PDF). They tell you to fix what is not an error.

So I am putting this out there for general awareness. Don’t use the Refresh PartBin QOH From PartTran process, and try to educate people that a nonzero starting balance isn’t a deep-seeded flaw in the production database; it’s just a flaw of Part Transaction History Tracker.

The Effect of Quantity-Bearing on PTHT and Refresh PartBin.pdf (1.2 MB)

2

Never use refresh part bin from QOH. It’s so so problematic. If there is an inventory issue I find its better to get a data fix from support to explicitly fix it.

1 Like
3

At first I was thinking it had a Database Purge and Summarize feel to me, except that usually will show a summary of all the transactions that were purged to that point… then I remember people who thought Direct SQL writing to the database was a plausible option…

But, the most likely culprit is usually Epicor Developers broke something in a report, tracker, dashboard, or business object. LMAO

4

@JasonMcD - What does the InventoryTran field show for your test transactions?

I’d have guessed that a part tran that happens while the part is NOT QtyBearing, would have that field cleared (its a boolean). Then any process that needs to calc the QOH would only include the parttran records with that field set.

The part tran history screen has some quirks. One being the running total is calculated in the query, so changing the sort of the results will make that field meaningless (with respect to totals in the rows above and below it.)

5

Here you go:

image

Reminder: STK-MTL was done while non-qty-bearing.

6

I have a situation that I believe is different. We do not use Non-Quantity Bearing (beyond one specific part). In one company, I have an accountant that runs tight control over inventory and transactions. She discovered one of these “anomalies” in her last month’s closing. She discovered a valuation difference and tracked it to a part. Her investigation showed that the quantity onhand per Stock Status was 0 on the previous month. (we can talk about using Stock Status also. None of our current accountants were around during Epicor installation). The difference in the current month’s closing quantity was this ghost quantity now affecting the beginning Running Total in the PTHT. After running the process, our quantity was back in line.

7

It is such an improvement that enough errors have been fixed in the software, that most people don’t have to run the “recalculate summaries” regularly. In 9.05 I’ve seen it run monthly, weekly, or even more often because the warehouse summaries got so out of whack.

8

@scott Oh, I don’t doubt that there exist some other reasons for a discrepancy. I just heavily disagree with Epicor support that their first and only answer is, “Your database is corrupt; it’s your fault, not ours.”