Liquid error: Value cannot be null.
Parameter name: key
Microsoft Dynamics 365
Agree with this idea - currently if someone attempts to change the currency and price before creating the PO, the PO picks up the new price but not the new currency. The PO is therefore created with the correct value but the incorrect currency. Then when the currency is changed on the PO, the PO recalculates the purchase price value based on the currency exchange which makes the price incorrect, which means they then also need to update the price on the PO again --- If the option is there to change the currency and price of the line before creating the PO then the PO should be created as per defined criteria. The current process is misleading and the number of steps required to then correct the PO is messy and confusing.
This will also be interesting when using primary and secondary operations
We have same issue in France and it must be review asap because lot of customers dissatisfaction.
Customer has the need to store associate the sales order inventtrans with load info. the same as feature "Associate purchase order inventory transactions with load"
Yes, DRP is "hard to model" and I'm sure that every large organisation tries to solution DRP with available tools, but inevitably there are omissions and gaps that make the planning solutions imperfect.
To balance resources across a large organisation with National and Regional Distribution Centres and local warehouses is challenging and requires automation. Optimising cost of inventory, the supply chain, warehousing and logistics, assets and human resources is the nirvana for many such organisations. The ability to respond to change, be it organisational, product or supply chain related, in this environment, requires serious technology assistance.
In order to attract such organisations, who have the desire to get closer to nirvana, to the MS D365 suite, MS will need to address some complex aspects of planning.
Pooling non-stocked demand from local warehouses into regional DCs where the demand level could warrant inventory (for the item) is essential to optimising distributed inventory cost with delivery lead times.
Having some kind of link, would be good. I even raised a Microsoft support ticket for this and there is now way to link work or shipments back to the packing slip (delivery note in Australia).
To me that is a fundamental floor in the design, as the packing slip is supposed to be the document that bridges between warehouse dispatch of a shipment and the invoice.
We use it to accompany the goods and are planning to do some extensions so we can capture that data, as we are now using containerisation and want to put extra information about the container structure on that document, so the customer can reconcile the individual containers to the delivery note when they receive the goods.
We chose the delivery note, as that is the one that then gets used in turn by the customer's finance team to reconcile against the invoice. Having yet another document for the customer is only confusing.
This is surely a bug in the system whereby it allows you to post to a subledger from a general journal when a sub ledger is stopped. Please can this be reviewed to maintain posting control.
Thanks for requesting this. This would be very helpful.
Also it would be great to get an option on assemble to order to update the assembly before the shipment.
Definitly, we need multi currency with the migration tool. All transactions in summary or in detailed if possible should be imported in originating currency.
Also in BC, if the exchange rates are already imported, the migration should consider importing the exchange rate of the transaction in GP.
Sometimes a transaction use a different exchange rate in a same day, in the migration tool, it would be really great to get the same historical information from GP to BC.
Please add the originating currency in General Ledger entries in BC, it is not available right now in BC.