The D365 Scheduling Behavior That Quietly Pushes Your Production Orders Months Into the Future

Why Outside Processing Is Derailing Your Production Schedule

A production order that should be halfway through production is sitting untouched, scheduled to start three months from now. Nobody flagged it. Nobody moved it. The scheduling engine moved it, automatically, silently, and repeatedly, and nobody knew it was happening until the customer called.

This is the OSP queue time bug in D365 Finance and Supply Chain, and it is one of the most damaging scheduling failures I have documented in a live manufacturing environment.

How Outside Processing Works in D365

When a production order includes an outside processing operation, a step where components are sent to a vendor for a service like heat treating, plating, or specialized machining, D365 generates a purchase order automatically to represent that vendor relationship. The queue time on the OSP operation is what tells the scheduling engine how long the part will be at the vendor. It accounts for transit time, vendor lead time, and any buffer the planner wants to build in.

This is the right design. Queue time is the correct mechanism for representing OSP duration in a finite capacity environment. The problem is not the concept. The problem is what D365 does with it on every reschedule.

What the Bug Does

Every time a production order is rescheduled, D365 updates the requested receipt date on the linked OSP purchase order. It adds the full queue time of the OSP operation to the requested delivery date on the purchase order.

If the queue time is 30 days, the requested receipt date moves 30 days into the future from the moment of the reschedule.

That date matters because it drives two things: when the vendor is expected to return the part, and when raw materials need to be available for the production order to start. When the requested receipt date is pushed out by 30 days, the raw material availability date follows. When raw material availability is pushed out, the production order start date follows. The entire order moves, not because capacity changed, not because the vendor changed, not because anything meaningful changed, because the system recalculated a date it should have left alone.

Now reschedule again. The date moves again. Reschedule a third time. It moves again. Each reschedule compounds the previous one. Production orders that were scheduled to start this week are now scheduled to start in three months. The order disappears into the future, buried among thousands of other orders, invisible until someone goes looking for it, or until the customer calls.

Why It Goes Undetected

The dates look plausible. A production order scheduled three months out doesn't immediately raise an alarm in a busy planning environment, unless someone knows what the original schedule looked like and notices the drift. In most environments nobody is tracking that comparison systematically. The planner sees an order with a future start date and assumes it's on track. The order falls off the radar.

The problem surfaces at one of two moments. The first is the customer call, the part was due last week and nobody has started it yet. The second is an expedite request that traces back to an order that has been silently pushed out through six months of routine rescheduling.

Both of these moments arrive too late to prevent the damage. The overtime, the expedited shipping, the customer conversation -all of it was avoidable if the order had been caught when it first started drifting.

What Makes This Particularly Hard to Diagnose

The scheduling engine is doing exactly what it was built to do. It is recalculating dates based on the information available to it. The problem is that the information it is using — the requested receipt date on the OSP purchase order, is wrong, and it gets more wrong with every reschedule.

This is a documented Microsoft bug. It is not a configuration error. It is not a training gap. It is not something an implementation partner can prevent by setting up the system correctly. The behavior exists in the standard D365 scheduling engine and affects any manufacturer using finite capacity planning with outside processing operations.

Most implementation partners do not know it exists. The manufacturers who discover it usually discover it the hard way, through a pattern of late shipments they cannot explain, fire drills that keep repeating, and a planning team that has learned to distrust the schedule. For manufacturers who catch it during testing, the impact is serious enough to stop a finite capacity implementation in its tracks. The schedule produced by the system cannot be trusted until the behavior is resolved, and most teams do not have the diagnostic depth to know what they are looking at or how to fix it.

The Scope of the Problem

Any manufacturer on D365 FSC that uses outside processing in their production routes is potentially affected. The severity depends on how frequently orders are rescheduled and how long the OSP queue times are.

A 30-day queue time that compounds across six reschedules can push an order's start date nearly six months beyond where it should be.

In a make-to-order environment where customer delivery dates are fixed commitments, that kind of drift is not recoverable without significant cost.

This Is Fixable

We have documented this bug, tested workarounds, and implemented a code-based solution in a live manufacturing environment. The fix requires a custom X++ extension, it is not something that can be resolved through configuration alone, but once in place, the scheduling engine stops compounding the dates and production orders stay where they belong.

If your planning team is seeing orders that keep moving into the future without explanation, or if your OSP-linked production orders consistently end up late despite appearing on track, this behavior is worth investigating. And if your finite capacity implementation stalled or was abandoned because the schedule couldn't be trusted, this may be the reason nobody could identify at the time.

Kerry Kennedy is a fractional operations and D365 FSC consultant specializing in finite capacity planning implementations. If your production orders are drifting and you suspect outside processing may be the cause, schedule a 30-minute conversation.