You’re offline. This is a read only version of the page.
5,701
Prerequisites:
The issue
When opening the stock count entry window the Allocated Qty shows zero. I would expect it to show the qty allocated to sales orders and other inventory transactions, the same value as is shown in stock level enquiry for that location and Bin.
If the count finds a shortage and for example, say in the above 90 are removed by the stock count. No warning dialog that there are qtys allocated will occur. The stock count will allow creation of its variance transaction. - hence on returning to stock level enquiry for that location and item, it now has a -ve value for stock available, as the qty allocated remains what it was and there is no on hand stock! The stock has been removed without deallocating the stock from the sales orders.
This is seriously messing up the inventory figures, as you can imagine.
My thoughts
The stock count entry is showing items by bin, when multiple bins is turned on, my assumption as to what is happening is that the Allocated Qty shown in the grid is the allocated qty from the Bin. The problem being that Bin allocations are at another tier to location allocations and are disconnected. Yes they are relevant but so are stock allocations to locations.
We use a separate fulfilment process so cannot allocate stock from Bins at order entry or the qty fulfilled is affected.
I am asking if this is expected behaviour as I would not expect to be able to corrupt our stock availability and allocations like this.
*This post is locked for comments
Tim,
You made me smile from ear to ear, very amusing!
Gut figures here:
1. Allocations in IV00102 (IV Quantities Master) = 99.999% confident
2. Allocations in IV00200 or IV00300 (Lot/Serial) = 98.5% confident
3. Allocations in IV00112 (IV Bin Quantities) = 99%
Already have suite of SQL jobs running integrity checks throughout the day and raising notification when any record steps out of line, at which point a precision SQL strike is made on the offending records and the world is happy again.
With this problem, found that if I don't allow the stock variance to post and go in to edit it the generated variance transaction in the item transaction window, at that point GP says NO-NO, you can vary beyond what is available. Thus it must be the stock count entry window at fault for not being "location allocation aware" in addition to being "Bin allocation aware".
I need a quick solution to this for now so I'm going to trigger an integrity check SQL script on the before event of the Process button on the stock count form to run the following, then pop a dialog with a gird showing any results to user and then ask them to deallocate orders/transactions causing the allocation before letting them create the variance by processing the stock count.
A more finesse way would be to do something on the lines as they enter the values, but that is for another day, would be more involved -totalling up table buffer values and what is in IV00102.
SELECT
IV10301.STCKCNTID
,IV10301.ITEMNMBR
,IV10301.LOCNCODE
,SUM(VARIANCEQTY) AS VarianceQty
,SUM(QTYONHND - ATYALLOC) AS LocnAvailQty
FROM IV10301
JOIN IV00102 ON IV10301.ITEMNMBR = IV00102.ITEMNMBR
AND IV10301.LOCNCODE = IV00102.LOCNCODE
GROUP BY IV10301.STCKCNTID, IV10301.ITEMNMBR
,IV10301.LOCNCODE
SUM(QTYONHND - ATYALLOC) + SUM(VARIANCEQTY) <0
I myself have asked the very same questions for a very long time. My observations have lead me to assign a "trust confidence level" in the allocation numbers presented in the Inventory Module of Dynamics GP.
1. Allocations in IV00102 (IV Quantities Master) = 99.999% confident
2. Allocations in IV00200 or IV00300 (Lot/Serial) = 99.5% confident
3. Allocations in IV00112 (IV Bin Quantities) = 98%
These guesstimates are for a ~60 user concurrent company. They get better in smaller companies and a little worse in larger ones.
The Manufacturing module leads to some interesting "phantom" allocations (zombie documents - thy won't die). And Field Service has it's quirks as well.
So, my answer to your final question:
"Lower your expectations (slightly)."
Tim
P.S.
Our users are pretty good at detecting and reporting this stuff. My support group is also good at fixing them on the fly.
We (full) reconcile monthly.
If you seeing a lot more than I guess I see, customizations can interfere with some of the work GP tries to do. This may not be a problem for you, as you are a development resource here on the forum. You may want to run a SQL job first thing to report these discrepancies.
I believe the cause lies in the complexity of the dexterity code, the "layers" that need updating, and "stupid unexpected user tricks."
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,113
Super User 2024 Season 2
#2
Martin Dráb
229,918
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (