D365 Supply Chain Management Premium: Demand Planning & EDI Guide 2026

What is Demand Planning in Dynamics 365 Supply Chain Management?

Demand Planning is the forecasting module inside Dynamics 365 Supply Chain Management. It builds statistical and machine-learning forecasts from historical demand, lets planners adjust them in a spreadsheet-style worksheet, and feeds the agreed forecast into master planning. Full forecast creation and editing requires the Supply Chain Management Premium licence.

To learn more about Dynamics 365 pricing and licensing, check out our ultimate D365 guide

Two clarifications before anything else, because both cause confusion in evaluations.

Demand Planning is not the old Demand Forecasting module. Microsoft’s earlier forecasting capability in Finance & Operations was limited and widely bypassed. Demand Planning is a separate, newer application with its own worksheet interface, its own forecast profiles, and machine-learning models. If your last evaluation of Microsoft forecasting was before 2024, you evaluated a different product.

Demand Planning is not full sales and operations planning. It produces a demand forecast. Consensus S&OP — reconciling that forecast with supply constraints, finance targets and commercial commitments — is a process you run around it, partly in D365 and partly elsewhere. Any partner presenting Demand Planning as a complete S&OP suite is overselling.

Where it sits in the chain: demand signals in, forecast out, master planning downstream. Everything useful about it depends on the quality of what goes in the front.

Do you need SCM Premium for Demand Planning?

Yes, for anyone creating or editing forecasts. Standard Supply Chain Management lists at CAD $284.90 per user per month and allows only limited Demand Planning access. Premium lists at CAD $407.00 and adds full demand planning, advanced planning capabilities, additional capacity and storage, and 1,000 Copilot Credits per user per month for running pre-built and custom agents.

List prices from Microsoft’s Canadian pricing, verified August 2026. Actual pricing varies by agreement, currency and region.

The seat split is the whole business case

The mistake most evaluations make is comparing $407 against $284.90 across the entire Supply Chain Management estate and concluding the uplift is unaffordable. That is not how this works.

Ask who in your organization actually creates or edits a forecast. In most mid-market manufacturers it is between three and twelve people — the demand planners, a supply chain manager, perhaps a category lead. Everyone else in Supply Chain Management is doing procurement, warehousing, production or inventory work, and standard licensing serves them perfectly well.

In that example, eight Premium seats and fifty-two standard seats. The uplift is roughly CAD $977 per month — not the $7,300 a blanket upgrade would imply. Model your own split before you take a number to your CFO.

Two operational notes. Copilot Credits are included on Premium only; standard users can consume agent capacity but the credits must be bought separately, pay-as-you-go or pre-purchased. And running agents requires an Azure subscription, which most F&O customers already have but which occasionally surprises procurement.

Premium adds full demand planning with forecast creation and editing, Copilot-generated demand insights, enhanced product phase-in and phase-out handling, row-level security and cell-level commenting on plans, additional capacity and storage, and 1,000 Copilot Credits per user per month.

Feature lists are easy to publish and hard to act on, so here is who each capability is actually for.

Full forecast creation and editing. The core reason to buy Premium. Without it, planners can look but not plan.

Copilot-generated demand insights. Useful for surfacing anomalies and explaining forecast movement to people who do not read statistics. Treat it as an assistant to a planner, not a replacement for one.

Product phase-in and phase-out. The sleeper feature, and the one most under-discussed. If you run seasonal ranges, refresh product lines regularly, or replace SKUs as standards change, this handles the transition from an outgoing product’s history to an incoming product’s forecast. Businesses without this capability typically manage phase-outs in spreadsheets and get them wrong. For anyone in apparel, footwear, safety equipment or consumer goods, this alone can justify the licence.

Row-level security on plans. Matters enormously to a multi-brand or multi-division group where each brand’s planners should see only their own numbers, and not at all to a single-brand manufacturer. If you are a group built by acquisition, this is what makes shared planning politically workable.

