Mikael Algeroth Senior Advisor

A lot of master data, e.g., terms of delivery, terms of payment, modes of delivery etc. changes over time but in D365 you're not able to remove this data if you have used it somewhere. A typical example would be terms of delivery where you at one point of time use FOB but you make a policy change and don't want to offer this to customers any more. In D365 the only thing you can do is to change the description to DO NOT USE or something similar but you can't eliminate the risk of the data being used.

I've worked with a lot of other ERP systems and most of them works the same way as D365, i.e., if you've used master data you're not allowed to remove it. But, what other systems offer is the ability to set master data as active or inactive which means that you're not removing anything but you're able to block it from use - and in some cases even specify from which date it will be invalid.

As master data management is a crucial part of correct use of an ERP - isn't it time that D365 gets this ability to maintain master data as well?

To support vendor consignment there is the concept of vendor owned inventory but the same type of feature would be useful both from a customer consignment process perspective as well as better supporting 3PL scenarios. The feature would also be very useful for subcontracting manufacturers who receives components from their customers requiring full support from a logistics perspective but as the components are never owned by the subcontractor it should be excluded from financial stock. Another process requiring this is for service providers who manage spare parts supplied by the customer but never owns the spares - they just use them for executing field service.

Other ERP packages has solved this by adding full support of inventory ownership in all inventory transactions.

In several scenarios in the EU you need to be able to set the tax code on an address level including a address specific tax registration and that's covered by standard. However, there's no standard entity for importing/exporting that data which is very unfortunate when setting up new legal entities or migrating data from legacy solutions. Hence, it would be a great help to just add such a standard entity making implementation and data management easier.

The entity Print management destination emails V2 doesn't allow for import of data which makes it impossible to import / migrate customer print management settings, e.g.emails. I guess it's because the entity itself only contains recid references and not a proper account id and then someone at the MS development was too lazy to make the shift to the account id and instead just made it impossible to import. But, as the print management setting is quite important in order to control who gets an invoice - this is really something that should be possible to manage data through a proper entity.