Solutions For o9

o9, loaded with hierarchies that hold.

o9 plans on a graph: products, locations, customers and time, each with a hierarchy, and numbers stored at a grain such as item by location by customer by week. Lima Backbone builds those hierarchies from SAP and Oracle, checks them for gaps and duplicates before every load, delivers actuals, supply and attributes at the right grain on the planning cycle, and returns the approved plan and forecast to the ERP as acknowledged transactions.

Run your first load into o9 Planning integration overview

First load: one dataset, four weeks, fixed price. o9 technical partnership application planned for Q1 2027.

o9's graph: dimensions with hierarchies feed measures at a grain; supply relationships and attributes complete the model. Each box names the SAP and Oracle tables Lima reads to fill it.

1 parent

per member per level — the rule every hierarchy is checked against before it loads

2,140

SKUs found without a family on the showcase estate's first extraction, held with their actuals until owners fixed them

Weekly = daily

every measure at a grain is checked against the daily rows it was built from

Step 1 · What o9 expects

A graph of members, hierarchies and numbers at a grain

o9 stores a number against members of several dimensions at once. For a number to land, every member it references must exist, sit in a valid hierarchy, and match the grain the measure is defined at. That is what makes hierarchy quality the decisive factor for an o9 load.

Object	What it holds, in plain words	Why the plan needs it	SAP source	Oracle source
Item dimension	Every product with its levels: SKU, family, category, business unit	Every product number rolls up along it	MARA · T179 (product hierarchy) · T023 (material groups)	MTL_SYSTEM_ITEMS_B · MTL_ITEM_CATEGORIES
Location dimension	Every site with its region and country	Where demand happens and supply is held	T001W · plant attributes	Inventory organizations
Customer dimension	Ship-to and sold-to customers with their channel	Forecasting by customer and channel	KNA1 · KNVV · KNVP (partner functions)	HZ_PARTIES · HZ_CUST_ACCOUNTS · sites
Time dimension	Days rolling into fiscal weeks, months and quarters	Every measure lives in a time bucket	T009 / T009B fiscal year variants	GL_PERIODS
Measures at a grain	Actuals, forecast, open orders, stock, capacity, each defined at a combination of levels	The numbers the plan is built from	VBRP · LIPS · VBAP · MARD · KAKO	OE lines · WSH deliveries · MTL_ONHAND
Supply relationships	Item-location nodes linked by bills of material, lanes and resources with lead times	The supply model behind the plan	STPO · MKAL · EORD · PLPO · CRHD	BOM tables · sourcing rules · resources
Attributes	Lifecycle status, ABC class, planner code, unit, new-product flag	Planning rules branch on them	MARA-MSTAE · MARC-MAABC · MARC-DISPO	Item attributes and flexfields
Version	The current working view and named scenarios	Keeps a scenario from overwriting the plan	Tagged by Lima on load	Tagged by Lima on load

o9 ingests members and measures through files and its API into a named version; Lima loads members and hierarchies first and measures at their grain second.

Step 2 · Where ERP integrations go wrong for o9

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

These problems are specific to a graph-based target: they are about membership, hierarchy and grain more than about volume.

A number with a missing member lands nowhere a customer's demand goes missingo9 stores a measure against existing members. A sales row for a customer that was never loaded as a member, or a SKU that exists in Oracle but was never conformed to the SAP code, has no place in the graph. Depending on the loader it is rejected or parked under an unknown member, and the forecast for that customer is simply missing.

Hierarchies must be strict: one parent per level roll-ups stop matchingSAP lets a material carry a product hierarchy, a material group and a planning hierarchy that disagree, and Oracle categories use different codes for the same family. A member with no parent (orphan), two parents, or two codes for one family breaks roll-ups, and the plan at family level stops matching the plan at SKU level.

Grain alignment double counted or lostERP transactions are daily and per document; an o9 measure lives at a grain such as week. Rolling up needs the fiscal calendar, the measure's unit and its aggregation rule. Loaded at the wrong grain, a number is double counted or lost in aggregation, and the error is invisible at the top level.

