Product documentation
Delivery Confirmation

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.

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:

Challenges exist because ATP:

 

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:

 

Delivery confirmation: optimal overview and automatic (re)confirmations

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

 

Main steps

  1. Enter sales order
  2. Run Master planning (Planning optimization or classic)
  3. Update allocation
  4. Sales order delay screen
  5. Initial confirmations: Process entire order
  6. Promised Not Available: Process entire order or Process delayed lines
  7. Promise Sooner Available: Process entire order 

Italics: automatic batch job or manually.

 

Enter sales order

Sales and markering > Sales orders

If a fixed ship date is agreed with the customer, e.g. because the customer hired a crane or installation experts, switch on the flag Freeze shipment dates on the sales header. The ship date will not be moved to an earlier or later date automatically. The intercompany scenario is supported too.

 

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. The bold printed allocation types are certain enough to confirm a ship date to the customer.

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, and are now allocated against on hand, are visible in the promised sooner available list.

Use button Process entire order 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. When the confirmation is posted and printed, the confirmation action will be blanked automatically.

 

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:

Then in the commercial company:

 

Optional manual action on sales order

Sales and marketing > Sales orders > Tab Sell >> Group Actions > Align confirmed date

On sales orders where all open sales lines have a confirmed ship date, copy the last confirmed ship and receipt dates to the header.

This function is also executed when Process entire order is used on the Sales order delays screen

 Note

The logic in Delivery Confirmation that updates sales order shipping and receipt dates skips the standard ATP recalculation which can force the order to the end of the queue if newer orders were added eversince. Do not modify the sales ship dates on the lines manually. Instead use Process entire order or Process delayed lines in the Sales order delay screen.
   

 

 Release notes

Feature Introduced in version
  • Align confirmed dates sales header added
  • IC support for freeze shipment dates
  • PSA (Promised Sooner Availble) - Process entire order enabled 

10042.25011400

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

10036.60.100