Cell-level commenting. Sounds trivial. Is not. It moves the conversation about a forecast override out of email and into the plan, which is the difference between a forecast people trust and a forecast people argue about.

Capacity and storage. Relevant at high SKU counts and long history horizons. Ask your partner to size this against your actual data volume rather than assuming.

Replace it when your planning tool’s main job has become reconciling data with your ERP rather than forecasting. Keep it when it does something D365 genuinely cannot — multi-echelon inventory optimization, deep attribute-based forecasting across size and colour matrices, or sophisticated promotion modelling. The test is capability, not integration convenience.

Most consolidation arguments are made on the wrong grounds. “One vendor, one throat to choke” is a procurement preference, not a supply chain case. Here is the honest version.

Two questions cut through the evaluation faster than a feature comparison:

How much of your planning team’s week goes into moving data between systems? If the answer is more than a day, the integration is the product, and consolidating removes the actual cost.

Are you using the advanced capability you are paying for? A surprising number of businesses run a probabilistic multi-echelon engine in single-echelon mode with default settings because nobody ever finished the implementation. If that is you, you are paying premium rates for basic forecasting, and D365 will do basic forecasting inside the ERP for less.

What consolidation is actually worth

• One data model, so no reconciliation and no timing mismatches between the forecast and the ERP.

• One security model, so planners see what their role permits everywhere.

• One integration you no longer maintain, which is real money in developer time and in every upgrade cycle.

• One vendor relationship and one renewal negotiation.

• Forecast changes reaching master planning immediately rather than on the next sync.

Quantify the integration maintenance specifically. It is the number people forget and it is usually larger than they expect.

Usually three things: multi-echelon inventory optimization, deep attribute-based forecasting for size and colour matrices, and mature promotion or event modelling. D365 Demand Planning is strong at statistical baseline forecasting inside your ERP. It is not, as of 2026, a specialist optimization engine, and any partner who tells you otherwise is selling.

Being specific about the gap is more useful than reassurance.

Multi-echelon inventory optimization. If you run a distribution network with regional warehouses feeding branches, specialist tools optimize stock placement across all echelons simultaneously. D365 handles this less completely. Where it matters, keep the specialist or accept the trade-off knowingly.

Attribute-based forecasting. Forecasting a new boot at the style level and exploding it across sizes and widths, using the size curve from comparable products, is standard in footwear and apparel planning tools. It is achievable in D365 with hierarchy design and effort, but it is not the same out-of-the-box capability. If your SKU count is driven by size and colour matrices, test this specifically during evaluation rather than accepting a demo of a simple product hierarchy.

Promotion and event modelling. Tools built for retail carry mature uplift modelling and cannibalization logic. If a meaningful share of your volume moves on promotion, probe this hard.

Probabilistic forecasting. Some specialists forecast the full demand distribution rather than a single number, which drives better safety stock decisions. If your team understands and uses this, it is a real loss.

How does D365 Demand Planning actually generate a forecast?

It pulls historical demand into a forecast profile, applies a selected algorithm or machine-learning model, and produces a baseline that planners adjust in a worksheet behaving much like a spreadsheet. Planners override at any level of the product or geography hierarchy, comment on individual cells, and promote the agreed version into master planning.

The working sequence:

1. Define the forecast profile — what you are forecasting, at what level of aggregation, over what horizon, in what time buckets.

2. Load and prepare demand history — usually sales orders, sometimes shipments, ideally cleansed of distortions.

3. Generate the statistical baseline — either a chosen algorithm or a machine-learning model selected on historical fit.

4. Review and adjust — planners apply market knowledge the data cannot contain, comment on what they changed and why.

5. Collaborate — sales, category and finance input, at the level each of them actually thinks in.

6. Publish to master planning — the agreed forecast drives requirements planning.

7. Measure accuracy — compare forecast to actual, and feed that back into the next cycle.