Attributes silently steer the plan wrong rule, silentlyLifecycle status, ABC class, planner and new-product flags decide which planning rules apply. When an attribute is missing, o9 applies a default, and a new product is planned like a mature one without anyone noticing.

Several ERPs, one graph one customer, split in twoThe same customer is TESCO-UK in SAP and Tesco Ltd in Oracle; the same family has two codes. Unless they resolve to one member before the load, the graph holds two customers and splits the history between them.

Actuals need a definition two forecastsShipments, orders or invoices; returns in or out; intercompany included or excluded. Two teams loading "actuals" with two definitions produce two forecasts. The definition has to be a rule with an owner, applied the same way to the whole history.

Industry flavour: consumer goods, retail, automotive and industrial, high-tech

Consumer goods and retail estates bring channel and customer hierarchies, promotions and point-of-sale history that must be conformed to the ERP's customers. Automotive and industrial estates bring long tails of parts with sparse history where attributes decide the forecasting method. High-tech brings product transitions where lifecycle status and successor links must be present on day one. 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 hierarchy check on a product tree fed by two ERPs. The table maps all six problems.

Problem	What Lima does	The capability behind it	What you see
1 · Missing members	Loads members before measures and checks every measure row against the member lists; rows for unknown members are held and listed for the owner, and a member can be created from the transaction with the owner's approval	Pre-load referential rules; owner review queue	An "unknown members" list with counts, resolved before the load
2 · Hierarchy integrity	Validates every hierarchy: one parent per member per level, no orphans, no cycles, no duplicate codes across ERPs; hierarchies are versioned with an effective date	Hierarchy validation rules; consolidation; versioning	A hierarchy report per dimension: members per level, orphans, duplicates, changes since last load
3 · Grain	Builds each measure at its defined grain from the daily rows using the fiscal calendar, then checks that the sum at the grain equals the sum of the rows it came from	Grain builder; sum-of-parts checks	A per-measure reconciliation: daily total, weekly total, difference
4 · Attributes	Requires the attributes each planning rule depends on, with defaults declared as rules and applied visibly	Attribute completeness rules with declared defaults	Attribute coverage per dimension and the rows that received a default
5 · Several ERPs	Resolves customers, items and families across ERPs into one member before the load, with the mapping versioned and owned	Consolidation with name resolution and similarity scoring	One member with its source codes listed underneath
6 · Actuals definition	Holds the demand-stream rule as a governed, versioned rule (which documents count, how returns and intercompany are treated) and applies it to the whole history	Rules in plain language with an owner and history	The rule text beside the actuals measure, with its version

Step 4 · The checks that run before anything loads

Nine checks an o9 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 measure row references existing Item, Location, Customer and Time members	Completeness	48 customers in sales history unknown to the Customer dimension	Rows held; members proposed for the owner
Every member has exactly one parent at each level	Consistency	2,140 SKUs without a family; 3 SKUs with two families	Exception to the product-data owner
No duplicate codes for one member across ERPs	Consistency	FAM-12 (SAP) and FAM12 (Oracle) for the same family	Consolidated; owner confirms
Sum at the grain equals the sum of the source rows	Consistency	Weekly actuals for Item × Location × Customer vs daily VBRP rows	Load stays open until they match
Time buckets follow the fiscal calendar; no partial or missing weeks	Completeness	Week 53 handling at fiscal year end	Exception to the planning calendar owner
Required attributes present: lifecycle status, ABC, planner, unit	Completeness	612 new SKUs with no lifecycle status	Default applied and reported; owner notified
Units are consistent within a measure	Quality	Actuals in cases for one plant, each for another	Exception to the item owner
The demand-stream rule applied to the whole history	Consistency	Returns excluded in 2025, included in 2024	Rule re-applied; version noted
Record counts and control totals per measure match the source	Completeness	Every measure, 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 o9: each step from the SAP or Oracle invoice table to the o9 measure row 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 o9 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

o9 is loaded on its planning cycle; every load ends with a reconciliation report; the consensus forecast and the approved supply plan return to the ERP as transactions the ERP confirms.

