Solutions For Blue Yonder

Blue Yonder, loaded on the calendar — and read back for execution.

Blue Yonder forecasts on demand forecasting units — an item at a location for a demand stream — and plans supply on SKUs shared by its demand, fulfilment and S&OP engines. Lima Backbone builds those units and keys from SAP and Oracle with a rule you own, loads history, supply and calendars on the planning cycle with counts proved, returns approved plans to the ERP as acknowledged transactions, and reads Blue Yonder warehouse and transport events live so plan and reality sit side by side.

Run your first load into Blue Yonder Planning integration overview

First load: one dataset, four weeks, fixed price.

Blue Yonder's model: items and locations make SKUs; a SKU plus a demand stream makes a DFU; sourcing, history, supply and calendars surround them, and execution events are read where they sit.

1 rule

defines every demand forecasting unit — owned, versioned, applied to the whole history

47,900

DFUs built from 18,400 SKUs and three demand streams on the showcase estate

0 gaps

every DFU history zero-filled over the planning calendar, so an empty week reads as zero demand

Step 1 · What Blue Yonder expects

SKUs, demand forecasting units, and the keys every engine shares

Blue Yonder's engines each hold a model, and they meet on shared keys: the SKU (an item at a location) and, for forecasting, the DFU (a SKU for one demand stream). Building those keys the same way for every engine, from ERPs that never heard of a DFU, is the core of the integration.

Object	What it holds, in plain words	Why the plan needs it	SAP source	Oracle source
Item · Location	Products with attributes and units; plants, distribution centres and stores	The two halves of every key	MARA · MARM · T001W	MTL_SYSTEM_ITEMS_B · inventory organizations
SKU	One item at one location with lot size, safety stock, lead time	The unit supply planning works on, shared by every engine	MARC	Item-organization assignment
DFU	A SKU for one demand stream, such as a channel or customer group, with the attributes forecasting branches on	The unit a forecast is built and measured on	Derived: MARC × KNVV customer group or sales channel	Derived: item-org × customer class
History streams	Shipments, orders, point-of-sale, per DFU per bucket, zero-filled	What the forecast learns from	LIPS · VBAP · VBRP · POS feeds	WSH_DELIVERY_DETAILS · OE lines
Sourcing and lead times	Make, buy or transfer per SKU with lead times and lanes	How supply reaches each SKU	MARC · EINE · EORD · MKAL	Sourcing rules · approved supplier list
Supply orders and stock	Open purchase, planned and production orders; on-hand by status	The supply side of the balance	EKPO · PLAF · AFPO · MARD · MCHB	PO lines · WIP jobs · MTL_ONHAND
Resources and calendars	Capacity, working days, planning buckets	Feasibility and the bucket structure	CRHD · KAKO · TFACS	BOM_RESOURCES · BOM_CALENDARS
Execution events	Warehouse receipts and shipments, transport loads and arrivals	Plan versus what happened, for the control tower	Blue Yonder WMS · TMS (read live)	Blue Yonder WMS · TMS (read live)

Blue Yonder loads planning data through its platform's data model interfaces (files and APIs); Lima produces those loads and reads execution data in place through the fabric.

Step 2 · Where ERP integrations go wrong for Blue Yonder

Six places the data breaks, and what it does to the plan

Most of these come from one fact: Blue Yonder's keys are planning concepts, and ERPs store transactions.

The DFU is a design decision hidden in three tables history split or merged wronglyA demand forecasting unit is an item at a location for a stream — a channel, a customer group, a market. The item is in the material master, the location in the plant record, and the stream in a customer attribute or a sales-organisation field on the order. Choose the wrong field, and history splits into units too small to forecast, or merges channels that behave differently.

History must be one stream with a rule, and it must have no gaps gaps read as unknownShipments, orders or invoices; returns in or out; intercompany included or excluded — the choice has to be made once and applied to every week of history. Blue Yonder's forecasting reads an empty week as missing data, so weeks with no demand have to be zero-filled or the forecast treats them as unknown.