Two points worth being blunt about.

Aggregation level determines accuracy. Forecasts are more accurate at higher levels of aggregation. Forecasting at product family and disaggregating usually beats forecasting every SKU independently, especially with intermittent demand. Getting this right is a design decision that outweighs algorithm selection.

Human in the loop is not a limitation, it is the design. The statistical baseline handles pattern and seasonality. Planners handle the things the data cannot know — a distributor’s new branch opening, a competitor exiting a category, a regulation changing a specification. Any vendor promising a hands-off forecast is describing a demo.

At minimum, two to three years of consistent transactional demand history, a stable item master with usable product hierarchies, and clearly defined units of measure. Forecast quality is capped by data quality: inconsistent item categorization, unflagged one-off orders, and discontinued SKUs left in history each degrade the model more than algorithm choice can improve it.

Demand history cleansing

This is the step evaluations skip and implementations regret. Raw sales history is not demand history. Before you forecast from it:

• Strip one-off bulk orders. A single large stocking order from a new distributor is not recurring demand. Left in, it teaches the model to expect a spike that will never repeat.

• Correct for stock-outs. Periods when you could not supply record suppressed demand, not real demand. Uncorrected, they teach the model that demand is lower than it is, and the resulting forecast guarantees another stock-out.

• Handle discontinued and superseded SKUs. History for a retired product should transfer to its replacement, not sit as a dead series.

• Flag cannibalization. When a new product takes volume from an existing one, that is a shift, not a decline.

• Separate channels. Direct sales, distributor sales and e-commerce behave differently. Blending them into one series averages away the pattern in each.

Budget real time for this. On most projects, data preparation takes longer than configuration — and skipping it produces a forecast planners quietly stop using within two cycles, which is a worse outcome than not having implemented at all.

Your own order history is sell-in, not sell-through, so it records your distributors’ buying patterns rather than end-market demand. Forecasting from it amplifies the bullwhip effect. The fix is to feed distributor point-of-sale and inventory data — usually EDI 852 — into Demand Planning alongside your own orders, and forecast on the downstream signal.

This is the most consequential section of this guide for any manufacturer selling through industrial distribution, and it is rarely discussed.

Sell-in versus sell-through

Suppose end demand for a product is steady at 100 units a week. Your distributor holds four weeks of cover and orders monthly, so you see orders of roughly 400 units a month. Steady enough.

Now the distributor decides to raise cover to six weeks. In one month they order 400 units of consumption plus 200 units of additional stock: an order of 600. Your sales history records a 50% jump. Nothing changed in the market. If your forecast is built from your own orders, it now expects a higher run rate, drives replenishment and production accordingly, and you build inventory against demand that does not exist.

The following month, the distributor is fully stocked and orders 400 again — or less. Your forecast reads a collapse. This oscillation, manufactured entirely by inventory policy downstream, is the bullwhip effect, and it is why manufacturers selling through distribution routinely alternate between stock-outs and write-offs while insisting their forecasting tool is the problem.

The forecasting tool is not the problem. The input is.

Getting to the real signal

EDI 852 Product Activity Data is the document distributors use to report point-of-sale and on-hand inventory back to suppliers. It is the closest thing a manufacturer selling through distribution has to true end-market demand.

Practical realities:

• Large distributors generally provide it. The major industrial distributors have mature EDI programs and 852 is a standard part of them. Ask. Many suppliers never do.

• Frequency varies. Weekly is common, daily happens, monthly is close to useless for anything but trend.

• Coverage is never complete. You will get 852 from your largest partners and nothing from the long tail. That is fine — if your top ten distributors are most of your volume, you have most of the signal.

• Formats vary in practice. Nominally standard, actually not. Each partner needs mapping and validation.

• Some will send spreadsheets instead. Take them. A weekly Excel file from a partner who will not do EDI is still a demand signal.

Blending the signals without double counting

