Item Journal "Unit Amount" and "Unit Cost" fields

mariussw
Member Posts: 52
I am writing this after resolving some uncertainties and also having read older threads on this topic. These two fields on the Item Journal is often a source of confusion to users.
Entering a value in any of these two fields will cause the system to duplicate the value in the other field. (Conditions do apply).
However it is possible to have different values in the fields under the following circumstances. How?
Enter Quantity. Enter Unit Amount. The system updates Unit Cost accordingly. Change the value of Unit Cost. Unit Amount changes accordingly.
Now change the Quantity. Unit Amount changes along, but Unit Cost remains the same. Now Unit Cost and Unit Amount is different.
Which of these values get posted to the value entry? The Unit Cost Field (Tested with Positive Adjmt). It is worth knowing which value posted as the cost, as a user unknowingly can cause the values to be different and the effect may not quite be expected.
It is also worth while to know that if the Entry Type is Positive Adjust or Purchase, Unit Cost = Unit Amount, Rounded by "Unit-Amount Rounding Precision" from G/L Setup.
For Negative Adjustmt or Consumption, Unit Cost = Unit Amount (not rounded).
And if Entry Type is Sale? Well, then Unit Cost does not relate to Unit Amount.
And what if we enter a value in Unit Cost?
For Purchase, Negative Adjmt, Cosumption: Unit Amount = Unit Cost (not rounded);
For Positive Adjmt: Unit Amount = Unit Cost (rounded by GL Setup "Unit-Amount Rounding Precision").
And if a Entry Type is Sale? Likewise then Unit Amount does not relate to Unit Cost.
If one enter an Item Journal Line with Type=Sale, effectively issuing from inventory, and the Unit Cost is changed, the entered unit cost is posted to the value entries. Hence causing deduction in stock at a different cost than the cost established by the costing system. Something I am not particularly in favour of. Though anyone of cause can comment on the practicality thereof.
Entering a value in any of these two fields will cause the system to duplicate the value in the other field. (Conditions do apply).
However it is possible to have different values in the fields under the following circumstances. How?
Enter Quantity. Enter Unit Amount. The system updates Unit Cost accordingly. Change the value of Unit Cost. Unit Amount changes accordingly.
Now change the Quantity. Unit Amount changes along, but Unit Cost remains the same. Now Unit Cost and Unit Amount is different.
Which of these values get posted to the value entry? The Unit Cost Field (Tested with Positive Adjmt). It is worth knowing which value posted as the cost, as a user unknowingly can cause the values to be different and the effect may not quite be expected.
It is also worth while to know that if the Entry Type is Positive Adjust or Purchase, Unit Cost = Unit Amount, Rounded by "Unit-Amount Rounding Precision" from G/L Setup.
For Negative Adjustmt or Consumption, Unit Cost = Unit Amount (not rounded).
And if Entry Type is Sale? Well, then Unit Cost does not relate to Unit Amount.
And what if we enter a value in Unit Cost?
For Purchase, Negative Adjmt, Cosumption: Unit Amount = Unit Cost (not rounded);
For Positive Adjmt: Unit Amount = Unit Cost (rounded by GL Setup "Unit-Amount Rounding Precision").
And if a Entry Type is Sale? Likewise then Unit Amount does not relate to Unit Cost.
If one enter an Item Journal Line with Type=Sale, effectively issuing from inventory, and the Unit Cost is changed, the entered unit cost is posted to the value entries. Hence causing deduction in stock at a different cost than the cost established by the costing system. Something I am not particularly in favour of. Though anyone of cause can comment on the practicality thereof.
0
Comments
-
mariussw wrote:If one enter an Item Journal Line with Type=Sale, effectively issuing from inventory, and the Unit Cost is changed, the entered unit cost is posted to the value entries. Hence causing deduction in stock at a different cost than the cost established by the costing system. Something I am not particularly in favour of. Though anyone of cause can comment on the practicality thereof.
This is not true.David Singleton0
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 320 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions