In the landed cost module in D365, one can set up automatic costs, similar to automatic charges, associated with a voyage. Typically this can be transportation cost, customs etc. The cost can be debited to the items that are being shipped or to finance accounts, while the credit can be set to finance accounts, or directly to the vendor and an invoice. It is even possible to use for transfer orders, where one can specify which from and to-warehouse the charge is allowed to be applied, and for what items. This is a great functionality!

However, in contrast to automatic charges in the procurement module, the automatic costs in the landed cost module are not possible to set for a specified unit. For instance per ton, per kg or per flask for that matter. Instead one must choose percentage of item, fixed charge, or charge per "item". However, often for transportation, at least in our case, the cost is communicated from the transportation firm as a cost per ton for a specific category of goods. That means that for the same transportation route, for the same category of goods, the cost per 25 kg bag of a formula will be different from the cost per kg or per tonn of the same formula transported in bulk. If the automatic cost could be set per ton like for automatic charges, the correct cost per item could be calculated based on the unit conversions defined for the different products. This would would have been a very flexible and good solution. Instead, with todays solution of cost per item, all these three product items of different units would need to have defined their own cost. This means that for every different unit the item can be transported in, there is another cost to maintain, rather than having just one cost defined for all of them, calculated by cost per kg. I know a lot of people use percentage of item cost as calculation, but in our scenarios, that is not a good fit.

So, as the title of the idea suggests: Extend the auto cost functionality to make it possible to specify auto costs by a unit.

I think this would have been a great contribution to an otherwise good module, making the maintenance of costs a lot easier.