Several engines, one set of keys plans stop reconcilingDemand, fulfilment and S&OP each hold their own model. If the SKU key or the calendar differs between them — a location coded differently, a week starting on a different day — the demand plan and the supply plan stop reconciling and the S&OP meeting argues about data.

Buckets and calendars the wrong weekBlue Yonder plans in buckets on a planning calendar with its own week-start rule and fiscal periods. ERP data is daily and per document; mapping it needs the same calendar every engine uses, including the 53-week years.

Sourcing lives in three ERP places supply from the wrong placeMake in production versions, buy in info records and source lists, transfer in special procurement keys and stock transport orders. Each SKU needs one clear sourcing record with a lead time, or fulfilment plans supply from the wrong place.

Plan and reality live in different products a second integrationThe plan sits in the planning engines; what happened sits in the warehouse and transport systems. Retail and consumer-goods estates need on-time-in-full, dock-to-stock and carrier performance beside the plan, and that is a second integration in most projects.

Industry flavour: retail, consumer goods, manufacturing, logistics

Retail estates bring stores as locations, point-of-sale history and promotions that must map onto DFUs by channel. Consumer goods bring customer-group streams and promotional uplift. Manufacturing brings production versions and routings behind the SKU sourcing. Logistics-heavy estates bring warehouse and transport events that the control tower reads live. Each has a check in Step 4.

Step 3 · How Lima Backbone handles each one

Each problem has a specific answer, and each answer is something you can see

The figure shows the DFU rule at work on one material. The table maps all six problems.

Problem	What Lima does	The capability behind it	What you see
1 · DFU definition	Holds the DFU rule — which item, location and stream fields combine — as a governed rule with an owner and a version, and builds every DFU from it; lines that fail to resolve are held	Governed planning master data; rules in plain language	The DFU register with counts per stream and the rule text beside it
2 · One history stream, no gaps	Applies the demand-stream rule to the whole history and zero-fills every bucket the calendar defines; the result is checked against the source totals per week	Demand-stream rule; calendar-driven zero-fill; sum checks	Weeks per DFU, weeks zero-filled, totals reconciled
3 · Shared keys	Builds SKU and location keys once and feeds every engine from the same tables, so demand, fulfilment and S&OP receive identical keys and calendars	One conformed key master feeding several targets	Per-engine load reports with the same key counts
4 · Buckets	Rolls daily rows into buckets using the Blue Yonder planning calendar you configure, including week-start and 53-week rules	Grain builder with a configurable calendar	Bucket totals against daily totals
5 · Sourcing	Resolves production versions, info records, source lists and special procurement into one sourcing record per SKU with its lead time	Model-aware transformation operators for SAP and Oracle	Sourcing by type per SKU with the ERP record behind it
6 · Plan and reality	Reads warehouse and transport events in place through the fabric and joins them to the plan for OTIF, dock-to-stock and carrier views	Zero-copy fabric; control-tower KPI library	Plan-versus-actual with exceptions routed to owners

Step 4 · The checks that run before anything loads

Nine checks a Blue Yonder load runs every cycle

Every check is a rule with an owner. A failed row is held with the rule and the row; the load continues with the rest and the report says what was held. Examples from the showcase estate:

Check	Kind	Example	When it fails
Every history line maps to exactly one DFU	Completeness	3,204 lines with no customer group on the sold-to	Held; exception to the customer master owner
Every DFU has a complete, zero-filled history over the calendar	Completeness	DFU with 147 of 156 weeks present	Nine weeks zero-filled and reported
Orders ≥ shipments per DFU per week; returns handled per the rule	Consistency	A week with shipments and no orders	Exception to the demand planner
SKU keys identical across demand, fulfilment and S&OP loads	Consistency	Location 1000 vs L1000 in two engines	Load stays open until keys match
Buckets follow the planning calendar; 53-week years handled	Consistency	Fiscal 2026 has 53 weeks	Exception to the calendar owner
Every SKU has one sourcing record with a positive lead time	Completeness	412 SKUs with two make sources and no priority	Exception to the sourcing owner
Units consistent between history and supply	Quality	History in cases, stock in each	Exception to the item owner
Stock by status sums to plant stock	Consistency	Blocked stock counted as available	Exception with both figures
Record counts and control totals per table match the source	Completeness	Every table, every load	Load report stays open until they match