Do not simply add sell-through to sell-in. Model it properly:

1. Forecast end-market demand from 852 point-of-sale data for the partners who provide it.

2. Track distributor inventory position from the same feed.

3. Derive expected replenishment — the orders you should receive — from consumption plus the gap between their current and target cover.

4. Forecast the uncovered tail from your own sell-in history, which is all you have for those partners.

5. Reconcile the two into a single demand plan.

Executed properly this collapses the bullwhip, because you stop reacting to your distributors’ inventory decisions as though they were market movements. It also transforms the conversation you have with those distributors — you are discussing their sell-through and cover position rather than arguing about their order forecast.

That is a supply chain capability, not a software feature. It is also the strongest reason for a distribution-model manufacturer to treat demand planning and EDI as one program rather than two.

Four routes: build it with Azure Logic Apps and Service Bus over the F&O data entities, buy an embedded EDI ISV from Microsoft AppSource, use a managed EDI service that handles trading partner onboarding for you, or run a hybrid with an ISV for standard documents and Logic Apps for the awkward ones. The right choice depends on how many trading partners you have and how often that number changes.

The documents that matter

Most EDI projects scope 850, 855, 856 and 810 and stop. If you sell through distributors, 852 belongs in phase one, not on a wish list — see the previous section for why.

F&O-specific mechanics

Whichever route you take, the same questions decide whether it works in production:

• Data entities. F&O integration runs through data entities. Some standard entities do what you need; some need extension. Establish which during design, not during build.

• Batch versus near-real-time. Recurring integration jobs suit most EDI volumes. Real-time is possible and rarely necessary. Match the pattern to the business requirement, not to preference.

• Error handling. What happens to an inbound 850 that fails validation at two in the morning? Who is told, where does it queue, and how is it reprocessed without duplicating the order? Ask any prospective partner this question. The answer separates the ones who have done this from the ones who have read about it.

• Trading partner identifiers. Mapping partner item numbers, locations and price agreements to your own is grinding work and it is most of the onboarding effort.

• Volume and throttling. F&O has service protection limits. High-volume EDI needs designing around them rather than discovering them in production.

Logic Apps makes sense with a small, stable set of trading partners, existing Azure capability, and a willingness to own the maintenance. An EDI ISV or managed service wins once you onboard partners regularly, because trading partner onboarding — not the integration itself — is where the cost sits. Most mid-market manufacturers underestimate onboarding by a wide margin.

A decision rule you can apply today

• Under five trading partners, changing rarely, Azure skills in-house: build with Logic Apps. You will spend less and keep full control.

• Five to twenty partners, occasional additions: hybrid. An ISV for standard document flows, Logic Apps for the partners who do things their own way.

• Over twenty partners, or onboarding several a year: buy. Either an ISV or a managed service. The onboarding tooling and the trading partner library are what you are paying for, and they are worth it.

• No internal integration capability and no appetite to build it: managed service, regardless of partner count.

What people get wrong about the cost

The build is not the expensive part. Onboarding is. Each new trading partner brings a specification document, a mapping exercise, item and location cross-references, a testing cycle with their EDI team, and a certification process that runs on their schedule rather than yours. Two to four weeks per partner for the first few is normal, faster afterwards, and almost nobody budgets for it.

Model three years, not one. Include: initial build, per-partner onboarding at a realistic rate, ongoing maintenance and monitoring, the cost of changes when a partner alters their specification, and the internal time spent on exceptions. Logic Apps frequently wins year one and loses by year three once onboarding volume is honest.

Where Logic Apps genuinely shines

Even if you buy an EDI product, Azure Logic Apps and Service Bus usually still earn their place — orchestrating flows between F&O and other systems, transformation and enrichment, retry and dead-letter handling, and the non-EDI integrations sitting alongside. Treating it as an either/or is usually a false choice.

