Business value

Confirm realistic ship dates: in trade and wholesale, it is key to be transparant to your customers about expected and confirmed ship dates. If the availability of a product depends on a purchase order, it is better to await the vendor's answer before confirming a ship date to the customer.

In many cases it is both the wish of the customer and the wholesaler to ship orders in full on time (aka. DIFOT or OTIF).

"On time" is often measured against the confirmed ship date or confirmed receipt date. In general, these dates should not be confirmed yet if they are only based on assumptions about an fixed purchase lead time, without knowing the answer of the vendor. "In full", i.e. the last available sales line determines the ship date of the whole order.

Promised not available: any disturbances that result in a later receipt should be communicated as soon as possible once there is no reasonable alternative to keep the promised confirmed dates.

Promised sooner available: when a receipt is expected earlier, maybe the goods can be shipped to the customer earlier than the already confirmed ship date. However, one should be careful not to overpromise with the risk of recalling the good news again. Therefor wait until the goods are actually physically on hand in the warehouse.

Dynamics Delivery Confirmation supports these requirements by adding new powerful overview screens and automatic mass-update functions to standard Microsoft Dynamics 365 for Finance and Operations.

Standard Available to Promise

Standard Microsoft Dynamics 365 for Finance and Operations comes with out of the box ATP functionality. When a sales order line is entered, the ATP function plots the available inventory per day, up to the end of the ATP time fence.

In short, ATP defines the current inventory, immediately subtracts all stock that is already promised within ATP time fence.

Expected stock receipts are added to the projected stock on the expected receipt date, with a horizon equal to the ATP time fence.

The date at which ATP finds enough available stock, is returned to the sales order line as requested ship date, and if applicable this date is postponed automatically according to ship calendars, transport calendars and receipt calendars.

If ATP does not find enough stock within the ATP time fence, the requested ship date is postponed to ATP time fence + 1, and if applicable this date is postponed automatically according to ship calendars, transport calendars and receipt calendars.

The ATP functionality is also available from the sales order header through the button Calculate delivery dates. This function allows to move the confirmed ship dates of all lines in the sales order to the latest calculated date.

Within the standard delivery date control types, in general, ATP gives the most reliable results, if:

• a company ships partially from stock and partially purchases to order, and
• ATP time fences are aligned with purchase lead times, and
• purchase lead times are more or less predictable, and
• no disturbances occur
• orders are not touched later  

Challenges exist because ATP:

• is always calculated for the current situation on this very moment (difficult to reproduce later)
• will return different results if recalculation is executed on a later date (order might become the last in queue again)
• does not take into account that some vendors need to confirm the purchase order
• does not cope well with varying purchase lead times (sometimes the vendor must purchase at his supplier)
• can not react on typical disturbances in the supply chain (delayed ETA of a container etc.)
• has only basic support for sending sales order confirmations based on realistic confirmed ship dates
• has no support for updating confirmed ship dates in case of disturbances in the supply chain

Standard Master planning

Once the requested sales line ship dates are set through ATP, the Master planning should handle the supply chain. Master planning (both classic and optimized planning service) can provide an overview of delayed sales order lines.

Challenges exist because Master planning:

• only shows the delayed sales lines, but does not give an overview per sales order
• can not update the confirmed ship dates automatically in line with the Master planning calculations
• does not discern between purchase orders that are already confimed, or still need to be confirmed by the vendor
• does not take into account the uncertainty induced by unconfirmed purchase lines for components and subcomponents
• has no automatic batch functionality to align different ship dates on the same sales order (only if calculate confirmed dates is started manually for each sales order)

Aligned process: optimal overview and automatic (re)confirmations

Dynamics Delivery Confirmation solves these challenges by adding new functionality and aligning all steps in the following process:

• Sales order is entered or imported from external sources
• The requested ship date on the sales header is regarded as earliest ship date
• ATP returns the expected ship dates based on best guess
• Master planning covers the demand through current inventory, open supply orders and new proposed planned purchase orders
• Planned orders are firmed into purchase orders and sent to vendor
• Vendor replies and communicates confirmed dates, e.g. through the vendor portal
• Confirmed dates on purchase order lines are processed automatically
• Master planning runs again and allocates the inventory and open supply orders to the open demand
• The planned supply allocation per sales order is visible, including the level of certainty of the supply
• Confirmed ship dates and confirmed receipt dates can automatically be applied to sales order lines with a "certain" supply allocation
• Sales confirmations can be sent automatically after a sales line has a confirmed date
• Disturbances in supply chain are visible in a Promised not available list, and can be auto updated incl. a sales re-confirmation
• Earlier receipts are visible in a Promised sooner available list, and can be auto updated incl. a sales re-confirmation

