Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.7K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 317 Dynamics CRM
- 110 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 385 SQL Performance
- 33 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 259 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Routing Line - Run Time
Fisherman
Member Posts: 456
All -
Our users in one facility have elected to track all routing line run times in hours. While I'm not crazy about this idea, this is the decision that has been made.
The issue is that some of our operations only take seconds to complete, which of course, causes rounding error (1/3600 = .00027777777777777777....) because the routing line has the precision set to 5 decimal places (.00028 * 3600 = 1.08). Because of that, they have asked that we increase the size of the field, hopefully to decrease the severity of the error, from 5 decimals to 10 (.0002777778 * 3600 = 1.00000008).
I'm not satisfied that this will "solve" this problem, though (nothing will remove the rouding error unless we can specify times in seconds - I'm only referring to reducing the rounding error) because I don't know to what other fields this value may be posted, or what variables in forms/tables/codeunits may have a precision set to 5. Does anyone have any insight into this?
Thanks.
Our users in one facility have elected to track all routing line run times in hours. While I'm not crazy about this idea, this is the decision that has been made.
The issue is that some of our operations only take seconds to complete, which of course, causes rounding error (1/3600 = .00027777777777777777....) because the routing line has the precision set to 5 decimal places (.00028 * 3600 = 1.08). Because of that, they have asked that we increase the size of the field, hopefully to decrease the severity of the error, from 5 decimals to 10 (.0002777778 * 3600 = 1.00000008).
I'm not satisfied that this will "solve" this problem, though (nothing will remove the rouding error unless we can specify times in seconds - I'm only referring to reducing the rounding error) because I don't know to what other fields this value may be posted, or what variables in forms/tables/codeunits may have a precision set to 5. Does anyone have any insight into this?
Thanks.
0
Comments
I think to know the fields, you can check capacity ledger entries. The run time is posted to capacity ledger entry. The codeunit will not record the run time
Don't be unsatiisfied, you can check the item ledger entry and value entry that there is no run time there. The effect of run time rounding will focus on capacity unit cost (can be seen in capacity ledger entry) and finally will influence your cost of good manufactured (COGM).
I am not sure there is another form/table other than routing and capacity ledger entry.
Rgds,
sea-navision-community-subscribe@yahoogroups.com
detail in:
http://sea-navision-community.blogspot.com
I would like to share my opinion about rounding in Navision, when I check cost per unit decimal in value entry, I check amount and try to add decimal, it is prohibited, the error message will appear but in cost per unit, you can add only until 5 decimals like what you've said. Is it mandatory in
Navision ? meanwhile in production BOM, I have ever set until 10 decimals, it set in the property.
I am not so sure that developer will be able to modify it. however, have you asked your developer or NSC consultant ?
Rgds,
sea-navision-community-subscribe@yahoogroups.com
detail in:
http://sea-navision-community.blogspot.com