Capable to Promise in Dynamics 365 F&O: Which Levers Actually Move the Date

A rep has a customer on the phone. The customer wants 400 of something the company builds instead of stocks, and the question is the one it always is. When can I have it?

If that answer comes from a planner's spreadsheet, or from a rep who tacks two weeks onto whatever the last quote said, you already know how the story goes.

Capable to promise is the piece of Dynamics 365 Finance and Operations that tries to answer the question out of the system's own data.

What CTP is doing that ATP isn't

Microsoft's framing is clean. ATP looks at material availability and assumes your resources have infinite capacity.

CTP looks at material AND capacity.

The example in the docs is the easiest way to hold onto it. Item A is built from items B and C, and you've got zero A on hand. Run an ATP check and you get zero. Run a CTP check and the system looks at whether you have B and C, whether you have the resources to turn them into A, and how many A you could produce. It'll go a level further and check whether you could make more B and C too. CTP is an explosion, run for one sales line, that comes back with a confirmed ship date and a confirmed receipt date.

So on a make to order item CTP can hand you a bigger number and an earlier date than ATP, because ATP only ever sees an empty bin.

The trade is speed. CTP has to walk the BOM and the route and consider capacity, so it's a heavier calculation, and Microsoft says as much.

Their (Microsoft) advice is to pick the method per item based on whether the thing is produced to stock or built to order.

Where the setting lives

Delivery date control is the switch, and it exists at four levels.

The company default sits at Accounts receivable > Setup > Accounts receivable parameters, on the Shipments tab under Delivery control. Your options are None, Sales lead time, ATP, ATP + Issue margin, CTP, and Batch CTP.

Per product, you override it at Product information management > Products > Released products, then Default order settings on the Manage inventory tab. Turn on Override delivery control and pick a method.

Then the sales order header and the sales order line can each override again. New lines inherit the product override if there is one, otherwise the company default.

In practice the product level is where the real design work happens, because that's where you decide which items are stock items and which are build items.

The levers inside F&O

Which engine, and which flavor of CTP

This is the part that trips people up probably because the documentation is inconsistent.

Planning Optimization is the only planning engine now. The Use Planning Optimization toggle is on and greyed out, and only in rare cases will Microsoft Support enable the deprecated engine for a specific company. Drop a duck emoji if you're one of those customers.

That matters because CTP used to be a built in engine feature. Microsoft first shipped a CTP calculation for Planning Optimization that runs off a dynamic plan, and in version 10.0.41 renamed that delivery date control option from "CTP for Planning Optimization" to Batch CTP, which describes it better. In the same version they shipped Near real-time CTP, which lets you use the standard CTP option with Planning Optimization and calculates the confirmed dates in the background without blocking the UI. Those two are your real choice today.

With Batch CTP, the confirmed ship and receipt dates stay blank until a dynamic plan runs. You schedule that plan as a recurring batch job, and the Batch CTP status field on the line tells you Not ready or Ready. Run the plan every 30 minutes and your worst case wait for a date is 30 minutes. That's fine for EDI and portal orders, and it's painful for a rep on the phone.

With standard CTP and Near real-time CTP turned on, the dates get set every time you save a sales line, and they recalculate when you change quantity or site. You need 10.0.41 or later and two features enabled in this order: Improve Planning Optimization performance by merging and queueing plan regeneration jobs first, then Near real-time CTP. The first one exists because several reps hitting CTP at once used to collide with "Another job for the same plan is currently in progress." The queueing feature merges up to 10 planning requests into one job by default, with a default queue depth of 20.

The plan behind the answer

CTP is only as honest as the plan it explodes against, and the dynamic plan's time fences are the quiet lever nobody adjusts after go live.

Coverage time fence sets your planning horizon and has the largest single impact on run time. Capacity time fence controls how far out the system considers maximum resource capacity when it schedules. If a planned production order lands outside the capacity time fence, the lead time comes from the item's delivery time instead, which means your CTP date for anything far enough out is really just a lead time calculation wearing a costume.

Lead times, and the floor under every CTP date

CTP offsets delivery dates to the sales lead time at minimum. That's a floor, and it's a lever. A sales lead time of five days on a product means CTP will never promise it sooner than five days out, no matter what the explosion finds.