Update allocation

Master planning > Run > Update allocation

Immediately after each Master planning run, the Update allocation (for the same master plan) should run in batch.

The logic travels through the master planning transactions from vendor via production and transfer orders to the customer, and updates the allocation type on each transaction.

This allocation type can have different values, ranging from least certain to most certain.

• Planned PO
• PO pending confirmation
• Confirmed PO line
• Production
• Transfer
• On hand

The Planned PO and PO pending confirmation are considered as not certain, and therefor if the sales order directly or indirectly is allocated with supply like planned PO or PO pending confirmation, the sales order ship dates should not be confirmed to the customer. So if we produce a car and the sub-sub-BOM of this car contains a dust cap on the wheel that has no confirmed PO date, we cannot confirm the car yet.

On the vendor, it is possible to specify: Vendor ships without confirmation. In this case after firming the planned PO, the allocation status becomes Confirmed PO line. Even if there is no real confirmation, this PO line is treated as confirmed.

Sales order delays

Sales and marketing > Sales orders > Order confirmation > Sales delays

In this form, the upper grid displays the sales orders that need either a first confirmation or a re-confirmation after a change in the supply chain. The lower grid displays the sales order lines for the selected sales order.

The allocation type of the order is equal to the least certain allocation type of the lines

Button [Process entire order]

If the allocation type of the order is not Planned PO and not PO pending confirmation: the confirmed ship dates for the whole order are moved to the latest ship date on any of its lines.

Sales lines for which no sales confirmation exists yet, get confirmation action "Confirmation". Sales lines for which a sales confirmation already exists, and the new confirmed date differs from the previously confirmed date, get confirmation action "Changed".

Button [Process delayed lines]

If the allocation type of the order line is not Planned PO and not PO pending confirmation: the confirmed ship date of each line is set according to the Master planning's calculation, incl. delays.

Sales lines for which no sales confirmation exists yet, get confirmation action "Confirmation". Sales lines for which a sales confirmation already exists, and the new confirmed date differs from the previously confirmed date, get confirmation action "Changed".

Filter [blank]

All sales orders that contain one or more lines which should be confirmed or reconfirmed are displayed.

Filter [Promised not available]

All sales orders that contain one or more sales lines that have been confirmed on a sales confirmation, and for which the Master planning calculates a delay, are visible in the promised not available list. Use button Process entire order or Process delayed lines to update the confirmed dates and the confirmation action Changed automatically.

Filter [Promised sooner available] 

All sales orders that contain one or more sales lines that have been confirmed on a sales confirmation, are now allocated against on hand, are visible in the promised sooner available list. Use button Process entire order or Process delayed lines to update the confirmed dates and the confirmation action Changed automatically.

Note that the new ship date will never be earlier than the requested ship date on the sales header (= earliest ship date).

Be aware that not all customers are interested in receiving the goods earlier than confirmed, because they might also have anticipated on the later ship date.

Process delays

Master planning > Run > Process delays

This function can run in batch and will update the confirmed dates either per order line, or will shift the dates of the whole sales order to the latest ship date.

Generate sales confirmations

Sales and marketing > Sales orders > Confirm sales order

Setup a batch job that includes all sales lines where confirmation action = Confirmation and / or Changed.

Auto consuming receipt margin

This is standard functionality: when the receipt margin is 3 days, Master planning calculates back: the receipt should be 3 days earlier than needed for the issue.

But if the receipt date is postponed by 3 days, the issue date is can be the same day as the receipt date without any delay.

Note that this behavior applies to receipt margin, whereas issue margin is never consumed.

Intercompany

If the commercial company purchases at the logistical company the Master planning and Update allocation should run in both companies.

Procedure

First in the logistical company:

• Run Master planning
• Update allocation
• Process the delays automatically.
• Now the dates in the IC purchase order are auto-updated too

Then in the commercial company:

• Run Master planning
• Update allocation
• Process the delays manually through the sales order delays screen, or automatically.
• Generate sales confirmations

 Release notes

Feature	Introduced in version
First release Multi level allocation for production orders improved	10036.60.100