BOM DB Lines not the Operations driving some calculations
If you look at this screenshot from a BOM, only after exposing the Operation DB ID, could I tell why I completed labor at Work Center 475, why it created an Inventory Receipt and completed a Production Order. Thanks to Auditing, I could see that even though the grid sorted by Operation ID, Acumatica thinks Operation 15 in Work Center 910 is the last step in the Production Order. The last two steps are still not Completed, the status is released, the first 4 steps are.
It created an issue for the obvious reasons. I would say that Acumatica is working as designed as when the last step is completed from a labor standpoint, it will create the Inventory Receipt. We completed Operation 20 in Work Center 475 and it completed all of the steps prior to.
But Labor is completing previous operations in Work Center Order, yet the Labor calculation to move to Inventory Receipt is using the Operation DB ID, so there is a level of inconsistency going on here.
Thoughts?
Page 1 / 1
@maichinger is this in your production database? or are you still testing? We recommend that your operations are consistent - for example: 0010, 0020, 0030
they should be the same length
10 = 0010
100 = 0100
@maichinger what is the AMProdItem.LastOperationID for this order? This is the value used during move transaction to determine if the entry is for the last operation. In your case from your screen shot it should be value 5
If it is not 5, then how are the operations being generated on the production order? customization? manually using production order details?
@maichinger what is the AMProdItem.LastOperationID for this order? This is the value used during move transaction to determine if the entry is for the last operation. In your case from your screen shot it should be value 5
If it is not 5, then how are the operations being generated on the production order? customization? manually using production order details?
5 is the last step but since the one qwith DBID #6 was added after, it gave it a higher DB#
The only labor on the JOB was posted to Operation 20 with a quantity
It created a move transaction which, by definition, if the last step on a labor entry has a quantity and it fulfills the order, a “move” or Inventory Receipt would be created.
The Production Order Details show this for each step:
It completed all the steps prior to the one on Operation 20, which I would expect. Leaving 2 more to complete.
But, since operation 15 has DBID of 6, it created the IN Receipt, and completed the Production Order. It appears that for one function, it’s using the Operation ID, and for one, it’s using the DBID.
It has nothing to do with the Operations or Work Centers being different lengths as it’s a text field and right justifying and the Operations are in the correct order.
@maichinger Operations are sorted in sequence by Operation CD. But the lastoperationid is important on the AMProdItem record to indicate which is the last operationid. The LastOperationID value is set automatically when the user is making changes on production order details. The operation CD has no value in code other than sorting for the sequence of operations.
I cannot tell from your last comment what the AMProdItem.LastOperationID value is. It must be value 5. Any other value is incorrect.
@maichinger Operations are sorted in sequence by Operation CD. But the lastoperationid is important on the AMProdItem record to indicate which is the last operationid. The LastOperationID value is set automatically when the user is making changes on production order details. The operation CD has no value in code other than sorting for the sequence of operations.
I cannot tell from your last comment what the AMProdItem.LastOperationID value is. It must be value 5. Any other value is incorrect.
My “last Operation” is 5, but since this was manually created, the last line entered was Operation 15 so it gave the Operation Id #6. It’s not doing any sort of re-numbering. If the Production Order was created from a BOM, it’s not an issue.