Below that, the usual suspects all feed the answer: purchase lead time on the item and on the approved vendor, production lead time, transfer lead time, and whether coverage settings are pushing planned orders out.

Order entry deadlines

Order entry deadlines are a cutoff time by day of week that decides whether an order counts as today's or tomorrow's. The default is 23:59, which means most implementations have them configured and inert. You can build order entry deadline groups and assign them to customers, and you can set deadlines per site in that site's own time zone, with daylight saving handled for you. If you've got a two coast distribution footprint and your reps are somewhere in the middle, this is the setting that makes the promise real instead of aspirational.

Margins

Issue margin is the prep time before shipping, and it's the only difference between ATP and ATP + Issue margin. Receipt margin and reorder margin push supply earlier. Small numbers, and they add up across a BOM.

Delivery alternatives

The Delivery alternatives page is underused. From a sales line, Products and supply > Delivery alternatives gives the order taker a list sorted by receipt date, with the ability to change mode of delivery and see the effect immediately, to include partial quantity, and to include later dates when something other than speed matters.

Know the limits before you demo it on a CTP line, though. Include other product variants isn't available for CTP. Include procurement, which surfaces external vendor and intercompany options, works for ATP and ATP + Issue margin only. What CTP gives you instead is an explosion of the selected alternative, and the warehouses it suggests include the current one, the default one, any with on hand, any with supply orders, and any with an active BOM version.

Keeping the promise after you've made it

This is the part that used to make CTP feel unsafe. You promise a date on Tuesday, the plan reruns Wednesday night, and the material you were counting on gets pegged to a newer order.

Keep supply for confirmed demand in Planning Optimization, also 10.0.48 and later, is the fix. It preserves planned orders, pegging, routes, route jobs, and capacity reservations across planning runs for any open sales line with a confirmed ship date, at every BOM level. Microsoft also has a release plan item called Protect confirmed CTP dates with Planning Optimization, with general availability scheduled for September 2026, that extends the same protection to material and capacity allocated to CTP confirmed lines.

Read the fine print on the first one. It doesn't honor the Period coverage code for confirmed supplies created between runs, it won't revisit product substitution once a requirement is confirmed, and co-product and by-product demand isn't treated as confirmed even with a confirmed ship date.

Order promising only recalculates when the existing date can no longer be met.

Increase a quantity so the July 20 promise slips to July 25 and the system updates. Decrease a quantity so July 15 becomes possible and the system leaves July 20 alone, because July 20 still works.

What usually stays out of F&O

I've never had a CTP conversation where the right answer was to put all of it in F&O. Plenty of it belongs somewhere else.

Detailed scheduling is the big one. Master planning does finite capacity against resource calendars, which is genuinely useful, but it won't optimize a sequence for you. If you live and die by sequence dependent setup, changeover matrices, campaign batching, or tooling constraints, that work happens in a scheduling tool sitting next to F&O, and the promise date comes back as an input.

Labor is the second one, and it catches people off guard. Planning Optimization's fit analysis still lists requirement types for skills, courses, certificates, and titles as a future wave. If your bottleneck is three certified welders rather than the weld cell itself, F&O is modeling the wrong thing.

Is CTP more important than ATP?

For most companies, no. ATP is the workhorse and CTP is the specialist.

The volume argument is the strongest one. The vast majority of order lines in most businesses are stocked items where capacity was never the constraint. ATP is also fast enough to run everywhere, including behind a website, and CTP isn't. And a bad ATP setup breaks every order in the company, while a bad CTP setup breaks the configured lines.

Importance and accuracy aren't the same thing, though. On an assemble to order or make to order item, ATP isn't just imprecise, it's wrong in a specific and expensive way: it reports zero on something you could ship in nine days. That's either a lost order or an invented date.

The way I put it to clients is that ATP is more important to your business and CTP is more important to your hardest customers. Pick per item, not per company. That's exactly why the delivery date control override lives on the released product.

So if you're considering it, start with the item list. Figure out which products are genuinely built to order and how much of your revenue they carry. If the answer is a handful of SKUs and eight percent of revenue, go fix your ATP setup and your Inventory Visibility feed instead. If the answer is most of what you sell, and every customer wants a date in writing, then the master data cleanup ahead of you is the real project. CTP is just the thing that finally makes it visible.

DynamicsDad