Looked into those already, yes. They believe they have nothing to do.
@JasonMcD oh for cripes sakes, so it lets you select the site, but then doesn’t return the data… sigh, here is the correct sites data…
Well, I got nuthin’ now. I’m going to repost your original Production image, for easier comparing side by side. That is definitely odd.
Yeah, I don’t even know why. Found that a few months ago. Bigger fish to fry and I just filed it away in the memory banks.
I’m going to have to disagree…
PartBin.OnhandQty is derived from the PartTran table. It doesn’t do anything related to the GL. The “Refresh PartBin” process, just corrects any errant values in the PartBin table, by walking through all the Part Transactions for that part.
The Stock Stataus Report “cheats” by taking the QOH in the PartBin table and subtracting out the transactions back to the SSR Date. It should actually do like the Refresh Process, and sum up all the trans from the beginning of time, up to the SSR Date. So while running the Refresh PartBin process will make the SSR appear different, it’s not actually changing anything related to the GL - even though the accounting department thinks they should be able to use SSR to reconcile the inventor accounts. Which they should not!
2 Likes
That looks like a “back-dated” transaction though. If you queried the system on 7/23, that 7/17 transaction wouldn’t be there and you’d observe a discrepancy between system and physical?
Like, in that case, I’m perfectly fine with the running total not in sync kind of thing.
Right, that’s what I said. That’s the problem. You get quantity out of thin air without the GL activity for it.
Well, without the GL activity at that moment - at the same time as the inventory is created out of thin air. I think your argument is that the GL activity had to have happened already and this gets the QOH in line with that.
But it’s possible that
- Different accounts were used over time (one for expense and then later one for inventory)
- Journal Entries have been done long ago (manually) to rectify the GL to the OH quantity for the account that it should live in now
Correct.
And I was unclear in those posts. The tran numbered 152806 should have bee the highlighted one (its the one that was out of order).
But either way, it shows that sorting by Tran Num could make the Running Balance column irrelevant.
@ckrusen Earlier this morning, I was poking around the BAQs because that is where I like to look at the tables, use Criteria to look at the data, and read the table / column definitions.
I ran across this, which makes me think that something happened to make the Bin qty -1, and then once the job receipt made the Bin qty reach 0, it gets deleted. Just a wild guess.
Erp.PartBin : Contains the Onhand quantity for a specific part in a specific bin location within a warehouse.
It is a subset to the PartWhse table.
These records are created or updated via Part maintenance, Receipt processing, Warehouse transfers or by physical inventories.
When the OnHand quantity becomes zero the PartBin record is deleted. There should never be any records that exist with a zero quantity onhand.
However…
“There should never be any records that exist with a zero quantity onhand”
==================== QtyOnHand | NonNettQty | TtlDemandQty
123302 VALVE DIR D02 HYD P A BIN 0 0 0
123430 Electronic Pro MISC P S 01A 0 0 0
Z422A TGS-60B ELECTR ELEC M S 1 0 0 0
Z423A ELECTRIC CIRCU ELEC P A 1 0 0 0
ExpediteFee Fee fo MISC M S 01071 0 0 4
PROGRAMMING FEE FEE FO MISC P S 01071 0 0 3
You are correct. A Bin Qty going to zero results in that record being deleted.
The Part Tran History form does not use the PartBin records at all. It uses PartTran records from the earliest date, and add /subtracts each later record (but with the TranDate as the order, not the TranNum).
The Running balance column won’t be affected by neither the “Starting Date:” on the Tran History form, nor the QOH in the PartBin.
2 Likes