Advanced UOMs

FishermanFisherman Member Posts: 456
Is there an add-on product for Navision that provides a more advanced system of UOM management? We're finding that the current implentation is too simple and restrictive to be of real value in a line of business that relies on flexibility.

For example -

As middle-men, we are not in control of our customer's suppliers. While we would like for them to ship in standard carton quantities, we cannot force them to. It seems like Navision assumes enforces UOM conversions very strictly, and does not let you change the UOM conversion on the document... am I correct here, or am I missing something?

Also, it looks like all UOM conversions relate to the Base UOM. Our existing product (which is > 10 years old) doesn't even require this. It lets me state that an 1inch = 1 ea, and 1 foot = 12 inches, and 1 yard = 3 feet, and it is able to perform the calculation for me. Again - am I missing something... because it doesn't seem like Navision allows for this.

Comments

  • SavatageSavatage Member Posts: 7,142
    The base uom should be your smallest allowed value

    Base UOM = INCH (1)
    then you can make as many sales & purchase UOM's as you need

    FOOT (12)
    YARD (36)
    etc etc

    On the sales order or the purchase order you can change the UOM as you need

    36 @ INCH is the same as 3 @ FOOT and 1 @ YARD etc etc

    You have to make all your cost and prices based on the INCH price then as you change UOM's it will automatically calculate for you.

    Does this make sence? You could if you wished go all the way down to 1/16 INCH as your base if that's what your situation needs.
  • FishermanFisherman Member Posts: 456
    You're misunderstanding me...maybe i'm not being clear.

    I've worked with two systems previous to Navision - in both of them, the UOMs did not have to be directly related to the base UOM - you could build trees, and the system would calculate for you. This is one problem. But it's not the big one - it's just annoying that our 10+ year old legacy systems allow this, and Navision does not.

    The real issue is this. We warehouse cartons for our customers. Let's say we enter a unit of measure of ea = 1. Then, we say that 1 carton = 100 ea. However, since we don't control the suppliers, next week we might receive cartons of 120 ea. Now, on our receiving dock - they're going to count cartons. If they count 6 cartons, the system will record 600 eaches in inventory after the putaway. However, that will be 120 short.

    Our current systems allow them to change the qty per unit of measure on that transaction - resulting in the correct quantity in inventory.
  • ssinglassingla Member Posts: 2,973
    Dear Friend,

    I am presently doing a system study and my requirement is exactly what you are asking. Though we have not finalized how we are going to acheive but the rough plan says like this :

    Allow user to enter 2 nd unit of measure on the purchase/sale/item journal/output/consumption lines and define the value of 2nd UOM for that transaction.

    The 1st UOM on the line will not be Base UOM and the 2nd UOM will be base UOM.
    On run time we will update the conversion factor in Item unit of measure table and let the system post the transaction. Reinstate the orinigal conversion factor after posting.

    8-[ would like ur comments.
    CA Sandeep Singla
    http://ssdynamics.co.in
  • David_SingletonDavid_Singleton Member Posts: 5,479
    Fisherman wrote:
    You're misunderstanding me...maybe i'm not being clear.
    ...

    Actually this is quite a common request in Navision, not a huge request, but I do see it often enough.

    For example it is very common in many food industries. Where for example a manufacturer may order 20 legs of meat that will be processed into different forms. Unfortunately many animals tend not to be intelligent enough to follow ERP rules, and end out growing their legs to different weights than other animals. So the company orders 20 10kg legs, but the vendor ends out supplying legs of different weights say 10.4kg or 9.3 kg.

    This is the extreme case, and does require a fair bit of work to get it working correctly. I have done this on a few occasions, and it is not a huge mod, but more than you need in your case.

    In your case though the better solution, is to keep closer to the standard. What I have done in the past is this:

    On Purchase order Line, have a new field that is populated from UOM Conversion. In you case this would populate with 100. Then when the user enters 6, the line will say :
    6 Cases or 100 each = 600 units.
    Then the user goes to the new field and enters 120. At this point a simple trigger scans the UOM table to see if you have a UOM for 120. If not it creates a new one (CASE120) adds it to the list, and changes the line using the new UOM.

    This mod needs very little work, and does not modify core functionality, so is easy to maintain and upgrade.

    The second mod you need, is also very simple, it just needs the addition of a couple of fields to the UPM table, and some triggers.

    Your NSC will be able to build both this mods very quickly (a few hours at the most).

    By the way, I know that the base product looks odd to you, and to many people it does. When it was first being introduced in Navision, I also complained that it was too strict and formalized. The point is that when they were designing this, they found that the majority of users worked this way, in that they had a list of case sizes. But that customers needing the more complex UOM generally all had differing needs, and those were best handled either by the NSC customizing or using vertical solutions. (NaviMeat for example).
    David Singleton
  • ara3nara3n Member Posts: 9,255
    Great tip/solution David. Most of the time the great solutions are the simplest ones.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • FishermanFisherman Member Posts: 456
    Interesting thought.

    We were already considering going with a "CTN120" type of solution - but I was trying to find a way around it that would make it more flexible for the Receiving clerks.

    The way our old systems had handled this was by caching the qty per unit of measure on subsequent ledger entries - meaning that the default was the one set up in the system, but it could be changed on any of the documents.

    I'll look into what you're talking about David. Thanks.
  • David_SingletonDavid_Singleton Member Posts: 5,479
    BY the way, ake sure you put the "CTN" text in a field, do not hard code it. Youc an put it anywhere, but the best is probably in either Item Group, Product Group or Inventory Posting group tables.
    David Singleton
Sign In or Register to comment.