Your EDI feed is your demand signal. The 852 product activity documents your distributors send carry their point-of-sale and on-hand inventory — the closest available proxy for true end-market demand. Treating EDI purely as an order-processing pipe, rather than a forecasting input, is the most commonly missed opportunity in distribution-model manufacturing.

The architecture is not complicated:

Distributor 852 feed → Azure Logic Apps for transformation and validation → staged in Dynamics 365 F&O → consumed by Demand Planning as an additional demand stream, alongside sell-in order history.

What makes it work is design rather than technology:

• Map distributor item numbers to your items once, properly. Everything downstream depends on it.

• Store point-of-sale and on-hand as separate measures. They answer different questions.

• Keep sell-in and sell-through as distinct demand streams in Demand Planning so planners can see both and reconcile deliberately.

• Handle gaps explicitly. A partner who reports weekly and misses a week must not read as zero demand.

Build the EDI program with this in mind from the start. Retrofitting 852 into a demand planning solution designed around sell-in means revisiting your hierarchy, your measures and your forecast profiles — considerably more work than including it in the original design.

Harmonize before you forecast. Acquired businesses arrive with their own item masters, product hierarchies and history formats, and a forecast built on inconsistent categorization will be wrong in ways nobody can trace. Build one product hierarchy, map each legacy structure onto it, then use row-level security so each brand’s planners see only their own plan.

For acquisitive groups — and in industrial products, most groups of scale are acquisitive — this is the section that determines whether the project succeeds.

Design the product hierarchy first. It governs the level you forecast at, how you aggregate, what planners can see, and how new acquisitions are absorbed. Design it once, with every brand represented in the room, before configuration starts. Retrofitting a hierarchy after forecasting has begun means rebuilding history.

Map, do not merge. Each legacy categorization maps onto the group hierarchy while remaining traceable. Brand teams keep their own view; the group gets a consistent one.

Use row-level security deliberately. Premium’s row-level security is what makes a shared planning platform politically acceptable in a multi-brand group. Brand planners see their own numbers, group planners see the total. Without it, expect resistance dressed up as technical objections.

Sequence the rollout by suitability, not size. Onboard the brand with the cleanest data and the most engaged planning team first, not the largest. You are proving a model, and you want it proven.

Forecasting a brand you have just acquired, with no clean history in your system, is a distinct problem. Options in order of preference: map their history into your structure if the quality supports it; forecast from an analogue product family within the group; or run planner-driven forecasts for two or three cycles until enough history accumulates. Say which you are doing, and why, so nobody mistakes a judgement call for a statistical output.

Cross-border operations add three complications: demand patterns that diverge by country, product ranges that are not identical because certification standards differ, and a landed-cost picture that moves with tariffs and exchange rates. Forecast each country as a separate demand stream rather than a single North American number, then plan supply across both.

This matters to most Canadian manufacturers of any scale, and it is consistently under-modelled.

Forecast by country, not by continent. Canadian and US demand for the same product diverge on seasonality, construction cycles, regional weather and buying behaviour. A blended North American forecast averages away both patterns and is reliably wrong in both markets.

Range differences are real. Certification and standards requirements mean the product sold in Canada is often not identical to the product sold in the US, even where branding matches. If those are separate items in your system, forecast them separately. If they are the same item with different attributes, make sure your hierarchy can distinguish them.

Currency. Forecast in units, plan value in the currency each entity reports in, and be explicit about which exchange rate assumption sits behind any value-based plan. Volume forecasts should never be quietly contaminated by FX movement.

Trade policy is a planning input now. Tariff and trade-rule changes affect sourcing decisions, landed cost and — where they change customer buying behaviour — demand itself. Build the scenario capability to model a sourcing or cost change rather than treating trade policy as something that happens to you between planning cycles.

Inventory positioning across the border is a supply decision the demand plan feeds. Where you hold stock, in which country, against which forecast, has cost and service consequences that a single blended number cannot inform.

