D365 Finance & Operations and Dynamics AX Forum

Expand all | Collapse all

Customer unit of measure requests

  • 1.  Customer unit of measure requests

    GOLD CONTRIBUTOR
    Posted Feb 08, 2019 03:39 PM
    Hi,
    As of lately it seems that more and more customers are requesting their invoices to be in specific units of measure for their business. Has anyone run into this and if so, how do you go about making those types of changes in D365?

    We've tried this for one customer so far and created a new unit of measure, the problem is that all reports that we run internally now show in this "non-standard" UoM, so it requires converting to what our standard is.

    ------------------------------
    Thank you,
    Justin Cooper
    ------------------------------


  • 2.  RE: Customer unit of measure requests

    TOP CONTRIBUTOR
    Posted Feb 11, 2019 01:47 PM
    ​A quick review of UOM design in AX:

    Each product has 3 UOM defaults, one for Sales, one for Inventory, and one for Purchasing. Sales and Purchasing UOMs require a conversion factor to the Inventory UOM. This allows the system to perform internal tracking in the Inventory UOM, while handling sales and purchase orders in alternate UOMs.

    Thus, a customer requesting a different UOM should just involve ensuring that customer's orders are taken in their desired UOM.

    The problem is often in custom reports not handling this cleanly because the programmer didn't expect the UOM to matter. Customer facing reports should always try to display in the saleline's sales unit of measure - and Qty values should be converted to that UOM, or use the sales qty field if available. Internal reports should always work off the inventory UOM and Qty's.

    The one weak point - there isn't any good way to enforce a customer's choice of sales UOM. However - if you are using trade agreements, you can take advantage of the fact that the price in the trade agreement has to match the sales UOM on the line in order to pull the price back. Thus, you can put some ridiculous pricing in the trade agreements using the UOMs that are not allowed, to ensure the order is obviously incorrect if the order entry person doesn't pick the right UOM.

    ------------------------------
    Tony Zeigler
    Senior Consultant
    Strategic Solutions NW, LLC
    Beaverton OR
    ------------------------------



  • 3.  RE: Customer unit of measure requests

    GOLD CONTRIBUTOR
    Posted Feb 18, 2019 09:08 AM
    Hi Tony,
    Thank you for your reply on this! We problem we are running into is a customer requesting a different UoM that is quite unique - typically our UoM is in length measures. They are requesting it to be in weight. The problem with this is that each product is a bit different when it comes to weight. No quite sure how to handle this as it sounds like we would have to create a UoM for each of the different products of different weights...

    Thank you
    Justin Cooper

    ------------------------------
    Thank you,
    Justin Cooper
    ------------------------------



  • 4.  RE: Customer unit of measure requests

    TOP CONTRIBUTOR
    Posted Feb 18, 2019 01:22 PM
    ​Ah yes, we have a lot of clients in the forest products space, and it is painful. Pre-2012 R3, AX didn't even have UOM conversions specific to a product variant, so for one client we had to do a massive mod to add that. And now it's out of the box :)

    But - getting the data into the system is still troublesome. We had one client that had rules for it that they built into their 3rd party configurator, and then had it add the conversions when it created the variant. Other clients put the work on their product engineers - each product they define they have to include the needed UOM conversions for.

    One thing I did find - if the conversion doesn't exist - it can prevent the user from saving the salesline correctly. So there was some discussion about having a generic conversion in place that was unrealistic, so the sales entry staff could enter the order correctly, then call out to product engineer to give it a correct conversion, then confirming the order after it was corrected. However, this can be risky as well, because it does open up the possibility of sending out an order with a bad conversion.

    You can also consider having the sales staff put the order on hold with a hold code representing the need for a UOM conversion, have the engineers get an alert when such a hold is created, and they have a process for responding to the alert by fixing it and releasing the hold. This then allows the order to progress.

    If the product engineers have rules they can use to define the conversions, they may be able to upload an excel into the UOM conversion table that loads all the conversions.

    Hopefully you don't have the issue that lumber can have - a wet weight and a dry weight :)

    ------------------------------
    Tony Zeigler
    Senior Consultant
    Strategic Solutions NW, LLC
    Beaverton OR
    ------------------------------



  • 5.  RE: Customer unit of measure requests

    Posted Feb 18, 2019 04:57 PM
    Hi Justin,

    Have you looked into the catch weight functionality to see if that could be used to meet the requirements?

    Cheers
    Phil

    ------------------------------
    Phil Dawson
    Data#3 Limited
    Toowong
    ------------------------------



  • 6.  RE: Customer unit of measure requests

    GOLD CONTRIBUTOR
    Posted Apr 09, 2019 10:17 AM
    Hi Phil,
    Appreciate the response and apologies for my delay.

    This has been coming up more and more as of recently. We have more customers requesting that their invoices reflect a different UoM than what our standard is. We have explored doing the conversions but one of the issues is that these are one-off requests, so it requires the CS team to keep track and enter orders accordingly.

    We have not looked at the catch weight function - do you have any reference links as to what exactly this is?

    ------------------------------
    Thank you,
    Justin Cooper
    ------------------------------



  • 7.  RE: Customer unit of measure requests

    TOP CONTRIBUTOR
    Posted Apr 09, 2019 10:49 AM
    ​If your just dealing with one-off requests, I don't think Catch weight will help much - it's quite intrusive to turn on & use.

    The best way to catch one-off issues during order entry is to have a closed loop agreement with your customer. Ie., send them that confirmation document and make sure they review it :) That way if issues do come up, they can't blame just you ;-)


    ------------------------------
    Tony Zeigler
    Senior Consultant
    Strategic Solutions NW, LLC
    Beaverton OR
    ------------------------------



  • 8.  RE: Customer unit of measure requests

    GOLD CONTRIBUTOR
    Posted Apr 09, 2019 12:35 PM
    Hey Tony,
    Appreciate the response! I am not sure what has been going on as of lately, but we have more and more customers requesting one-off UoMs on their invoices over the last couple of weeks. We want to meet their needs, but having to go in and create these unit conversions for individual customers would be a nightmare to maintain. I was hoping that there would be an easier way to do it.

    ------------------------------
    Thank you,
    Justin Cooper
    ------------------------------



  • 9.  RE: Customer unit of measure requests

    TOP CONTRIBUTOR
    Posted Apr 09, 2019 01:15 PM
    ​Unfortunately, there is no good solution out of the box for dealing with just occasional customer requested UOM conversions.

    The cleanest solution would probably be a custom button on the salesform that would allow order entry staff to quickly add one, then they could use it on the salesline. The button would just need to create a modal pop-up that takes an item, then use it to open the standard UOM conversion form. However, it would all be custom. You would probably have to work out security permissions on the usage of it - and you might want to enable some of the audit fields on the UOM conversions if your opening it up to a large group. A good dev could probably complete such a customization in a couple days or less.

    Normal processes would be:
    1. Product engineering group creates standard UOM conversions when they define a product.
    2. Configuration tool calculates standard UOM conversions when it defines a product.
    3. Engineering group uses spreadsheets to load updated conversions on a periodic basis for conversions that change over time.
    4. Catch weight is enabled, which at a very high level, allows you to track inventory qty at the batch or serial dimension, separate from the sales uom. This allows you to separate qty of packages from qty used for invoicing. Use cases are limited - so it should only be used in the scenarios that really call for it.




    ------------------------------
    Tony Zeigler
    Senior Consultant
    Strategic Solutions NW, LLC
    Beaverton OR
    ------------------------------



  • 10.  RE: Customer unit of measure requests

    SILVER CONTRIBUTOR
    Posted Apr 10, 2019 10:51 AM
    ​we had request for multiple unit of measures for 'inventory unit', which we handled thru custom code. Still wondering why Microsoft does not allow multiple uom for inventory transactions.

    i believe my msg is relevant in this discussion as its about uom and how to handle different business requirements.

    ------------------------------
    Amer MS
    ------------------------------



  • 11.  RE: Customer unit of measure requests

    TOP CONTRIBUTOR
    Posted Apr 10, 2019 12:14 PM
    ​Multiple inventory units of measure would simply be too complicated to support in a general way.
    The inventory unit of measure should be the smallest unit of an item you track in inventory.

    The sales & purchase units of measure are simply defaults for buying and selling.
    So for instance, you may track individual items in inventory (ea), but buy in cases, and sell in boxes.
    However, these can be thought of as simply "views" of inventory that is tracked in the inventory unit of measure.
    Any additional units of measure needed can probably also be thought of as "views".

    For instance, in the lumber products industry, we often talk about MBF (Million Board feet), as well as pieces. So for some of our clients we customized an alternate unit of measure for the salesline so a salesperson can quickly see/enter in either pcs or mbf. However, those are still converted to the inventory unit of measure, and need to have conversions between the different views. So inventory is tracked in pcs.

    In summary, when dealing with units of measure - your inventory unit of measure is most important - and should be the smallest trackable unit when counting/moving inventory. All others should be considered views upon that inventory unit of measure.

    ------------------------------
    Tony Zeigler
    Senior Consultant
    Strategic Solutions NW, LLC
    Beaverton OR
    ------------------------------



  • 12.  RE: Customer unit of measure requests

    SILVER CONTRIBUTOR
    Posted Apr 11, 2019 02:35 AM
    Thanks Tony.  I agree with your point that other uom are just views, which we too accomplish with some customization for certain transactions. we were expecting this as standard across system, because business works with multiple units. For example, lowest unit of inventory is pieces but transfer happen in pallets, production happen in cases and sales can be in cases or pieces. User finds it difficult to enter 181440 pieces when they are transferring 18 pallets, where each pallet has 120 cases of 84 pieces each.

    lets raise this in ideas to Microsoft

    ------------------------------
    Amer MS
    ------------------------------



  • 13.  RE: Customer unit of measure requests

    TOP CONTRIBUTOR
    Posted Apr 11, 2019 09:50 AM
    ​I'm going to disagree with Tony a little bit. Your inventory unit of measure should be the unit that makes sense to your business, which isn't necessarily the smallest. Your default conversions should take care of any transactions, selling or inventory, in alternate units of measure whether larger or smaller, as well as allowing you to view your inventory in terms of those alternate units of measure.

    We are a chemical manufacturer. The vast majority of our inventory raw material and finished goods, whether liquid or dry, is tracked in pounds. That said, we sell to a lot of companies who buy from us in grams or kilograms, and many of those customers have specific levels of precision they require.

    So, for example, we have conversions set up where:
    KG1 = 1 kg = 2.2 lbs. (1 decimal place)
    KG3 = 1 kg = 2.204 lbs. (3 decimal places)
    KG4 = 1 kg = 2.2046 lbs. (4 decimal places)
    KG8 = 1 kg = 2.20462262 lbs. (8 decimal places)

    The gap, for us anyway, is that there's no way in AX 2012 to define a default selling unit of measure per customer. That has to be done at the item level. One way to deal with it may be to set up your items for manufacturing and inventory with one item key and create a separate item key for that item/customer combination with their default selling unit of measure set? You'd need some way pull the inventory from one item key and sell it as the other. I don't know if there's any way to do that without a manufacturing step. Maybe others can suggest something?

    Example:
    Widget01 is the manufactured/inventoried product with all units of measure in LBS
    Widget01-001 is the same product, for customer 001, with a selling UOM of KG1
    Widget-01-005 is the same product, for customer 005, with a selling UOM of KG4

    Somehow you'd need a step in there to take 2.2 units of Widget01 out of inventory and sell it as 1 unit of Widget01-001 and take 2.2046 units of Widget01 out and sell it as 1 unit of Widget01-005. I'm on the accounting side of things, so I don't know if there's a simple way to do that without actually manufacturing the alternate item key product first.

    Without a little more detail about your unit conversion needs, it's kind of hard to understand how you are ending up with so many unique conversion requirements for each customer instead of a few that can be used across all customers.



    ------------------------------
    Steve Latta
    Accountant
    Ortec, Inc.
    Easley SC
    ------------------------------



  • 14.  RE: Customer unit of measure requests

    TOP CONTRIBUTOR
    Posted Apr 11, 2019 11:20 AM
    The approach I've used was to use a combination of Customer Item description (use as the SO item lookup reference to the AX item id: some modification was required) and Trade Agreement Sales price (to assign the customer UOM). We required POs from the customer to use their item number.


    ------------------------------
    Mark Prouty
    Programmer / Analyst
    ANGI Energy Systems
    Janesville WI
    ------------------------------



  • 15.  RE: Customer unit of measure requests

    TOP CONTRIBUTOR
    Posted Apr 12, 2019 10:51 AM
    one note, on the smallest unit , and the makes sense unit. Remember that for example if you buy in rolls and store in rolls  and your conversion is 1 roll equals 50000 yards, and your bom consumption is in inches, you will get some 0 consumptions and 0 cost as you do production. so I caution make sure that you use appropriate units to not give misleading results in the system so for the above I would buy in roll store in yds
    and consume in inches or feet. then everything works.

    ------------------------------
    Paul Martin
    Production Program Manager
    Elite Comfort Solutions, LLC
    Rutherfordton NC
    ------------------------------



  • 16.  RE: Customer unit of measure requests

    GOLD CONTRIBUTOR
    Posted May 06, 2019 11:28 AM
    I appreciate all of the feedback on this! Our struggle is that our standard UOM is MFT (thousands of feet): 1 MFT = 1,000FT. We have some scenarios where customers are requesting to be invoiced in, for example, meters. To convert 1 MFT to 1 M, there are quite a few decimal places, especially when it comes to the pricing. When trying to put in pricing, D365 seems to only store 2 decimal places but for this conversion we would need a minimum of 4.

    ------------------------------
    Thank you,
    Justin Cooper
    ------------------------------



  • 17.  RE: Customer unit of measure requests

    TOP CONTRIBUTOR
    Posted May 06, 2019 12:41 PM
    You might check the units screen in organization administration, setup, units. The rounding precision for each unit of measure can be found there.

    ------------------------------
    Tony Zeigler
    Senior Consultant
    Strategic Solutions NW, LLC
    Beaverton OR
    ------------------------------



  • 18.  RE: Customer unit of measure requests

    GOLD CONTRIBUTOR
    Posted May 06, 2019 12:54 PM
    Hi Tony,
    Even with this set, with you create a trade agreement journal it is limited to 2 decimal places. Lets say, for example, I set a price at .0056, it is going to set the price to .01.

    ------------------------------
    Thank you,
    Justin Cooper
    ------------------------------



  • 19.  RE: Customer unit of measure requests

    TOP CONTRIBUTOR
    Posted May 06, 2019 01:00 PM
    ​Yes, at the end of the day amounts of money are typically limited to 2 decimals :)
    The price unit can be adjusted as well tho...
    So instead of setting your trade agreement journal at  .0056 per price unit of 1, try setting it at 56 per price unit of 10000.

    ------------------------------
    Tony Zeigler
    Senior Consultant
    Strategic Solutions NW, LLC
    Beaverton OR
    ------------------------------



  • 20.  RE: Customer unit of measure requests

    GOLD CONTRIBUTOR
    Posted May 08, 2019 12:17 PM
    Hi Tony,
    We will give this a shot and see if it does the trick! Appreciate it!

    ------------------------------
    Thank you,
    Justin Cooper
    ------------------------------



  • 21.  RE: Customer unit of measure requests

    SILVER CONTRIBUTOR
    Posted May 09, 2019 03:59 AM
    ​hi Justin,

    we are using this concept without issues. Just check the printing is ok for you.

    ------------------------------
    Amer MS
    ------------------------------



  • 22.  RE: Customer unit of measure requests

    TOP CONTRIBUTOR
    Posted May 08, 2019 01:19 PM
    Using a Price unit greater than 1 is a common standard approach to solve this issue in lieu of customizing forms/data for decimals places or creating new units of measure like Steve mentioned.

    ------------------------------
    Andrew Lencsak
    Solution Architect
    DXC Technology
    Atlanta GA
    ------------------------------



  • 23.  RE: Customer unit of measure requests

    GOLD CONTRIBUTOR
    Posted Jun 14, 2019 10:40 AM
    Hi Everyone,
    Thanks again for the input on this!

    We were able to get this implemented and seems to be working OK but it has been causing some confusion on the reporting side. When our finance groups runs reports, they typically would just take the QTY * unit price to get the revenue for the order. However, in this scenario with using the price units that does not actually work because the price is set up with a price unit of 1,000. When they do their standard calculation, they are getting much higher values.

    Any recommended ways to get around this?

    ------------------------------
    Thank you,
    Justin Cooper
    ------------------------------



  • 24.  RE: Customer unit of measure requests

    TOP CONTRIBUTOR
    Posted Jun 14, 2019 10:52 AM
    Sounds like the report is referencing the Price field instead of the unitPrice method?

    ------------------------------
    Mark Prouty
    Programmer / Analyst
    ANGI Energy Systems
    Janesville WI
    ------------------------------



  • 25.  RE: Customer unit of measure requests

    GOLD CONTRIBUTOR
    Posted Jun 14, 2019 11:17 AM
    Yes, so for example - they are running the Open Sales Order Lines by Customer report. If you were to take the Quantity and divide by the amount ordered (revenue), that would not give you the actual unit price. We'd have to divide the QTY by 1,000 first.

    ------------------------------
    Thank you,
    Justin Cooper
    ------------------------------



  • 26.  RE: Customer unit of measure requests

    TOP CONTRIBUTOR
    Posted Jun 14, 2019 11:53 AM
    Depending on how you want to report data, there should be a couple of methods that do the pricing math - one is related to invent price, the other to purch price.
    Depending on your environment, you could re-create the pricing ​formula in the report, but that can be difficult if you have different pricing by inventory dimension (site/ warehouse). Best to reference the available methods.

    ------------------------------
    Mark Prouty
    Programmer / Analyst
    ANGI Energy Systems
    Janesville WI
    ------------------------------



  • 27.  RE: Customer unit of measure requests

    TOP CONTRIBUTOR
    Posted 26 days ago
    ​If they are reporting off the salesline table, they should really be using lineamount, not qty*unit price.
    If you ever begin using discounts, the qty*unit price wouldn't work either....

    Similar if they are reporting from custinvoicetrans.

    The tricky one may be shipped not invoiced, in which case the base table is custpackingsliptrans, but that may not have pricing yet. So they might be trying to fetch qty from there, and pricing from the salesline. In that case, a quick shortcut it probably salesline.lineamount*(custpackingsliptrans.qty/salesline.qty)
    (Basically, taking a portion of the salesline.lineamount based on the % you have shipped.)

    ------------------------------
    Tony Zeigler
    Senior Consultant
    Strategic Solutions NW, LLC
    Beaverton OR
    ------------------------------



If you've found this thread useful, dive deeper into User Group community content by role