Intercompany Master Planning in D365: Planned Intercompany Demand and the Plan Run Sequence

The first two articles in this intercompany series dealt with documents: the trading relationship and its policies, and then the order chain that those policies produce once a purchase order is confirmed. Today I want to go one step earlier in time, to the point before any order exists, because this is where most intercompany implementations quietly underperform. The selling entity plans, sees it needs stock from the sister company, and creates planned purchase orders. The supplying entity plans and sees nothing, because nobody has firmed anything yet. Intercompany master planning exists to close that gap: what it does, how to set it up with Planning Optimization, why the run order matters, and what still goes wrong.

THE PROBLEM: EACH LEGAL ENTITY PLANS ALONE

Master planning in D365 is scoped to one legal entity. It reads one company's demand, supply, and coverage settings and creates planned orders in that company. To the engine, an intercompany supply chain is two or three independent planning problems. The selling entity's plan output is planned purchase orders on an intercompany vendor, and in the supplying entity those do not exist. The only demand the supplier sees from its sister company is the demand that has already been turned into intercompany sales orders, which, as I showed in the order chain article, only happens when the planned purchase order downstream is firmed and the resulting purchase order synchronises a sales order upstream.

The consequence is a planning horizon that shrinks as you move upstream. The sales entity may plan twelve months out, but the factory only sees the slice that has already been firmed into orders, typically a few weeks. Beyond that the factory covers demand with a forecast of its own, built by a different team on different assumptions. Two forecasts for the same end demand, in two companies, is the most common root cause of both excess stock and shortages in intercompany groups.

PLANNED INTERCOMPANY DEMAND: WHAT THE FEATURE ACTUALLY ADDS

Intercompany planning solves this by letting the supplying entity read the planned purchase orders of the selling entity before they are firmed. When the upstream plan runs, every unfirmed planned purchase order in the downstream company whose vendor is the intercompany vendor representing the upstream company becomes a demand line in the upstream company's net requirements. The reference type is planned intercompany demand, carrying the downstream company, planned order number, quantity, and requirement date. The upstream engine treats it like any other demand: it nets it against on-hand and existing supply and, if there is a shortfall, creates planned production orders, planned purchase orders, or planned transfers according to the item's default order settings and coverage group upstream.

Notice what this does not do. It does not create orders in either company and it does not firm anything. The downstream planned purchase order stays a planned order; the upstream supply stays planned too. What you gain is visibility across the boundary at planned level, with multilevel pegging that can be traced from a planned production order in the factory back through the planned intercompany demand to the sales order or forecast line in the selling entity that caused it. That traceability is what convinces planners: the factory can finally answer "why are we making this" with a customer order number from another company.

SETTING IT UP WITH PLANNING OPTIMIZATION

In the last article I said the planning settings live on the trading relationship. For the current engine that is only half true, so let me be precise. The trading relationship still does the mapping: it is what tells the system that vendor X in the selling company is the supplying company. The planning behaviour itself is configured on the master plan of the supplying entity. The steps, in the order I do them:

1. Release the products in every company in the chain, and make sure the item in the selling entity has the intercompany vendor as its default purchase vendor, either on the released product or through the item coverage record. No vendor on the planned purchase order means nothing to map upstream, and the demand never crosses.

2. Give the planned purchase orders downstream sensible default dimensions. Site and warehouse on the downstream planned order drive the upstream dimensions through the order defaults from the setup article; a blank warehouse produces demand that plans against the wrong site, or none.

3. In the supplying entity, open the master plan you run there (Master planning, Setup, Plans, Master plans), go to the Intercompany planning FastTab, and set Include planned downstream demand to Yes. A grid called Downstream plans appears; add one line per downstream company, naming the company and the master plan in that company whose planned orders should be read. This is the detail people miss: you are pointing at a specific plan, not at the company. If the selling entity runs a static plan and a dynamic plan, as I recommended in the static versus dynamic article, decide which one the supplier should listen to. For the nightly run it should be the static plan, so the factory is not chasing every simulation tried in the dynamic plan.

4. Repeat step 3 for every link in the chain. In a sales, distribution, factory chain, the distribution entity's plan includes the sales entity's plan as downstream, and the factory's plan includes the distribution entity's plan as downstream. The factory does not list the sales entity directly; demand arrives through the distributor's planned purchase orders, the same way the goods will travel.

