Share
Report
46I think BC has changed how backward flushing on components gets calculated in Wave 28.
Problem:
Problem:
I have a production order for 100 of Item A, that on the components screen shows it will consume 36.0904 SQFT, for backward flushing.
We add the lot tracking (lot has plenty of inventory available).
We post the finished goods amount of 100.
We click change status and finish to get BC to post the consumption.
We get the error: "Qty. to Handle (Base) in the item tracking assigned to the document line for Component 1 is currently 36.0904. It must be 36.0948..."
Background:
I have Item A that uses a lot tracked Component 1.
We do not have any extensions that change the way production order posting is handled. The error details does not show any extension code units firing for the error either:
"Tracking Specification"(Table 336).TestFieldError line 12 - Base Application by Microsoft version 28.3.52162.52328
"Item Jnl.-Post Line"(CodeUnit 22).SetupSplitJnlLine line 75 - Base Application by Microsoft version 28.3.52162.52328
"Item Jnl.-Post Line"(CodeUnit 22).PostSplitJnlLine line 4 - Base Application by Microsoft version 28.3.52162.52328
"Item Jnl.-Post Line"(CodeUnit 22).RunWithCheck line 16 - Base Application by Microsoft version 28.3.52162.52328
"Prod. Order Status Management"(CodeUnit 5407).PostFlushItemJnlLine line 11 - Base Application by Microsoft version 28.3.52162.52328
"Prod. Order Status Management"(CodeUnit 5407).FlushProdOrder line 107 - Base Application by Microsoft version 28.3.52162.52328
"Prod. Order Status Management"(CodeUnit 5407).ChangeProdOrderStatus line 21 - Base Application by Microsoft version 28.3.52162.52328
"Prod. Order Status Management"(CodeUnit 5407).OnRun(Trigger) line 14 - Base Application by Microsoft version 28.3.52162.52328
"Released Production Order"(Page 99000831)."Change &Status - OnAction"(Trigger) line 3 - Base Application by Microsoft version 28.3.52162.52328
"Item Jnl.-Post Line"(CodeUnit 22).SetupSplitJnlLine line 75 - Base Application by Microsoft version 28.3.52162.52328
"Item Jnl.-Post Line"(CodeUnit 22).PostSplitJnlLine line 4 - Base Application by Microsoft version 28.3.52162.52328
"Item Jnl.-Post Line"(CodeUnit 22).RunWithCheck line 16 - Base Application by Microsoft version 28.3.52162.52328
"Prod. Order Status Management"(CodeUnit 5407).PostFlushItemJnlLine line 11 - Base Application by Microsoft version 28.3.52162.52328
"Prod. Order Status Management"(CodeUnit 5407).FlushProdOrder line 107 - Base Application by Microsoft version 28.3.52162.52328
"Prod. Order Status Management"(CodeUnit 5407).ChangeProdOrderStatus line 21 - Base Application by Microsoft version 28.3.52162.52328
"Prod. Order Status Management"(CodeUnit 5407).OnRun(Trigger) line 14 - Base Application by Microsoft version 28.3.52162.52328
"Released Production Order"(Page 99000831)."Change &Status - OnAction"(Trigger) line 3 - Base Application by Microsoft version 28.3.52162.52328
Component 1 has rounding precision of 0.0001 in both the item card and the UOMs. This is setup like this because when purchasing the material, we have UOMs like LM1080 (Linear Meters 1080mm Wide), LF60 (Linear Feet 60 inches wide). That material gets consumed in SQFT which we have set as the base UOM. For the UOM LM1080 the qty per unit of measure is 11.625, this is to make sure when receiving Component 1, there is no math to be done. We have a scanner with IWX that allows us to receive in LM1080 under each lot the material comes in as. Before we changed the precision, we would get errors posting receipts. Since that update we made mid last year, we have not had an error come up for rounding for converting UOMs.
The BOM for Item A for Component 1 is 0.33306 SQFT with 8.36% Scrap Rate.
That math works out to 36.09038 or 36.0904 rounded.
- If I take the scrap % out of the equation, the error changes to: "Qty. to Handle (Base) in the item tracking assigned to the document line for Component 1 is currently 33.306. It must be 33.31..."
- (In Sandbox) I removed all inventory for Component 1, update the UOM rounding precision to 0. On the components it shows it wants to consume 37 SQFT for the 100 finished goods, this posted with no issue, but this would be an over consumption. Since receiving the Component 1 could be some decimal since it needs to be converted and its lot tracked BC won't allow an over consumption, so someone would need to update the qty of that lot which is not right either.
- Changing the rounding back to 0.0001 the error is present again.
- Creating a production order with a material that I have not been notified about for 100 for the same sized item produces the error there as well.
- Updating to 28.3 does not solve the issue, I did see that there are some bug fixes and the one that caught my attention:
| 636568 | Address incorrect rounding of 'Quantity Per' on Production Order Components after upgrading to BC27. | Manufacturing |
The rolls of material are various lengths. The amount of Item A we get out of Component 1 will be different depending on the size. That being said sometimes there is no error at all when the rounding matches.
Since July 2nd 2026 we've had the error popup on random production orders across multiple material types that have not changed since mid last year and some new materials we started using this year. Prior to July 2nd there was not any issues. We updated to 28 June 12th but in June we were mostly fulfilling and packing a large order rather than creating new finished goods.
Our workaround is to change the flushing to manual and post the consumption ourself, which has its own pros and cons. I am wondering if anyone else is having this issue or if maybe I am missing something on a setup that was now changed. I am at a loss.
Categories:
I have the same question (0)
All responses (
Answers (
