Labor Hours are rounding (RUNL) when routing is attached to a work order


Active Member
Does anyone know if there is an ESU to fix decimal rounding when the routing from F3003 is attached to the work order (F3112)? I am on E900, tools release 8.98.34. If there is an ESU to fix it, please kindly provide the ESU number or search criteria. I can't find it on Oracle Support. But, I think it's there because I have heard of this problem before.
I am not trying to be a jerk but are your decimal points out of place in the above example?
Yah - I'm confused too.
3.69 rounding to .04?
If indeed that's what happening then its not a rounding issue but a decimals issue as Gomer alludes to.

What release are you running Phanson?
3.69 is rounding to .04. The environment where this is happening is E900, tools 8.98.34. If I do it from my 9.1 stand alone, it works fine.
Did you just upgrade the tools release to 8.98.34? We were previously on a Tool 8.98.something prior to upgrading and I was not aware of this type of issue? Any custom code?
No custom code. The client has never used mfg accounting before and I think they have been on 8.98.34 for some time. Does anyone know of any areas I should look at in the configuration of costing and mfg accounting? I can't seem to find any problems. That's why I was leaning towards an unapplied ESU.
Looks like a data dictionary issue. I'd say the display decimals on one of your quantity DD items is not consistent which is causing the variable labour calculation fail.
In addition to checking the Data Dictionary make sure there is not a unit of measure issue related to the work order that is causing the hours to change by a factor of 100.
Another possible cause is that the time basis code on the labour routing step is not set to U.
I checked everything and setting the time basis to "U" has resolved the rounding issue. But, what I see now is that all of the actual labor costs are two decimal places too much. For instance, the standard direct labor cost is $27.1281, which is correct. The actual amount is $2,712.8100. As you can see, the numbers are correct. But, the decimals are off. This is creating a variance where there shouldn't be one. Any idea where I should look?
What kind of cleanup?

Which variances are out? Engineering, Planned, Actual? This should tell you where the issues are. After changing the time basis code did you run a full frozen cost update? Have you adjusted the accounting cost quantity to match? If you've run a frozen cost update did you still have open work orders that were created when the time basis was not U? If the frozen costs were correct before you made the changes to the time basis then what are the frozen work centre rates?
I changed the time basis to "U". Since doing that, the standard and actual hours line up perfectly for the B1 cost, for example. But, the actual amount when compared to standard is off by a couple of decimal places. Standard amount is $25.65. Actual amount is $2,565.00. What could cause that? I'm using the work center costs, so I shouldn't have any variance.
Last edited:
Standard amount is $25.65. Actual amount is $2,565.00. What could cause that?

Not running a frozen cost update after changing the time basis could cause that. Your work centre rates will be frozen and multiplying against the run labour hours however your standard B1 cost will be coming from your last frozen cost update for the manufacturing item. You've mentioned your actual variance but what values are you getting for the engineering and planned variances?