Delivery Date Fields on the Sales Order Line — Deep Dive
SO Transport Days
Related fields:
Delivery Date Fields on the Sales Order Line
A deep dive into every date, control, and status that drives order promising in D365 Finance & Operations
Think of these fields as a "promise pipeline"
The customer asks for a date → the system calculates what is actually possible → the system promises a date back to the customer. Every field on the Delivery tab plays one role in that pipeline.
1. Requested Ship Date
What it is: The date the customer wants the goods to leave your warehouse. It is the starting point of the whole promise — what the customer asked for, not what will actually happen.
How it is filled
- Manually entered by the order taker, or
- Defaulted from Requested receipt date − Transport days − Delivery time.
- On new SO lines, it defaults from the header requested date.
Key rules
- Editable until the order is invoiced.
- Drives ATP / CTP calculation together with Delivery date control.
- If Delivery date control = None, it is copied to Confirmed ship date without any check.
2. Requested Receipt Date
What it is: The date the customer wants the goods to arrive at their location. This represents the customer's real business need.
Key rules
- Changing one automatically recalculates the other via Transport days.
- Used as the target that ATP / CTP tries to meet.
- Reported on customer-facing documents like Sales confirmation.
3. Confirmed Ship Date
What it is: The date the system promises the goods will actually leave your warehouse. This is your internal commitment. Master planning, warehouse work, picking, and shipping all use this date, not the requested one.
How it is calculated
| Delivery Date Control | How Confirmed Ship Date Is Calculated |
|---|---|
| None | Copied directly from Requested ship date. No availability check. |
| Sales Lead Time | Order date + Sales lead time. |
| ATP | Earliest date when cumulative ATP ≥ order quantity. |
| ATP + Issue Margin | ATP date + Issue margin (pick/pack preparation). |
| CTP | Master planning explosion considering material and capacity. |
| CTP for Planning Optimization | CTP calculated by the Planning Optimization add-in. |
Key rules
- May differ from Requested ship date if availability is not sufficient.
- If it slips, the SO line typically triggers a delivery date warning.
- Drives picking wave scheduling and outbound work.
4. Confirmed Receipt Date
What it is: The date the system promises the goods will arrive at the customer. This is the number you tell the customer — the confirmed ship date translated to their location using Transport days.
Key rules
- Printed on Order confirmation, Packing slip, and Invoice.
- Used for on-time delivery (OTD) KPIs.
- If Delivery date control = None, it mirrors the Requested receipt date.
5. Delivery Date Control
What it is: The rule the system uses to calculate confirmed ship/receipt dates. Think of it as the brain behind order promising.
| Value | Meaning | When to Use |
|---|---|---|
| None | No calculation. Confirmed dates = Requested dates. | Simple businesses without inventory constraints. |
| Sales Lead Time | Uses a fixed lead time. Ignores stock and supply. | Made-to-stock with predictable throughput. |
| ATP | Uses uncommitted inventory, planned receipts and issues. | Distribution and stocked businesses. |
| ATP + Issue Margin | ATP + extra pick/pack margin. | When shipment preparation time matters. |
| CTP | Master planning explosion considering material and capacity. | Make-to-order manufacturing. |
| CTP for Planning Optimization | CTP calculated by the Planning Optimization add-in. | Modern master planning users. |
Configuration hierarchy (overrides)
Global default
Accounts receivable > Setup > Accounts receivable parameters > Shipments > Delivery control.
Per released product
Released products > Manage inventory > Override delivery control.
Per sales order (header or line)
Highest priority. Overrides the released product and global setting for that specific line.
6. Batch CTP Status
What it is: The state of the CTP explosion for this line when Delivery date control = CTP. It tells you whether the confirmed date on the line can be trusted.
Ready
CTP has not been triggered yet, or the explosion completed cleanly. (This is what your screenshot shows.)
Started
The CTP explosion is currently running in the background.
Waiting
Queued and waiting for a batch server to pick it up.
Error
The CTP explosion failed. Check the Infolog and Batch history — the confirmed date may be stale.
Key rules
- Only relevant when the line uses CTP or CTP for Planning Optimization.
- Appears grey / read-only for other delivery date control methods.
- Reset automatically when the line is re-promised.
7. Planning Priority
What it is: A numeric field (0–255) that tells master planning how important this line is compared to others. Higher number = higher priority.
Where it is used
- Planning Optimization with priority-based planning enabled.
- Priority-based sorting in Delivery alternatives.
- Firm and fair-share allocation logic in supply reservations.
8. Simulate Delivery Dates
What it is: An action, not a stored date. Opens the Simulate delivery dates dialog that runs the order-promising calculation without saving the result.
Purpose in delivery
- Preview what confirmed dates would be under each Delivery date control method.
- Test whether the Requested date can be met before committing.
- Compare Sales lead time vs. ATP vs. CTP outputs side-by-side.
Behind the scenes, it calls the same routines as production order promising but writes to a temporary structure. Nothing is persisted until you click Update dates.
9. Delivery Alternatives
What it is: A companion feature to Simulate delivery dates. Opens a screen that shows alternative options to meet the customer's requested date.
Split delivery
Ship the quantity across multiple dates (partial shipments).
Alternative warehouse
Switch to another warehouse with better availability.
Faster mode of delivery
Use a mode of delivery with shorter transport days.
10. How the Fields Flow Together
Here is the actual timeline for a single sales order line, from customer request to invoice:
Warehouse and outbound work always follow the Confirmed dates, not the Requested ones. Customer-facing documents show the Confirmed receipt date.
11. Deep-Research Notes Worth Knowing
Things every consultant should remember
- Working-day calendar effect — Calculated dates roll forward to the next open day on the site's shipping calendar.
- Warehouse follows Confirmed, not Requested — Outbound work, waves, and load planning all use Confirmed ship date.
- Recalculation trigger — D365 only recalculates the confirmed date if the current one can no longer be met.
- OTD metric — On-Time Delivery is measured against Confirmed receipt date, not Requested.
- Batch CTP status lives on the line — Each SO line runs an independent CTP explosion.
- Priority + reservation policy — Priority-based reservation is required for Planning priority to actually win over FIFO.
- Delivery date control = None is dangerous at scale — Real HOYA-style projects usually enforce Delivery date control ≠ None for customer-facing SOs.
- Direct delivery orders — For drop-ship, Confirmed dates come from the linked PO, not your own warehouse.
12. Sources Used for This Deep Research
| Source type | Reference |
|---|---|
| Microsoft Learn | Order promising — Supply Chain Management | Dynamics 365 |
| Microsoft Learn | Delivery dates and available-to-promise calculations |
| Microsoft Learn | Simulate delivery dates |
| Microsoft Learn | Delivery alternatives |
| Microsoft Learn | Priority-based planning |
| Microsoft Learn | Transport days and shipping calendars |
| Application Help | Sales order Delivery tab field reference |
| Community | Dynamics Community & LinkedIn posts on Batch CTP status behavior |
Key Takeaway
Every field on the Delivery tab plays one specific role: Requested = what the customer wants, Confirmed = what you promise, Delivery date control = the rule that connects them, and Transport days + Planning priority = the modifiers that make the promise realistic.