Weekly demand cycle

Actuals, attributes and hierarchy changes loaded before the demand review, with the sum checks and the hierarchy report.

Nightly supply net-change

Stock, open orders and supply relationships as changes since the last load, in dependency order.

Monthly S&OP

Scenario versions loaded and tagged; the current working view is never overwritten by a scenario.

What goes back to the ERP

Result	SAP transaction	Oracle interface	How it is confirmed
Consensus forecast	Planned independent requirements: `BAPI_REQUIREMENTS_CREATE` / `_CHANGE`	`MRP_FORECAST_INTERFACE`	PIR version and counts acknowledged and reconciled per product-plant
Approved supply plan	`BAPI_PLANNEDORDER_CREATE` · `BAPI_PR_CREATE`	WIP job interface · `PO_REQUISITIONS_INTERFACE_ALL`	Order numbers stored; failures re-queued with reason
Allocation decisions	`BAPI_SALESORDER_CHANGE`	Order import (`OE_HEADERS_IFACE_ALL`)	Acknowledged and reconciled; visible on the next extraction
Approved attribute 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 o9 runs when two ERPs feed one graph. Figures are from the showcase estate.

Day 1
connect

Two ERPs, one graphSAP ECC (Europe) and Oracle EBS (North America) connected; the demand dataset scoped: Item, Location, Customer, Time dimensions and the Actuals measure at Item × Location × Customer × Week.

Day 4
hierarchies

The product tree from two systemsSAP's product hierarchy and Oracle's categories are consolidated: 37 families with two codes resolved to one member each; 2,140 SKUs found without a family; 3 with two. Each becomes an exception for the product-data owner.

Day 7
customers

One customer, two names6,800 customer records across the two ERPs resolve to 4,120 members; 48 customers in sales history had no master record at all — proposed as members and approved by the steward.

Day 10
actuals

The demand-stream rule written downShipments count, returns are excluded, intercompany is out: the rule is written in words, versioned, and applied to 156 weeks of history; weekly sums match daily sums for every SKU.

Day 13
first load

Members first, measures secondDimensions and hierarchies load; then 1.2 million actuals rows at their grain into the current version; the reconciliation report matches counts and totals.

Day 19
write-back

The forecast returnsThe consensus forecast posts to SAP as planned independent requirements for 18,400 product-plants and to Oracle through the forecast interface; every post acknowledged.

Day 22
hand-over

LiveThe hierarchy report, 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
o9 technical partnership	A recognised integration path and a badge for planning COEs	Application planned · Q1 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 o9 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

DimensionA list of members with a hierarchy — products, locations, customers, time — that numbers are stored against.

GrainThe combination of dimension levels a measure is stored at, such as item by location by customer by week.

MemberOne entry in a dimension: one SKU, one site, one customer.

OrphanA member with no parent at the next level up; it breaks roll-ups.

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

VersionA named copy of the plan; scenarios are versions, and the current working view is the one planners use.

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.

o9 has its own data-ingestion layer. What does Lima add?

Lima produces what o9 ingests: conformed members, validated hierarchies, measures at their grain, and the reconciliation that proves them, on the cycle schedule. o9 keeps its graph, its planning logic and its scenarios.

What happens to a sales row for a customer o9 has never seen?

The row is held with the others for that customer, the customer is proposed as a member with the details from the ERP, and the steward approves or maps it. The load carries on with the rest and reports what it held.

Can the product hierarchy change mid-cycle?

A change is versioned with an effective date. The cycle in flight keeps the tree it started with; the next cycle gets the new one, and the change is traceable to a person and a date.

How is the forecast returned to SAP?

As planned independent requirements through the released BAPI, per product and plant, with the version noted; SAP's acknowledgement is stored and reconciled. Oracle receives it through the forecast interface.

How current is the data between cycles?

Supply runs nightly as net-change; demand refreshes on the cycle; the dashboard shows lag and window margin for each.

Can we start with one business unit?

Yes. One business unit or one region is a common first dataset; the hierarchy and member work extends from there.