Margin history that survives the migration

Years of product and customer margin live in the costing-based profitability tables, and the new margin apps cannot see them. There is no conversion tool for the history. Unless something is built, the margin trend starts over at go-live.

RuleLand both histories in a warehouse you own, conform the dimensions, and union across an explicit seam date with a lineage column.

Neverpresent a trend that silently crosses the seam. Every row states which system it came from, or the chart is not evidence.

◆ The break, mechanicallytwo profitability designs, no bridge for the history.

Costing-based profitability analysis stores its history in its own tables, one set per operating concern, conventionally written CE1xxxx. Margin Analysis, the S/4HANA successor, records profitability inside the universal journal instead. The two designs value and time postings differently, and SAP provides no conversion tool that migrates the costing-based history into the new structure.

SAP’s own guidance is to keep costing-based running in parallel where historical analysis is needed. The delivered margin apps read only the universal journal, so they begin at the migration and know nothing older. The consequence lands a quarter later, when someone asks for the three-year margin trend by product and the answer stops at the go-live month.

◆ What breaks at the boundarythe questions that need both sides at once.

The question	At the boundary
Product margin trend, three years	Stops at go-live in the new apps; the older years sit in tables they cannot read.
Customer profitability, year over year	This year and last year come from different systems with different valuation logic.
Price and volume effects across go-live	Needs one conformed series. Two parallel systems each tell half the story.
Audit of a pre-migration margin number	Answered only in the legacy system, for as long as it stays alive and licensed.

◆ The owned answerone conformed series, one visible seam.

The build lands the legacy CE1xxxx history and the new margin rows in your warehouse through the extraction pattern, conforms products, customers, and value fields into shared dimensions, and unions the two across an explicit seam date. Every row carries a lineage column naming its source system. The trend runs unbroken, and the seam stays visible for anyone who asks how the series was made.

-- one margin series, seam explicit
SELECT fiscal_month, product, SUM(margin) AS margin, lineage
FROM fct_margin_conformed
WHERE fiscal_month BETWEEN '2023-01' AND '2026-06'
GROUP BY 1, 2, 4 ORDER BY 1

This is the same pattern this catalog documents for Workday on the pre-go-live history page: the vendor migrates the future, and the past is yours to carry. The general case has its own page, the system only knows now.

Use case

Problem

Costing-based profitability history cannot be migrated into Margin Analysis and the new apps read only the universal journal, so the margin trend breaks at go-live.

What we build

Both histories landed in your warehouse, dimensions conformed, unioned across an explicit seam date with a lineage column on every row.

What you get

Product and customer margin trends that run unbroken across the migration, with the seam documented instead of hidden.

Does your margin trend survive go-live?

We land both histories and union them across a seam you can point at.

Talk to us

Terms on this page

SAP: The vendor. Systems, Applications, and Products in data processing.
HANA: SAP’s in-memory database, the platform S/4 runs on.
ERP: Enterprise resource planning, the system of record for operations and finance.
costing-based profitability analysis: The classic profitability ledger with its own tables per operating concern.
Margin Analysis: The S/4 successor, recording profitability in the universal journal.
seam date: The explicit date where a conformed series switches source systems.
lineage column: A field naming the source system behind each row.
conformed dimension: One shared product or customer list both histories join to.