Refresh QOH from PartTran - no records to be updated, but there are

[skhayatt (Sam Khayatt)]

10.2.700.6

Have read through the many posts on this topic, but none fits my situation.

We have one part (there may be others, but this is more about the process) where the QOH in PartTracker (both bin and warehouse) is one number and the Running total from Part Tran Hist is another. Part Tran Hist is correct (verified by physical count). Part Tran History running total is greater by about 130,00 units.

So, I ran the Refresh PartBin QOH Report Only and it found no records.

Anyone have thoughts on where to go next?

And… just to add to the fun: Between this morning and this afternoon, the Bin QOH has decreased again with no corresponding Part Tran record.

The quantity decrease today was for the same amount as a shipment yesterday, but that shipment was already included in the Part Tran.

Someone somewhere (cannot find the posting) mentioned that transactions sometimes get delayed. Is there a place to look for those.

This part is NOT non-stock and IS quantity-bearing.

Thanks.

[JasonMcD (Jason McDermott)]

That’s kind of unsettling…

Do you have a BPM that might be causing this?

Generally I am a believer in PartTran, as I have argued recently…

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

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 …

But you’re seeing PartBin change erratically?

[andrew.johnson]

What are these tables for: PartBinDeferred and PartQtyDeferred

SELF-PROMOTION: During my “Case of the Unusual” at Insights 2016, one of the examples I used was a Deferred table and the various ways to triage issues with it. So, those on the fence on Insights 2017, come on down! Additionally, I’ll be discussing some of my favorite things about 10.1 at the MN EUG this week, and this will be one of the topics I’ll be speaking to. Deferred tables are there to eliminate contention. When you have processes like MRP with multiple threads (processors/schedulers…

@aidacra

Deferred tables are there to eliminate contention. When you have processes like MRP with multiple threads (processors/schedulers) and what happens if two of those both need to change the PartQty? Locking/blocking/deadlocks ← fun fact: deadlocks are almost 100% software issues assuming of course that there aren’t any external processes in play. So, what we did instead is for processes that have current threads trying to update the same records (MRP, Posting) we created these deferred tables to insert a new record into the deferred table instead of updating the actual record directly to avoid the contention. After the transaction is complete, the actual record is updated - so in practice, it isn’t slower. There is some additional logic that says that after a period of time if that record is in the deferred table too long (~15 minutes I believe) it will process it immediately like if the appserver went down in the middle of processing - this is triggered from the taskagent.

[skhayatt (Sam Khayatt)]

I did see that post.

Just found out that the person doing our shipping is checking as “shipped” items that will not ship until tomorrow or Thursday. I think both those shipments can account for the difference.

What is weird is that she did the same thing last week and I did see that future-dated transaction in Part Tran Hist but the two from today are not there.

I am tempted to unship them and see if the bin inventory matches Part Tran.

Sigh.

[skhayatt (Sam Khayatt)]

Thanks. Will BAQ these and see what I can see. Hope they are there.

[ckrusen (Calvin Krusen)]

When a packer is created, the user can specify a future date. Marking it SHIPPED will create a parttran record with a sysdate of today, but the trandate will use the date on the packer.

I believe the Part Tran Tracker has a cutoff that defaults to today. So that packer wouldn’t show unless the cutoff date was adjusted.

The million dollar question is, “when is PartBin updated?” The instant the packer is marked shipped, or by some other process that happens when the TranDate is reached?

[skhayatt (Sam Khayatt)]

When the order is shipped (in the system, which may or may not be in reality), it moves into the “picked” category Part Qty.

If we are just looking at Part Tracker, the inventory is decremented once it has been picked.

Will look tomorrow for the Part Tran transaction. It was odd that over the weekend I could see Monday’s transaction in Part Tran but that today I cannot see tomorrow’s.

[skhayatt (Sam Khayatt)]

I could not find these tables when trying to BAQ them… but the answer was future-dated shipments. Why she did that, I have no idea.

And just to close the loop – the Refresh QOH did not find any record to update because it knew about the future-dated transactions and I did not (at the time).

I am hopeful that everything will be back in synch on Thursday, when the second future-dated shipment goes.

Thanks all.

[JasonMcD (Jason McDermott)]

@skhayatt

the answer was future-dated shipments

Been there also. Sorry I didn’t think of that.

I’ve had transactions in 2107 (not 2017). That is an annoyance of PTHT, that it cuts off at “today.”