Liquid error: Value cannot be null.
Parameter name: key
Microsoft Dynamics 365
I support this idea as well and voted for it.
please considering using users language. This would support the user experience the most. You might need than a fallback language (e.g. user selected a language in which the product is not translated to)
Luc made a good suggestion that I make add some justification for this.
I am a pre-sales consultant for Business Central and we often get potential deals where Business Central will not manage the entire business - there is another (best of breed) operational system that fits the industry specific need. Of course they still want an integrated solution.
Business Central has some great integration tools these days, including API's, PowerApps, PowerAutomate etc.. - technically we can sell the dream. And customers are used to doing this as they used to in the on-premise scenario, with concurrent-style licensing.
But the (multiplexing) licensing kills the whole deal - without more licensing options we are losing the client completely, and so is Microsoft.
Metered licensing for API's would be a good solution to this, without getting into more complex modular licensing (I know F&O has an Order Lines SKU - that might work in BC for some scenarios but maybe not others).
This option will help alot the organizations and sys admins to maintain the workflow changes on paper and record them accordingly with management.
We are a Global company with multiple countries on one instance. We definitely need this feature as it is confusing for our Customer service, logistics, manufacturing and distribution teams when they can't see the correct product name in D365FO when they are creating formulas or just general inquiries and searches on the products. I would think this should be a high priority for a high end ERP system.
Definitely a great idea! We are struggling with API licensing on almost every project.
Another point which could be helpful in this context:
The customer does not see the shipment-number from our mandant, when the shipment is a drop shipment. The papers only show the shipment-number/and purchase-order-number of our vendor. Could you please implement the copying prozess from purchase to sales for this information? Then the vendor shipment-number could be printed on the sales invoice and the customer can connect the shipment to the invoice.
Otherwise the customers often have problems to connect the right shipment to the invoices.
I hope Microsoft can consider either auto-update OR providing information on new objects (i.e. table data, page, etc.) of features in used prior to the updates. Permission issue not only cause unpleasant experience to our clients, it also interrupt our client daily operations.
Now I have to create new Journey.
Make a new but same segment and add behavior to exclude old journey contacts.
Not make any sense.
What I mean add new steps, I forgot to say is add it to after the latest step.
Not add it in the middle of exist step. (I know it is not possible)
From our point of view it's definetly a very good point, too. The main intention for drop shipment processes is to use it for some kind of destination management of shipments.
Many of our customers do not use the standard drop shipment due to the posting concept of the functionality. It's to complex to work in a process like that. Also the cancelation of a process like that is not really supported well.
So please put a very helpful improvement like this on the general roadmap.