Kinds: completeness (is everything there), consistency (do related numbers agree), quality (is each value valid).

Step 5 · Watching the data flow, correcting it on the way

One screen from the ERP table to the planning object

Integration suites such as Informatica sell data integration, data quality, the catalog and lineage as separate services on one consumption meter, and a team stitches the four together for each load. Lima runs the four as one surface. The screen above is the same for every load into Blue Yonder: each step from the SAP or Oracle delivery table to the Blue Yonder DFU bucket shows its row count; the rule that stopped a row shows the row and the person who owns the fix; the fix is applied where the row stopped and the replay starts from that step. Column-level lineage is recorded from the run itself, so the trace from a number in Blue Yonder back to the ERP table is current every morning without a scanning project.

Rules in plain language

Checks a planner can read

A rule such as "confirmed date is on or after order date" is written in words, previewed on live rows, versioned, and owned by a named person.

Exceptions with owners

Nothing disappears

A row that fails a rule becomes an exception with the row, the rule, an owner and a deadline. The load carries on with the valid rows and says what it held.

Lineage from the run

Always current

Every step records what it read and wrote at column level, so the trace from a planning number back to the ERP field is captured as a by-product of running.

Governed planning master data

Parameters with owners

Values the ERP never held — hierarchies, changeover matrices, demand-stream rules — live in Lima with an owner and an effective date.

Acknowledged write-back

The loop closes

Results return to the ERP as transactions the ERP confirms; the confirmation is stored and reconciled against what was sent.

Deadlines on the pipeline

The planning run waits for nothing

Each load carries its window and deadline; a tripped rule pauses the run and the clock, and the run resumes from its checkpoint after the fix.

Step 6 · Load, reconcile, return

On the planning cycle, reconciled, and back to the ERP

Blue Yonder is loaded on its cycle; every load ends with a reconciliation report; approved plans return to the ERP as transactions the ERP confirms, and execution events are read live where they sit.

Weekly demand cycle

DFU history, attributes and calendar loaded before the demand review, with zero-fill and the sum checks.

Nightly supply net-change

Stock, open orders, sourcing changes as net-change into the fulfilment engine, in dependency order.

Execution, live

Warehouse and transport events read in place by the fabric for the control tower; nothing copied unless a copy has a purpose.

What goes back to the ERP

Result	SAP transaction	Oracle interface	How it is confirmed
Approved supply plan	`BAPI_PLANNEDORDER_CREATE` · `BAPI_PR_CREATE`	WIP job interface · `PO_REQUISITIONS_INTERFACE_ALL`	Order numbers stored; failures re-queued with reason
Forecast to the ERP	Planned independent requirements: `BAPI_REQUIREMENTS_CREATE`	`MRP_FORECAST_INTERFACE`	Counts acknowledged and reconciled per product-plant
Replenishment and allocation decisions	`BAPI_SALESORDER_CHANGE` · stock transport orders via `BAPI_PO_CREATE1`	Order import · internal requisitions	Acknowledged and reconciled; visible on the next extraction
Approved master-data corrections	`BAPI_MATERIAL_SAVEDATA`	Item interface	Second-person approval in Lima, then the acknowledged write

Standard released interfaces; the exact objects are confirmed per scope during the assessment.

A first load, step by step

Twenty-two days on the showcase estate

How a first load into Blue Yonder runs for a consumer-goods estate with three channels. Figures are from the showcase estate.

Day 1
connect

ERP and execution systems connectedSAP ECC and Oracle EBS connected on open interfaces; Blue Yonder warehouse and transport systems registered as live sources for the fabric; the demand dataset scoped.