WHY THE RUN SEQUENCE MATTERS

Because each company still plans itself, the planned intercompany demand that the upstream plan reads is whatever the downstream plan last produced. Run the factory at 02:00 and the sales company at 03:00, and the factory has planned against yesterday's planned purchase orders; today's new sales orders reach it tomorrow night. Over three entities that is a two-day lag in a chain with perhaps one day of transport between them. The rule is therefore simple and must be enforced in the batch schedule: run the plans from the furthest downstream company to the furthest upstream company, in that order, and do not start an upstream run until the downstream one has finished.

With Planning Optimization each run is a separate batch job in its own legal entity, so sequencing is a scheduling problem rather than a planning parameter. I set it up as one batch job with one task per company and explicit dependencies between the tasks, rather than three jobs with staggered start times. Staggered times work until the night a downstream run overruns and the upstream job starts anyway. Readers still on the built-in engine will recognise the older Intercompany master scheduling job with its iterations and primary and secondary calculation principles; that engine is deprecated, and I would fold the move to Planning Optimization into the same project.

WHAT HAPPENS WHEN SOMEBODY FIRMS

When the planner in the selling entity firms a planned purchase order against the intercompany vendor, the purchase order is created, and, through the trading relationship, an intercompany sales order appears in the supplying entity. From that moment the supplying entity has two possible views of the same demand: the real sales order line, and the planned intercompany demand that used to represent it. The engine handles this correctly, but only on the next upstream run: the downstream planned order no longer exists, so its planned intercompany demand disappears, and the sales order line takes its place. Between the firming and that next run, anyone reading net requirements upstream sees the demand twice. So read the upstream picture after the nightly run, not after a lunchtime firming session.

The same logic applies to the firming time fence. If the selling entity automatically firms planned purchase orders within, say, ten days, then inside that window the supplier sees sales order demand and outside it planned intercompany demand. Keep the fence short: a long one converts planned visibility into committed orders that are expensive to change, which was the whole problem with the order chain.

LEAD TIMES ACROSS THE BOUNDARY

The requirement date of the planned intercompany demand upstream is the order date of the downstream planned purchase order, because the downstream purchase lead time has already been consumed between the sales order date and that order date. So the purchase lead time on the item in the selling entity must represent the transport and handling time between the two companies, and nothing else. Manufacturing or purchase lead time belongs upstream, on the factory's item. A forty-day purchase lead time on an intercompany item usually means somebody added the factory's production time to it before intercompany planning existed, to make the dates look right. Once planned demand flows, that double counting pushes every planned production order forty days early.

WHAT GOES WRONG

• The demand never arrives upstream. Nine times out of ten the downstream planned order has no vendor, or a vendor that is not intercompany for the supplying company, or the Downstream plans grid points at a plan nobody runs.

• The demand arrives with the wrong site. The downstream planned order carries a warehouse whose default order settings map, through the trading relationship, to a site upstream that does not make the item. Check the planned intercompany demand lines in upstream net requirements first.

• Doubled demand that never clears. If the downstream plan is not rerun after firming, the firmed planned order lingers as planned intercompany demand because upstream reads a stale downstream plan. A sequencing issue, not an engine fault.

• Both companies forecasting the same end demand. Once planned intercompany demand flows, the supplier's own forecast for those items should be removed or reduced to the independent portion, otherwise forecast and planned demand add up. Use the forecast reduction settings in the coverage group I covered in the coverage group article, and be deliberate about which company owns the forecast.

• Direct delivery lines. They still generate planned intercompany demand, but the dates belong to the end customer, so the transport-only lead time assumption is often wrong for them. Treat them separately.

Before declaring intercompany planning live, confirm: intercompany default vendor downstream, correct site and warehouse on planned purchase orders, the right downstream plan in the upstream master plan, batch dependencies that run downstream first, a short firming fence, transport-only lead time downstream, and a forecast in one company only.

Next time I will look at intercompany pricing and transfer prices: where the intercompany sales price comes from, how trade agreements, cost plus markup, and fixed transfer price lists compare, and how the choice affects margin reporting in each legal entity.

In this series: previous article The Intercompany Order Chain in D365: Synchronisation, Direct Delivery, and What You Can Change