Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.5K Microsoft Dynamics NAV
- 18.5K 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
- 264 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 992 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
Options
Changing Base Unit of Measure
mariussw
Member Posts: 52
I would like to get some additional opinions on this please.
1) I believe it should not be an issue if changing an Item's Base Unit of Measure to a new Item Unit of Measure under the following conditions
- "Qty. per Unit of Measure" for the new Unit of Measure is also 1, but this would be a condition to become the Base Unit of Measure in any case.
- The Item Unit of Measure is new and hence will not have been used on any previous postings.
2) The real issue for not changing Base UOM, is that if the new UOM previously had "Qty. per Unit of Measure" > 1, and open Item Ledger Entries exist where the UOM was used as such.
(I obviously will have to change the C/AL code to allow this).
1) I believe it should not be an issue if changing an Item's Base Unit of Measure to a new Item Unit of Measure under the following conditions
- "Qty. per Unit of Measure" for the new Unit of Measure is also 1, but this would be a condition to become the Base Unit of Measure in any case.
- The Item Unit of Measure is new and hence will not have been used on any previous postings.
2) The real issue for not changing Base UOM, is that if the new UOM previously had "Qty. per Unit of Measure" > 1, and open Item Ledger Entries exist where the UOM was used as such.
(I obviously will have to change the C/AL code to allow this).
0
Comments
You can not change the Base UOM if Item has open Ledger entry.
1. Identify the Items and the Quantity on Hand 2. Zero the Inventory using a Physical Inventory Journal (Make it Zero whether Positive or Negative) or wait until its completely consumed 3. Change the Base Unit of Measure on the Item 4. Delete the old Item Unit of Measure, or change the quantity to what it should be 5. Re-calculate and put back the quantities in the new Base Unit of Measure.
Item ledger and your previous sales / consumption entries hold the Unit of Measure that was used for those transactions in the Item Ledger and the history tables, so it isn't a problem going forward using the new one.
"Profanity is the one language all programmers know best."
What we did was:
- Post a Negative Adjustment to have 0 Inventory
- Change the UoM
- Post a Positive Adjustement with the new UoM
It's important to be sure that the Cost of the inventory is the same after the process.
You have to be really carefull if there are open Orders, Invoices or any other pending document or movement that use the old UoM. You also need to uptade List of Materials, Prices, etc.
When running a proces or a report that sums quantities on a certain period, the result may be wrong if during the period the Base UoM Changed. So we added a field on the item card to know when the change took place. We show that date on cetain reports and forms.
It is not an easy task...
Salut!
Author of the book Implementing Dynamics NAV 2013
Cursos Dynamics NAV (spanish) : http://clipdynamics.com/ - A new lesson released every day.
That is correct, just make your values tie in the end.
One thing to make sure you look into is the existing lines you are using (Sales Lines, Purchase Lines, Production BOM Lines, Component Lines etc) and make sure you correct all of these as well. If you delete the old Item Unit of Measure, these transactions won't be able to post without being corrected. Though if you change the old Qty. Per Unit of Measure to what it should be relative to the Base - it still would be pulling correct on all of those existing documents, and those quantities would be correct on the existing documents and they wouldn't need to be changed.
For example, changing Grams to Kilograms, if the BOMS and Purchase Lines were for 1000 Grams of something at $x, and you now changed the Item Base Unit of Measure to KG, Qty. Per Unit of Measure 1, and changed the G to Qty. Per Unit of Measure: 1000, then everything is still correct. When you receive the 1000 G, Item Ledger will reflect the receipt of 1 KG.
"Profanity is the one language all programmers know best."
I am not confident that my actual question is answered. Though I did ask for opinions
- NAV blocks changing the Base UOM as a simple but perhaps unnecessary harsh approach. With more checks it can possibly be slackened a bit.
- We live with the restriction by first reducing stoct to zero (effectively closing all Item Ledger Entries), before changing Base UOM. If we perhaps can reduce the impact on us, as pointed out by current comments.
- I am suggeting that there actually are conditions - if strictly adhered to, where changing a base unit of measure has no consequences. Hence considerable less effort is required.
Why is changing Base UOM not allowed? Because of the following:
Suppose we have an Item, with UOMs of 20 EACH per PACK,
lets say EACH is the Base UOM.
If open Item Ledger entries exist where PACK was the UOM and we would change PACK to base UOM (firtsly changing "Quantity Per Unit of Measure" to 1) we create utter chaos. Because in subsequent application of new ILEs (typically for stock reduction) against other ILEs e.g. for available stock, quantities will not convert correctly.
Supose however we add a new UOM e.g. BAG. If there is one BAG per PACK (i.e. 1 to 1 ratio), there should be no negative consequences if BAG is made the Base UOM.
After having making such change, "Qty. Per Unit of Measure" value for PACK may not change as long as Open ILEs exist that are based on PACK.
Alternatively just renaming the Item UOM PACK to BAG should theoretically ripple through all table relations for existing entries and documents (were it not for the On Rename triggers that prevents doing so). (PACK and BAG must both be valid records in the "Unit of Measure" table - not to be confused with "Item Unit of Measure" table. Any flaw in this reasoning?
You can put code to allow the change under that circumstance, but then you have to decide what to do with open Orders, Invoices, List of Materials, etc. etc. etc. that use the old UoM. Do they have to change?
Salut!
Author of the book Implementing Dynamics NAV 2013
Cursos Dynamics NAV (spanish) : http://clipdynamics.com/ - A new lesson released every day.
Quite right. So let's discuss possible reasons why we would want to change the Base UOM in these two ways.
1) I am not sure whether it will happen in newer versions of NAV, but it came from an old version before upgrade. Apparently, during first purchase no Item UOMs were setup. Apparently the first purchase automatically created (or perhaps by human intervention) a blank Item UOM Code was created and used as Base UOM. :shock:. Now we want to fix this bad practice and hopefully can rename '' to WHATEVER. Cannot be done (regardless of programmed rules – prevented by architecture). We cannot rename UOM: ItemNo,{Blank} -> to ItemNo,WHATEVER.
Solution: setup new UOM with 1 to 1 ration to blank. Bypass code checks and select on Item Card as Base UOM.
2) End user created a UOM Code called '100' and selected as base unit of measure. #-o, implying a pack of 100, lets say labels. Purchase Order 3 x "100". Come invoice from supplier listing 300 labels and price. Receiving clerk does not understand intent or consequences, reopen order change qty to 300. Oops. (Yes, one does not even need multiple UOMs on an Item to end up in this).
So we realise '100' is a bad choice for a code and we rather want to call it 'PACK'.
Ok, here we actually can rename the Item UOM, if we either disable the OnRename trigger as a temporary, or refine them a bit. (One trigger on the Item Unit of Measure table and another on the Item Table).
It's always amusing to read how the ERP systems are being bend and reprogrammed to their limits because of bad (or no) NAV setup and end users lack of knowledge or should I say stupid mistakes.
This case has a simple solution: Everything that has been posted with the "wrong" UOM can be canceled/credited and then posted again with the "right" UOM. There really is no need for programming interventions or philosophical debates on whether the disabled changing of the UOM for an item with stock and open ledger entries is right or not.
If after crediting you don't change the Base UoM it is very easy to make the same mistake again!
Of course you can credit, block the item, create a new one with the right setup and post using the new item.
Salut!
Author of the book Implementing Dynamics NAV 2013
Cursos Dynamics NAV (spanish) : http://clipdynamics.com/ - A new lesson released every day.