Day 3
the rule

The DFU written downItem, location and customer group: the rule is written in words, given an owner, and run against the history. 18,400 SKUs and three streams become 47,900 DFUs; 3,204 history lines have no customer group and are held.

Day 6
history

One stream, zero-filledShipments count, returns are excluded; 156 weeks per DFU, 7.5 million buckets, 2.1 million of them zero-filled; weekly totals match the delivery table for every plant.

Day 9
keys

Every engine gets the same keysSKU and location keys built once and loaded into the demand, fulfilment and S&OP engines; the key counts match across all three.

Day 13
first load

ReconciledThe first full load lands with the reconciliation report; 412 SKUs with ambiguous sourcing are resolved by the sourcing owner before the fulfilment load.

Day 18
control tower

Plan beside realityWarehouse shipments read live from Blue Yonder WMS are joined to the plan; on-time-in-full by customer group appears in the control tower with exceptions routed to owners.

Day 22
hand-over

LiveThe DFU register, the reconciliation report and the exception register are handed to the planning COE; the weekly cycle runs on its own.

Partner and certification status

Stated as it is

Program	What it gives you	Status
Blue Yonder partner network	A recognised integration path and a badge for planning COEs	Application planned · 2027
Systems integrator delivery	Delivery by your SI or ours on the same fixed-scope offer	Available

Statuses are stated as they are and dated when they change. Badges appear only after they are granted.

Lifecycle

A Blue Yonder integration uses every stage, Return included.

STEP 1

ConnectSAP, Oracle, WMS, files, lakehouses

STEP 2

Extracttable reads, BAPIs, CDS views, CDC

STEP 3

Transformat MRP volume, 150+ operators, Python

STEP 4

Loadon the run window, counts proved

STEP 5

Orchestratedeadlines, pause and resume, replay

STEP 6

Returnwrite-back, acknowledged

One engine underneath every page in this family. It reads from any source and writes to any target, runs batch loads or change-data streams, handles a nightly delta or a multi-terabyte migration, and is licensed by capacity, so the bill stays the same however many rows move. Lima's fabric answers questions on data in place; Lima Backbone moves, transforms and returns data on a deadline. When to federate and when to pipeline · The Backbone hub.

Terms on this page

Plain definitions

SKUOne item at one location — the unit supply planning works on.

DFUDemand forecasting unit: a SKU for one demand stream, such as a channel or customer group.

Demand streamThe rule that says which ERP documents count as actual demand and how returns and intercompany are treated.

Zero-fillWriting an explicit zero for every calendar bucket with no demand, so the forecast reads it as zero demand.

BucketOne period on the planning calendar — a week or a month.

Execution eventsWarehouse receipts and shipments, transport loads and arrivals — what happened, as opposed to what was planned.

Control totalA sum computed on the source and the target and compared, alongside record counts.

Acknowledged writeA transaction the ERP has confirmed, with the confirmation stored and reconciled against what was sent.

Questions we hear

Asked before the first load.

Blue Yonder has integration tooling of its own. Why Lima?

Lima produces and proves the loads — the DFU rule, the demand stream, the zero-fill, the shared keys, the reconciliation and the cycle schedule — and reads execution events live for the control tower, which is usually a separate project.

Who decides what a DFU is?

You do, once, in a rule Lima keeps with an owner and a version. Changing it is a versioned change with an effective date, and the history is rebuilt from the rule.

Do execution events get copied into Lima?

Only when a copy has a purpose, such as a reporting database. For the control tower the fabric reads them where they sit.

Which Blue Yonder products are covered?

Planning loads into the demand, fulfilment and S&OP engines; live reads from the warehouse and transport systems. The First Load engagement scopes the exact products and objects.

How does the write-back reach the ERP?

Approved plans post through released BAPIs and Oracle open interfaces with a unique write reference so a retry never posts twice; the ERP's acknowledgement is stored and reconciled.

Can we start with one channel?

Yes. One channel or one region is a common first dataset; the DFU rule extends to the rest.