This is maybe more of a “best practices” question, but I really want it answered from a coding perspective, thus I am posting here…[8D] Basically I am about to implement (what I will call) Dynamic Units of Measure. By this I mean, that it is not possible to specifically define the ratio of the unit of measure. A typical example of this is the meat industry, where you purchase say a leg of meat, you want to order 20 legs they have a typical weight of 5.5 kg, but could be from 4.0 to 6.0 so its impossible to have any standard UOM for this. Unfortunately the way Navision implemented UOMs, it really needs to have the table defining the ratios. The logical way to do this, is just to start again, create a new field For the New Quantity, and a field for the conversion ratio, math it into quantity etc. But… Has anyone gone and just modified existing UOMs to allow them to be dynamic. Obviously it can be done, but in the long run, which is the least amount of work, and which one makes for the cleanest upgrades. Modifying Navision UOM and Qty (Base) everywhere, or just adding a new field. All comments are welcome, but please let me know if you have actually got a client live on each of these methods, I really am interested most in the development point of view, of how much work is involved each way. PS: By the way, I know that a third option is to dynamically generate a different UOM every time a different ratio is needed. I have implemented that also, but it wont work in this case.
So what you’re saying is you have an order for say 5 legs, and each leg has its own equivalent ‘quantity’ of lbs? Wouldn’t you have to have 5 lines with UOM LEG and quantity 1, with an additinal quantity in say a ‘secondary’ UOM of LBS? I could see this work with FIFO or LIFO, so you have dedicated item ledger entries. I would probably use LEG as Base UOM, and add a secondary UOM field, or something like that, to the Item table and have that flow from the order into the ledger and back out again. What you’d have to do is keep stock in LEGS, and modify the pricing/costing code to convert it into lbs prices on the order line. You’d also have to figure out a way to enforce quantities of 1 on each line, mabe by abusing the item tracking code? Nah you’d probably have to put something custom in there, for upgrading purposes and the next customer who wants to use Lot/Serial numbers with this :). Maybe… you enter the item number for Pork legs. Navision knows by this new custom field that it is ‘one of those items’, so it defaults the quantity with the value 1. The user will only have to enter the LBS quantity (so that would go into a new additinal custom ‘secondary quantity’ field or something like that), and the system would calculate the price/cost into the regular price/cost/amount fields. For 5 legs you’d have 5 lines with the correct LBS values and the correct prices/cost. Then during the posting these values flow into the ledger, so you will have to add those fields to both the journals and the ledger tables. On the flip side, you sell pork by the leg, and by the FIFO or LIFO it takes the right one out of inventory. Maybe you can add functionality for the user to pick the one they want, but then you’d probably have to add serial # type logic… hmm this is getting complicated :). Just some quick thoughts, but probably a pretty good direction I’d say. I would stay away from messing around with standard UOM logic, that is just used in too many places.
By the way, don’t forget to set rounding precision to 1 on those items. So you’d have LEG in the Item UOM, with qty per=1. Also, LBS with qty per=1. In the price/cost table you’d enter the lbs price/cost. All you need to do is modify the order table to calculate the LEG price as the ‘secondary uom’ price times the ‘secondary qty’ and enter that in the regular order amount fields. When the order is posted, it should enter the converted LEG values into the ledger, so that particular 1 LEG of pork has the equivalent value of 12 LBS. The more I think about it, the more I think this could work :). Just two Item UOM records and all your values would be right. The only issue would be that because you’d have LBS with qty per of 1, and your inventory is in LEG with different secondary qties. But since that would be in a custom field, you’d have to create custom reporting anyway, so you can MAKE that work.
This brings back memories of when I worked in the grocery wholesale world… Similar to what Dan is saying, we had a different picking process for what we called ‘random weight’ items. Usually meat products. What I would do is create another field on the sales line like ‘Unit Quantity’. So, to keep with Dan’s example, the order would be placed for 5 in your new field. Someone would then pick the order and get the actual weight of the 5. That weight would then be the standard Navision ‘Quantity’. Looking ahead at warehouse management and/or ADCS, this could also be easily integrated.
Right that would work even better, plus you could keep your stock in actual weight, and costing/pricing would all be standard. All you’d need to do is make that ‘Unit Quantity’ field flow into the ledger, and some logic to not allow receipt/shipment/invoicing of partial quantities for ‘that type of item’.
Hi Dan and Crazy, thanks for your comments.[8D] [Oops!]Unfortunately when I was making this posting, it started to get too long winded, so I shortened it, and in doing so, I think I failed to get my question across clearly. Basically I have implemented Dynamic UOMs a number of times fro different applications, and generally found that in each case I used a diferent aproach. In the Meat case, I had a new field where they enter actual weight (total for the number of legs received), and then calculate an average leg weight. This works fine, and was done before Navsion introduced UOMs, so the only option was to start from scratch. I only used this as an example, since it is the easiest to describe. The current scenario is a client that already have Dynamic UOMs, and have been using the systemfor a couple of years now, but its not perfect, and they are now looking to upgrade, so now would be the time to review UOMs. I think it would be much cleaner if I was able to make use of Navision’s standard UOMs, but just how much work is involved in going that path. Actually this is the question bit of my posting
quote:
Has anyone gone and just modified existing UOMs to allow them to be dynamic? … which is the least amount of work, and which makes for the cleanest upgrades. a/ Modifying Navision UOM and Qty (Base) everywhere, or b/ just adding a new field.
Originally posted by David Singleton - 2005 Aug 26 : 12:36:34
Sorry for the confussion. [Duh!]
By the way if I were about to implement this, your comments would have been very helpful, thanks for the effort. As a foot note, the Legs were purchased as a raw material, that was then used in manufacturing, so the quanitities were all stored in Kg, which did simplify things somewhat, since all the conversions issues generally only happened at the purchasing time.
I would say that this makes the case most compelling for using the weight uom as the base uom, and have somebody with a calculator adding up the weights of the 5 legs, or entering the weight per line or something like that. Especially since the meat is raw material, you’re not really interested in the unit quantities anyway. Maybe you could have it as a new field on the order line and have it flow into the posted documents, but really in the ledgers you wouldn’t need that info. I have never done anything like this before, so I’m looking at this with my mind’s eye. At the very least (from a standpoint of minimizing the development effort) I would try to stay away from altering the uom logic. If you really need to do someting dynamic, I would try to design it in such a way that you have some process populating the standard tables in Navision, or some type of “plug-in” process that converts the quantities, with a pop-up window where you can enter weights per unit and that adds them all together on the fly.
Anyone done it? [?]
No not done it as dynamic unit of measure - but i am encountering the same or similar issue. Working in the Metal Industry where everything is reported in Weight KG/Tonne but there is a requirement to know the No. of Pieces. This is usually calculated from a Standard Weight field but due to Cast, Pulling Speeds chemical Make up and Other Factors the weight per piece can vary from Batch to Batch. How best do you then track this through the system??? Add new fields and calculate the Qty. per for each transaction? What should the Base Unit of Measure be Weight or Piece. it is really quite a tricky one as the industry will want to report almost everything in KG and will sell mostly in KG too. But for Stock Adjustments they will want to adjust via no. of Pieces etc. no easy when you have a varying relationship between the 2!! Best of luck & if you have any great ideas …
Hi Andrew, what you are looking for here, I have done before. As I said in my posting, I did it by adding new fields, but it was in a version before UOMs were introduced into Navision. Currently the system I am looking at right now is not too far different, and they have been running for 3 years, and are now looking to upgrade. My question is “has anyone modified Navision standard UOMs to be dynamic”, since there is no response, I am assuming that no one has done it. I am still deciding which way to go. (i.e. leave it as it is with custom fields, or modify standard). If you have any specific issues, post them, I have done 6 or 7 implementations with dynamic UOMs, but with custom fields. Custom fields is obviuosly easier, but not as “clean”.
I have customized the UOM’s to be dynamic in both methods on version 3.10, and must say that changing the existing was far easier. That is to make Use the Base fields and the Quantity Per… I do recommend that you also make adjustments so that in the Sales you cover for Unit Price (Base), Unit Cost LCY (Base). Since most issues after these customizations was to display prices per Base Unit…in My case is was Boxes of Fish in different Sizes,each box naturally have a individual Weight, the pricing is based on KG, but Sale is done normally in Boxes based on Fish Size (Variant Codes with info on how may Pieces of fish in a Size). So basically the customers did get a fairly estimated price at SO Stage and not until they had put the boxes on the scale the actual Sales Price was determined. They could also break boxeds and sell PCS of fish, still billed in KG to estimated KG Prices based on Variant Codes info on Estimated No Of Pcs and Weight. So it was sort of a duplication of UOM’s for a Item. Just that one Unit was the TRUE Valued Inventoy unit(KG) We keept both info on how Many KG in Inventory as well as info on how many BOXES (per Item,Variant Of course) But to share most problems came with Pricing, Item Journal Operations, since it required these things to be fully enabled there as well(Transfers etc.), and as normal there is a tendency to forget that 
Most of these issues you mention i am coming across. My main concern is that KG’s has been chosen as the Base unit of measure. but most transactions are controlled easier by piece. Sales order come in for X no. of KG’s i then need to create consolidated Warehouse shipments by customer upon these orders. (no problem) Next i need to create a pick for no. of pieces as the warehouse guys will physically pick pieces. and confirm how many pieces they have picked. It is not until the stoc kliterally goes out of the door/Yard that it gets weighed. I then need to capture the actual weight as this may well be different to the recorded weight of those bars that have been shipped. I need to do this so i can invoice the actual weight shipped if the sales order was for KG’s to start with. I do have some ideas but keep coming across stumbling blocks. Has anyone implemented the “dynamic UOM’s” with Warehousing and Manufacturing?? As again i have the requirement to make so many thousands of KG’s of stock - once this is made the stock will be booked in as x no. of pieces giving me only a theoretical weight.
Hi Andrew, so far I think that sticking with creating a new set of fields is probably your better solution, but I am still looking at it. As Joe points out, the biggest issue with modifying the functionality of the existing fields is that you MUST do it everywhere, you can’t just do it where you need it. Where as, adding your own fields means you only need to implement it where you need it. Joe, you are implying that it is less work to modify the exiting functionality than to add new fields, and this is interesting. As I have said, the current client has been running the current version with a new field set for about 3 years, and it works fine, but they are getting ready to upgrade to 4.01, and I am contemplating converting it to use existing fields, so that future upgrades will be easier. But I need to know if this really will make the next upgrade easier. PS Daniel, thanks for the input, concidering I have already done it, I can say that your observations were quite correct. Sorry that I didn;t make it clear in the begining that the system was already in place, but your time spent responding was much appreciated. And of course, if anyone has done this (I mena modified existing UOM code to be dynamic), I would really appreciate any feedback.