Hi,
We have a process where we add some amount of inventory of an item that is then picked onto a production order. The process is posting a counting journal, then posting a picking journal. We have seen some cases where the on-hand "physical available" was wrong after that process happened.
Here is a screenshot of one of the cases:
After the production picking, there should be 0 left. but there was 9.61 left that I was able to re-count to zero. This means inventory transactions actually go below zero for this item.
Also, I would add that between the two journals, I added this because sometimes the picking wasn't working because it was saying not enough inventory:
inventSumReCalcItem = new inventSumReCalcItem(itemId,true,CheckFix::Fix); inventSumReCalcItem.updateNow();
Any idea how this could happen? The picking journal should have set the physical available to zero. Any idea where to look this fix this?
*This post is locked for comments
There is a job under System Administration\Periodic\Database called Consistency Check which allows you to validate if the stock quantity and value in InventSum matches with the values in the inventory transactions.
The job also has a 'Fix' option.
Regards,
Grzegorz
We ave removed the inventsum recalc, it was causing serious issues and we had to clean that all up. It seems like the process of the counting journal is not synchronized, and sometimes the inventsum is not refreshed before the picking. Instead of breaking the sums (the counting journal was doing its effects after the picking.. screwing inventory counts), we tell users to retry the picking if it fails.
The process works fine most of the time. The inventsum recalc was needed because sometimes the picking would not work because the inventsum wasn't updated fast enough. Does this mean I should remove the inventsum recalc and put some kind of timer between the two journal postings??
Edit: Also, this "bug" I am speaking of in my orinigal post doesn't happen all the time. It seems like a random glitch or some sort of concurrency problem (but the process is always running all in the same synchroneous thread, not batch involved). I am also really curious on how it is possible for the inventsum to be updated "later" after posting a counting journal. Is there an asynch job running somewhere to catch inventory changes? I really don't understand how the picking could say (sometimes) there is not enough on-hand while I just posted a counting for the exact amount needed.
If you need the inventsum recalc function, it probably means some buggy code. You should not be needing it.
My steps would be:
1. Verify that your dimension tickboxes are correct.
2. Verify that the correct dimensions are used on the created transactions.
3. Verify onhand stock before the 'process'.
4. Verify onhand stock after this process.
5. Recalculate onhand stock.
6. Review it again.
This should pinpoint where it goes bad.
So you don't use the new warehouse management system in R3? I think in this case you can forget all i said :-)
There are 0 rows in WHSInventReserve
I suspect there is no quick solution. If there is one tell me :-). But i remember we had problems after creating and posting journals. It happend on our Dev-System and after hours of debugging and 'corrections' we finally killed all transactions and created/posted the jounals again. Unfortunatelly i don't remember what the solution/problem was.
Edit:
I don't think it's your reservation hierarchy because in this case all OnHand would be broken. Search the WHSInventReserve for your Item/InventDim if you haven't already. Maybe you'll find a 'mismatch'.
If I have an item that is "bugged" by this behaviour, where can I look to see where there is a mismatch? Or is there anyway of doing a query to "check" that all is in synch?
Yes normally the Framework takes care of it. In our case the Reservation hierachy was broken and caused chaos. There was another case but i don't remember exactly what it was. I posted it her somewhere. I'll take a look.
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
André Arnaud de Cal... 291,228 Super User 2024 Season 2
Martin Dráb 230,056 Most Valuable Professional
nmaenpaa 101,156