An issue was reported where a job was received into inventory, but the on-hand quantity afterwards did not add up. It’s a new stock, qty-bearing, manufactured part, and this is the first job ever being received. Our bins are all standard and nettable.
Personally, I unhide the TranNum column and make it the far left column, then I can sort by the that to ensure I’m looking at the order the transactions happened in.
What’s the ASM-INS transaction actually doing? Does that record have the “Inventory Trans” box checked?
It looks like:
The QOH is -17 before the MFG-STK (at time: 28608).
The above mentioned MFG-STK for 17 bumped the QOH from -17 all the way up to zero.
The 2nd MFG-STK (at time: 41176), added another 17, taking the QOH up to 17.
A Transfer Order Shipment (the STK-PLT) occurred for 17, taking the QOH back down to zero.
I’d focus on why it is starting with a QOH of -17. Try setting the cutoff date to 12/32/2099, to see if maybe some made an errant dat entry somewhere.
That’s my experience. Only PartTrans records with “Inventory Trans” checked affect the QOH. Therefore the ASM-INS transaction shouldn’t affect the “Running Total”
The “Running Total” column in the Part Tran History isn’t stored anywhere. It is derived based on the sum of the PartTran records leading up to it. I doubt it would affect it, but there is a Process that you can run to re-calc the QOH based on PartTransactions. There’s a “Report Only” mode that would show you if any of the QOH’s (which are stored in PartBin) don’t give with the sum of the part tran records.
Also … Make sure there’s no Sort applied to the Grid. ( I think a right click on the grid will give you a pop-up menu and have a “Remove Sort” option)
What this shows, is that the Running Total isn’t based on the order of the transactions, but rather the order of the “Tran Date”
In my example the +100 ADJ-QTY happened before the -5 ADJ-QTY. But the tracker displays the -5 QTY-ADJ “first” (on the bottom of the grid), because it has the early transaction date. And then does it does the math starting there.
I see what you mean, unfortunately the “Running Total” confusion is only part of the issue. The main thing is the actual QOH for that part in PartBin table isn’t getting updated after the receipt to inventory. I was assuming it was related to that running total.
I loaded our Test environment with a backup that was directly after the initial job-receipt-to-inventory transaction. This is the transaction where people noticed issues (since they couldn’t do anything with the inventory they just received in “No QOH for part”).
So the main issue (in addition to the Running Total column not making sense) is that after the receipt to inventory, our QOH in the bin it’s received to does not reflect the transaction quantity. Part tracker claims there’s nothing on hand at all.
I’m going to try that QOH recalc for the heck of it.
Another thing I noticed for this part (it’s relatively new), is that it’s a manufactured part, but it was received into the RAW bin rather than the FG bin. There is no primary bin set up on the part. Do you think this could be part of the issue?
Tran 438955 was not an Inv-Tran so its Tran Qty of 3 has no effect on the “Running Total”. But no idea why the Running total is already at -17.
Tran 438988 (MFG-STK) was for +17
The Running Total (after the MFG-STK added 17 to -17 (the prior Running Total)), gives you the zero QOH.
I really think the problem lies with why the Running Total is starting with -17.
And you say a BAQ of the PartTran table (filtered to just the P/N in question) shows no other records than the ones displayed in Part Tran History?.
We don’t have the QC module, so I’m not up to speed on the Inspection process … But it seems odd that an ASM-INS would be the first record created for a new manufactured part.
Any chance the part table was changed after the part was first added to a Job? Like if it was non-Qty Bearing when the job was created, and some transactions performed, but then changed to Qty Bearing when later transactions were done.
Yes, I filtered the partTran table just for that part. No other records show. I loaded a copy of the db just before the MTL-STK transaction too, and the “Running Total” for the ASM-INS transaction said 0. I received the job to inventory again too, received it to that same RAW bin, and the QOH WAS updated this time. Haven’t been able to recreate the issue.
The ASM-INS transaction was the first one for this part since there was a nonconformance reported on the part’s first job. I THINK that makes sense.
I’ll check the change log / previous backups for part table changes, good call.
Recently went live on E10 in mid-September. Today, while preparing for Physical Inventory, we ran across 2 job receipts having very similar behavior. Running Total qty was -1 for a while, even though the users never observed an issue with it in E9. The receipt to tie up the job for PI just raised the on hand to 0.
Now I am curious how many more might be out there.
The Inspection (-INS) transactions is taking the quantity off of stock. If you click Part Locations then Inspection & Retrieve you’ll see the 17s in there.
It’s just that the -INS transaction was only for quantity of 3, and it’s not reflecting that. When I completely redid the transactions using a backup I got the expected results, could not recreate the issue.
Ours is not related to inspections. All transactions prior to 9/14 were done in E9. Not sure how those issues would not have raised a flag going negative. I have a hard time believing it was that way in E9, but maybe.
@Michael_Ramsey I think, like @ckrusen said, it’s an issue of going from non-QB to QB. The screen calculates backward from OH today, and doesn’t understand that the QB setting can change. This seems really likely in your case, since it started out life as a make to order part (MFG-CUS).
@Asz0ka The only oddity I have seen that comes close to your scenario is the fact that you are multi-site. We had an issue last month where a job auto-received to a different site and created a MFG-STK in site A but the quantity showed up in site B. Yeah.
So, if you deliberately to job receipt to inventory to a different site, it’s a MFG-PLT transaction. But an auto-receipt goes haywire.
But your reference column doesn’t say “auto-receipt from op” whatever, so I guess it’s not that, either.
Would Change Log show the flip of QB? For this part, I only see 3 changes, Non-Stock flag flipped around back in Jan-2019, twice, and then min order qty changed from 0 -> 1.
PS: Well, I can research Change Log, appears those things are configurable,
@Michael_Ramsey have you tried using the Refresh tools on that specific part? I would try the Refresh PartBin QOH From PartTran on the specific generate the Report Only first and see what the results are. If there are no results try the Refresh Part Quantities and Allocations.
I’m always going to sound the alarm on “Refresh PartBin…” That is such a dangerous tool. It’s like editing the OH quantity in the SQL DB directly. It’s “This is what I wish had happened, but I don’t want any GL activity to go with it.”
If you really have none on hand today, for example, don’t tell the system to lie to you so that you have to go adjust it.
A starting running total of -1 can be accurate, as far as the limitations of Epicor go.
One thing I’ve found in the Part Tran History form is that the Running Balance column is only accurate when the grid is “unsorted” - meaning the data rows are in the order that the internal query process returns them.
For example, the highlighted row is “out of order” if you go by the TranNum, but in order by TranDate.
The running balance is correct, as the prior balance (line below it) was 45,693 FT, and this transaction (a STK-MYL) reduced QOH by 450 FT, resulting in a balance of 45,243 FT.
If it is sorted by TranNum, you get:
And the Running Bal for the highlighted row is not equal to the row below it +/- this row’s tran qty.