Demand Planning alone typically takes eight to sixteen weeks, most of it spent on data preparation rather than configuration. EDI runs in parallel and is paced by trading partner onboarding, at roughly two to four weeks per partner for the first few and faster afterwards. Running both alongside an in-flight Finance & Operations rollout adds sequencing constraints rather than, usually, extra elapsed time.

Should you add SCM Premium during an active F&O rollout?

Frequently asked, and the honest answer is: design it now, build it after core go-live, with one exception.

Design it now because your product hierarchy, item master structure and demand history strategy are being set during the F&O implementation. Decisions made without demand planning in mind are expensive to unwind afterwards, and the hierarchy is the worst of them to get wrong.

Build it after core go-live because Demand Planning needs demand history in a consistent format. During an active rollout that history is still moving, and a forecast built on data that changes under it will be discredited before anyone trusts it.

The exception is EDI. If EDI is on the critical path for customer orders, it belongs in the core rollout — you cannot ship if you cannot receive orders. Build the EDI foundation with the F&O program and add the 852 demand-signal flow when Demand Planning follows.

One expectation to set with the board early: forecast accuracy improvement takes at least one full planning cycle to demonstrate, and realistically two or three. Anyone promising measurable accuracy gains in month two has not run one of these.

Three components: the Premium licence uplift over standard for planner seats only, implementation services covering demand planning setup and data preparation, and the EDI build. Offset those against the retired tool’s subscription and the integration maintenance you stop paying for. For most mid-market manufacturers the licence delta is the smallest of the three numbers.

Illustrative ranges for scoping. Replace with a quoted figure before budgeting.

The comparison that matters

Run this with your own numbers, and include the incumbent’s renewal — vendors of standalone planning tools do not typically hold pricing flat for three years.

Be prepared for the answer to be “keep it”. If you run genuine multi-echelon optimization and use it well, consolidating is a downgrade dressed as a saving. Knowing that before you commit is worth more than the licence difference.

Five failure modes recur: demand history nobody cleansed, a product hierarchy designed after forecasting started, planners never given a reason to trust the model, EDI scoped by document type instead of by trading partner, and accuracy targets set before a baseline was measured.

Baseline before you start: forecast accuracy by category, inventory turns, stock-out rate, excess and obsolete stock value, and planner hours spent preparing data rather than planning. A realistic first-year target is meaningful improvement on your top-moving categories, not across the entire range.

Two notes on measurement.

Agree one definition of forecast accuracy before you start. Right now two people in your business almost certainly calculate it differently, at different aggregation levels and over different lags. Fix that first, or you will spend the review meeting arguing about arithmetic.

Measure improvement where it pays. A 5% accuracy gain on your top-moving 200 SKUs is worth vastly more than the same gain across a long tail of intermittent items — and the long tail may not be forecastable at all, which is a legitimate finding rather than a failure.

Look for three things that rarely sit together: Finance & Operations supply chain depth, real integration engineering on Azure rather than reselling an EDI product, and demand planning experience in a business with your route to market. Ask how many EDI trading partners they have onboarded, and ask to speak to the engineer who did it.

That last row and the accuracy question do most of the work. Any partner offering a confident forecast accuracy figure before seeing your data is guessing, and you should treat every other number they give you the same way.

Working with Dynamics Square

We are a Microsoft Solutions partner with offices in Thornhill and Vancouver, 150+ certified professionals, more than 14 years in the Dynamics ecosystem, and 350+ clients. We work across Finance & Operations, Supply Chain Management and the Azure integration services that hold them together — which matters here, because demand planning and EDI are usually sold by two different vendors and delivered as two disconnected projects.

A better first step than a demo. Send us two years of demand history and we will run a demand data readiness assessment: what your data can currently support, where the forecast quality ceiling sits, and what cleansing would move it. You will know whether this project is worth doing before you license anything.

Book a demand data readiness assessment

