ERP World View · Doctrine

Cross-ERP Rosetta Stone

Every ERP's vocabulary, mapped to the one canonical model the engine folds into. Read a row across: the same business fact, named five ways, retained faithfully in one AD shape.

Provenance by source column: iDempiere ◆ canonical · Odoo ✅ folded (the O2C/P2P rows shipped in gen_ad_odoo.js, oracle-diffed) · SAP S/4 · Oracle EBS · Dynamics BC ○ reference (their standard table/term names are public and accurate; our fold of them is master-mapping only so far — see the honesty panel). A cell marked “—” means the concept has no direct named home in that product (often it is imperative code there, not a table).

1 · Tenancy, organisation & security

2 · Master data (the WHAT)

3 · Documents — Order to Cash (sell-side)

4 · Documents — Procure to Pay (buy-side)

5 · Accounting & posting (the books)

6 · Process, rules & workflow

7 · Cost of change — the elementary case

The Rosetta rows above show where a fact lives. This section shows what it costs to change one. Start with the most boring change in any ERP: a clerk keeps overwriting an auto-filled field, so the business says “lock the Sales Order Description field — make it read-only.” Read the two columns down.

Witnessed live: W-AD-SELFEDIT — a signed AD_Field edit re-folds the open form on the spot (field count 26→25→26), no reload, no recompile. The honest point: even iDempiere makes this change declarative — that is exactly why the engine borrows its dictionary rather than re-authoring it. The Fold Engine does not win on “is it config”; it wins on no server, no cache reset, and self-propagation by op-log.

Now the gradient. Cost stays near-zero while a change is declarative, and rises only when the logic is genuinely imperative — and even then it is bounded to a single plugin.

§7 in numbers — one real change, counted. Not a stopwatch (noisy) and not the whole-codebase LOC ratio — the effort surface of one identical change done both ways: “block completing a Sales Order when it would breach a custom CreditCeiling on the customer” (a real customisation that genuinely needs a Java ModelValidator on the iDempiere side, not config).

* Lines is a forecast estimate (each line enumerated in the witness card), pending an actual wc -l on a built artifact each side. The other three axes — checks, DB artifacts, build/restart — are structural facts, exact: they are fixed by OSGi (which forces a build→resolve→restart loop and a per-instance migration) versus the fold (which forces neither). The decisive saving is the bottom two rows: build+restart 2 → 0, and a per-instance migration ×N collapsing to one signed op-log append.

8 · The cost equation — what actually scales

A common first reading is that this architecture just moves cost: you save on UI and DB binding, then pay it back managing a cryptographic op-log. That is the wrong equation — it confuses a one-time substrate with a recurring tax. The honest accounting:

Sources: maintenance share of TCO — ScienceSoft · Galorath (IEEE 60–80%); ERP vendor support % of license — Panorama Consulting (18–25%) · Panorama — Cloud ERP Cost; build-once vs maintain-forever — Idealink. Peer-reviewed primary sources: Lientz & Swanson, CACM (1978) — the foundational 487-organisation survey · Glass, Facts and Fallacies of Software Engineering (2002) — the canonical 40–80% of lifecycle cost range · Erlikh, IEEE IT Professional 2(3):17–23 (2000) — legacy upkeep ≈80% of TCO; categories standardised in ISO/IEC 14764. Not a universal law: the range is wide by design — long-lived, regulated, heavily-customised systems (ERP is the textbook case) sit high (70–90%); short-lived or throwaway software sits low (20–40%). So this is strongest exactly where ERP lives, not a claim about all software. Figures are third-party research; our contribution is only the architecture that moves the saving onto that bucket.

9 · For the iDempiere OSGi plugin maintainer

If you have shipped ModelValidators, Callouts and custom Doc_* posting as OSGi bundles, most of what you maintain is not business logic — it is OSGi plumbing and upgrade-breakage. That is exactly the recurring cost the table below removes. Read it idiom for idiom: the OSGi tax disappears; the business logic does not.

10 · Measured — both sides counted, on disk and in code

The sections above argue the shape of the cost. This one is just a tape measure. Every figure below is a real du/wc/sqlite count of iDempiere itself against this engine — same demo tenant (GardenWorld), measured 2026-06-06 / -12, no estimates in the left three columns.

Source: real measurement, not estimate — internal/BLOAT_MEASUREMENT.md (live docker Postgres → migrate_pg_to_sqlite.js, 2026-06-06) + LOC re-counted 2026-06-12; the model-layer denominator is docs/ERP_MODEL_ARCHETYPE.md (the MOrder archetype + ~25 completeIt deltas). Full coverage accounting: Coverage Matrix.

Companions: Benchmark Comparison — the engine vs iDempiere live in-browser; both sides measured from real source (51× LOC, 26× by size), re-counted each deploy · Fold Engine Black Book — the deep dev manual (op-log programming, how to extend the engine) · ERP Rosetta Stone (iDempiere-Java → Fold Engine) — the developer idiom map · ACDOCA Fold Plan — the SAP headline (the Universal-Journal fold) · Coverage Matrix — which surfaces are proven equivalent · Migrate & Compare — the thesis & honesty panel.  ·  Reference table/term names are public product documentation; their fold into the canonical column is proven only for iDempiere (◆) and Odoo (✅) today — SAP/Oracle/Dynamics (○) are the campaign ahead.