Manufacturing, Distribution, and Internet Applications

[DGill]

Has anyone else noticed an increased occurences of inventory batches that will not post due to 'Dist and Tran Qtys Differ'?  We are getting it on a fairly regular basis and it is for items that have a Track Method of None.  If we move the item(s) to a new batch, we are typically able to post it without error and we have even had cases where the batch gives us the error and then the next day it works.  Any insight would be appreciated.  Thanks

We are currently on 7.30.2 w/the Hot Fix for Inv Cost Tiers applied (we had been getting this error as well)

[dbcoles]

Strange, hmmm. Do these items have stock UOMs that are larger than the purchase UOM or sale UOM? Are they distributed to many bins? We have not seen/ heard of this behavior so I'm throwing out a few guesses as to possible causes. How many decimal digits (Qty) do you have? If the quantities have been split into bins where repeated decimal digits occur, that could be an issue (same possibility with the distributions).

Otherwise, you may have found a bug...

[DGill]

Hi DBColes,

Thanks for the response.  That's the strange thing, I believe all our recent occurences of these have been items that only have 1 UOM involved so it should not be an issue of conversions or rounding errors.  Also, we are talking about items without any tracking (either lot or serial) so I don't think multiple bins would enter the equation.

For Quantity, we maintain our decimal places out to 4.

The common issue between these problem batches is that when opened up, the TranType/Count/Amount grid on the main batch screen is always empty even though if you select Enter Transactions, you can view the associated transactions.  Once I see that missing data on the main batch screen, I know I will not be able to post that batch due to this error.  It seems as though the

record(s) got corrupted somehow that prevents that summary grid from displaying correctly.

Thanks

[gstorres]

Hi DGill,

I too have not heard of this problem.  Can you research if the error is caused by the distributions being missing or the DistQty being different from the transaction quantity.  I noticed they give off the same error message during posting.

Run the following query and replace it with your own TranID.  If you get no rows, then the distribution is missing.  If not, what value do you see in the TranStatus field?

select l.TranID, l.TranType, l.TranStatus, l.TranQty, itd.DistQty from timInvtTranLog l join timInvtTranDist itd on l.InvtTranKey = itd.InvtTranKey where l.TranID = '0000000010-PU'

Also, you mentioned the items are not tracked.  Is the warehouse tracking quantity at bin?  Is it possible the transaction quantity was edited and then re-saved?  Is every transaction in the batch affected or just a few?  Finally, are you able to discern a pattern as far as when the problem tends to happen (i.e. throughout the day or maybe after a physical count)

[ddoucette]

Gerard,

DGill & I are working together on this one (sorry to have duplicated in my prior post) ... so to answer your questions ...

-  TranStatus is 5 (VOID), TranAmt 0, using your query & transaction ID filter
-  warehouse is not tracking quantity at bin
-  tran quantity may have been edited & resaved - not sure
-  all batch transactions may have same error but usually it's a subset
-  no discernable time pattern

Patterns we do notice:
- if line(s) with error are removed from batch and then re-added or added to new batch, the problem seems to go away

- error seems to occur with transactions that involve a quantity reduction; e.g., a physical count with count quantity less than frozen quantity or a negative inventory adjustment

Any sights?

[Ralph]

Interesting thread.  I'm upgrading to v7.30.2 this weekend.   If anyone is on this version and NOT seeing inventory transaction posting errors and would care to chime in or send me a message, you'd help me sleep better this week. 

[gstorres]

The really strange thing about this problem is that if you ran my query, it means the timInvtTranDist record still exists but it must have the wrong DistQty to trigger the validation.  To me, this indicates the transaction record must have been edited but the distribution was re-created with the wrong quantity.  Not sure how this can happen.

The second problem is having a TranStatus of 5 (Void) for a pending transaction.  We basically use the delete / insert approach to handle edits to distributions.  A parameter is the spimDistDeleteDistribution tells the code if it should change the TranStatus to void.  In an "edit" scenario, this parameter should be false.  I can only guess there is code that is passing the wrong parameter value.

Do you have customization that revolves around the problem transactions?  From what I remember, we did not change the distribution code much in v7.30.  Unfortunately, I have not run across this scenario so I would ask for you guys to keep trying to reproduce the problem.  Once you have a consistent set of steps, I would call our support dept and report the problem.

[ddoucette]

We have minor one-line customizations in two stored procs called when processing the batch.

Removing the customizations and re-running the register/post does not prevent the error.

Will try getting reproduceable steps.

Thanks.

[ddoucette]

We had another batch with this problem and the timInvtTranDist record is missing. 

timInvtTranLog has tranID  -DU, tranAmt  0, DistQty  NULL, TranStatus 5

Any way clues as to why the timInvtTranDist record would be missing or what that could mean?

thanks

[gstorres]

The condition of the records you described indicates that the transaction has been deleted.  Do you still it see the batch?  Are you getting an error during posting against this transaction?

btw:  What type of transaction has an TranID suffix of "-DU"?