Frequently asked questions

Do I need SCM Premium for demand planning? 
Yes, for anyone creating or editing forecasts. Standard Supply Chain Management provides limited Demand Planning access — reading and creating worksheets — while Premium is required for full forecast creation and editing. You only need Premium for the people who actually plan.

What does Dynamics 365 SCM Premium cost in Canada? 
Microsoft lists Supply Chain Management at CAD $284.90 per user per month and Supply Chain Management Premium at CAD $407.00, both on annual commitment. Premium also includes 1,000 Copilot Credits per user per month. Pricing varies by agreement and region, so confirm current figures before budgeting.

What is the difference between Demand Planning and the old Demand Forecasting module? 
Demand Planning is a newer, separate application with a spreadsheet-style planning worksheet, forecast profiles, machine-learning models and collaboration features. The earlier Demand Forecasting capability in Finance & Operations was considerably more limited and widely bypassed in favour of third-party tools.

Can I mix standard and Premium licences? 
Yes, and you generally should. License planners who create and edit forecasts on Premium, and everyone else in Supply Chain Management on standard. Blanket-upgrading the whole estate is the most common way businesses talk themselves out of a project that would have been affordable.

How much sales history does Demand Planning need? 
Two to three years of consistent transactional history is a reasonable minimum. More matters less than consistency: history from several acquired systems in different formats will produce a worse forecast than a shorter, clean series.

Can it forecast at size and colour level? 
It can forecast at any level your product hierarchy supports, and you can forecast at a higher level and disaggregate. Purpose-built apparel and footwear planning tools offer more sophisticated attribute-based and size-curve capability out of the box, so test this specifically if your SKU count is driven by size and colour matrices.

Does D365 do multi-echelon inventory optimization? 
Not to the depth of specialist optimization engines. If you genuinely run and use multi-echelon optimization today, evaluate carefully before consolidating — a hybrid model, keeping the specialist and integrating it, is often the better answer.

How does EDI work with Dynamics 365 F&O? 
EDI integrates through F&O data entities. You can build it with Azure Logic Apps and Service Bus, buy an embedded EDI ISV from AppSource, or use a managed EDI service. The route to choose depends mainly on how many trading partners you have and how often you onboard new ones.

Do I need an EDI ISV, or can Azure Logic Apps handle it? 
Logic Apps handles EDI well for a small, stable set of trading partners where you have Azure skills in-house. Once you onboard partners regularly, an ISV or managed service usually costs less overall, because partner onboarding tooling — not the integration itself — is the expensive part.

What is an EDI 852 and why does it matter? 
The 852 is the Product Activity Data document distributors use to report point-of-sale and on-hand inventory back to suppliers. For a manufacturer selling through distribution it is the closest available signal to real end-market demand, and feeding it into Demand Planning is the single highest-value use of EDI beyond order processing.

How long does EDI trading partner onboarding take? 
Two to four weeks per partner for the first few, faster once your process is established. Onboarding is paced by the partner’s EDI team and certification process rather than by yours, which is why partner count drives EDI cost far more than document count does.

Can I add SCM Premium during an active F&O rollout? 
Design it during the rollout, build it after core go-live. Your product hierarchy and item master decisions are being made now and are expensive to unwind, but Demand Planning needs stable demand history that an in-flight rollout does not yet provide. EDI is the exception — if it is on the critical path for customer orders, it belongs in the core program.

What are Copilot Credits and will I need more? 
Copilot Credits are the metered capacity for running Copilot features and agents. Premium includes 1,000 per user per month; standard does not include any, though they can be purchased separately. Consumption depends on how heavily you use agents rather than on user count, so monitor for a quarter before committing to a volume.

How much will my forecast accuracy improve? 
Nobody can answer that before seeing your data and your current baseline. Improvement depends on your starting accuracy, your demand patterns, and how clean your history is. Treat any partner offering a confident percentage upfront with caution.