Plans accepted in a planning application, purchase requisitions, allocations and corrected master data are written back into the ERP through its released transactions. Each write carries a unique key, so a retry cannot create a duplicate. The ERP’s confirmation is captured, and every run is reconciled with record counts and control totals.
Results that belong in the ERP are sent back through the transactions the ERP releases, and the ERP confirms each one.
Write-back is the sixth step of a Backbone job. In the first five steps, data is read from your ERP, changed into the shape a target needs, loaded into a planning application or a data lake, run on a schedule and checked. An ERP is the system that holds orders, stock, materials and finance.
Some of the results produced on that data belong back in the ERP: a plan a planner has accepted, a purchase requisition, an allocation, or a master-data record a steward has corrected. Write-back sends those results into the ERP through the transactions the ERP releases for other software to use. On SAP these are BAPIs and IDocs. On Oracle they are open interface tables, public APIs and, on Oracle Cloud, REST APIs. Each is explained below.
The ERP has to confirm each write. An ERP applies its own checks to every transaction, such as whether the plant is open for planning or the material is locked, and then returns a document number or an error. Backbone captures that answer on the ledger line for the write. A confirmed write is complete. A rejected write is re-queued with the ERP’s reason and retried once the cause is fixed.
Every write carries a unique key, generated before the write is sent. A retry carries the same key, so the ERP cannot create a duplicate.
The ERP’s answer, a document number or an error, is captured on the ledger line. A write counts as done when the ERP has confirmed it.
A rejected write goes back into the queue with the ERP’s reason, under the same key. The retry updates the same ledger line.
At the end of the run, records sent, confirmed and re-queued are counted, control totals per object are compared, and a named person signs off.
Six steps take a result from the moment it is accepted to a confirmed, reconciled line in the ledger.
The six steps are the same for SAP and for Oracle. What differs is step 3, the transaction that is posted, and step 4, the form the confirmation takes. The next section sets the two ERPs side by side.
Every step writes to the ledger. The ledger has one line per write, and that line is created at step 2, before anything is sent, so a write that fails on the way still has a line with its key and its reason.
The technical user is the dedicated login Backbone uses in the ERP. For write-back it holds the authorisations for the objects in scope and no others. Your Basis or database team grants them, in the same way as for extraction. How the ERP is read →
The path into each ERP differs. The key, the confirmation, the re-queue and the reconciliation are the same.
Your ERP publishes a set of transactions for other software to post records through. Backbone uses those transactions and captures the answer. The table sets SAP and Oracle side by side on the five points that differ: the transaction type, an example, how the ERP confirms, what the technical user needs, and the retry rule.
| Item | SAP ECC and S/4HANA | Oracle E-Business Suite, Oracle ERP and Oracle Cloud |
|---|---|---|
| Transaction type | Released BAPIs and IDocs. A BAPI is a function SAP publishes for writing one business object; an IDoc is an SAP document format for exchanging business records. | E-Business Suite and Oracle ERP: open interface tables and public APIs. Oracle Cloud: REST APIs. An open interface table is a table Oracle provides for other software to load records into, which Oracle then validates and posts. |
| Example | BAPI_PLANNEDORDER_CREATE for a planned order accepted in Kinaxis Maestro. | A country-code standardisation written back to Oracle ERP on the showcase estate. |
| How the ERP confirms | The return structure of the BAPI, or the IDoc status, with the document number SAP created or the error it raised. | The status and error columns of the interface table after the concurrent program runs, or the response of the public or REST API. |
| What the technical user needs | Authorisations for the BAPIs and IDoc types in scope. | Insert rights on the interface tables in scope, and the API roles in scope. |
| The retry rule | A retry carries the same key, so SAP sees one write and the ledger shows one line. | A retry carries the same key, so Oracle sees one write and the ledger shows one line. |
Transaction names on this page are limited to the ones confirmed so far. Other objects use the released BAPI for the object on SAP and the interface table or public API for the object on Oracle. The exact list per planning target is confirmed during the first load.
Plans, requisitions, allocations and corrected master data, each through the transaction the ERP releases for it.
Four kinds of result go back. Each has a place where it is accepted, a path into SAP, a path into Oracle, and a confirmation that is captured on the ledger line. The corrected master data comes from the exceptions hub, where a steward fixes a record once and the fix is written back to the system that owns it. How exceptions reach their owners →
| Kind of result | Where it is accepted | Path into SAP | Path into Oracle | Confirmation captured |
|---|---|---|---|---|
| Planned orders | Kinaxis Maestro, o9, SAP IBP, OMP or Blue Yonder, by the planner | BAPI_PLANNEDORDER_CREATE | The interface table or public API for the object; the REST API on Oracle Cloud | The planned-order number SAP returns; the interface status on Oracle |
| Purchase requisitions | The planning application, or a buyer approving a draft raised by a rule | The released BAPI for the object | The interface table or public API for the object | The requisition number, or the reason for rejection |
| Allocations and supply plans | o9, Blue Yonder, SAP IBP or OMP | The released BAPI or IDoc for the object | The interface table or public API for the object; the REST API on Oracle Cloud | Per transaction; control totals on quantities compared per run |
| Corrected master datacountry codes, units, addresses | A steward in Lima, or a quality rule at ingest | The released BAPI for the master-data object | The interface table or public API for the object; a country-code standardisation to Oracle ERP on the showcase estate | Per record; the count is reconciled against the number of exceptions that raised the fix |
One line per write, for SAP and Oracle alike: key, object, target, transaction, status, confirmation and run.
The ledger is the record of every write. It has one line per write, created before the write is sent and updated when the ERP answers. The screen below shows four lines from one run, with SAP and Oracle targets side by side.
| Key | Object | Target | Transaction | Status | Confirmation or reason |
|---|---|---|---|---|---|
| WB-0910-0001 | Planned order accepted in Kinaxis Maestro | SAP S/4HANA | BAPI_PLANNEDORDER_CREATE | Confirmed | planned order 0000123456 |
| WB-0910-0002 | Country code · customer master, steward fix | Oracle ERP | open interface table | Confirmed | interface status: processed |
| WB-0910-0003 | Purchase requisition accepted in Kinaxis Maestro | SAP S/4HANA | released BAPI for the object | Re-queued | reason: plant not open for MRP |
| WB-0910-0004 | Allocation accepted in o9 | Oracle Cloud | REST API | Confirmed | API response: created, id 88213 |
Illustrative ledger: the columns are the product’s; the keys, document numbers and counts are placeholders.
Each line holds the key, the object, the target ERP, the transaction posted, the status, the ERP’s confirmation or its reason, the approver and the run. A re-queued line keeps its key, so the retry updates the same line and the ERP sees one write.
The ledger can be filtered by run, by object or by target and exported for auditors line by line, with the reconciliation state of the run and the name of the person who signed it off. Audit logs on the platform are kept on write-once object storage, where a record cannot be changed after it is written.
A run is complete when the counts and the control totals on both sides agree and a named person has signed off.
At the end of a run, the ledger is totalled per object: records sent, records confirmed, records re-queued. Control totals are compared too: the sum of the quantities or amounts sent against the sum the ERP confirmed. Any variance is listed line by line, with the key and the reason, and the run is signed off by a named person. The ledger, the totals and the sign-off can be exported for auditors.
The same method produces the certified snapshots that regulators read. A certified snapshot is a fixed copy of a view at a point in time, stamped with a hash. A hash is a short code computed from the content, so any later change to the content would change the code. On the showcase estate the v_net_revenue snapshot (hash 96f2b4a1) passed three stages, Data Engineering, Finance and the external auditor, in 6h 14m. The auditor signed and raised 0 follow-up queries.
What a regulator sees is the snapshot, its hash, the three signatures with their times, and the ledger lines behind the figure.
| Check | What is compared | When there is a variance |
|---|---|---|
| Record counts | Records sent, records confirmed and records re-queued, per object, per run. | The re-queued keys are listed with the ERP’s reason for each. |
| Control totals | The sum of the quantities or amounts sent against the sum the ERP confirmed: planned quantity, allocated quantity, requisition value. | The ledger line that moved the total is identified from the ledger. |
| Keys | Each key appears once on the ledger and at most once in the ERP. | A second confirmation for the same key is matched to the same line. A key with no confirmation is re-queued. |
| Sign-off | The run’s reconciliation state, who reviewed it and when. | The export carries the reviewer. A certified snapshot behind a view carries a hash as well. |
From the planner’s click in Maestro to the SAP planned-order number on the same screen, in five events.
BAPI_PLANNEDORDER_CREATE and given a unique key. The ledger line is written before the call is sent.This is the loop that has run in production since 2021: SAP and Oracle read into Kinaxis, and accepted planned orders written back into the ERP. The five events in the timeline are what the planner and the ledger see.
The same path returns an Oracle-owned plan through Oracle’s interfaces: the accepted order goes into the interface table for the object, Oracle’s concurrent program validates and posts it, and the interface status is captured on the ledger line.
The same five events carry an o9 allocation, an SAP IBP supply plan or a steward’s corrected country code. The object and its transaction change; the key, the confirmation and the reconciliation stay the same.
Write-back is off until a test write is confirmed, approval rules are set per object, and the approver is recorded on every write.
Write-back to an ERP is switched off by default, per application and per object. It is switched on for an application after a test write has been confirmed by that ERP, and then per object once the transaction for that object has been tested. A planning application that has been read for months therefore still starts with write-back off.
Approval rules are configured per object. Four-eyes means two named people approve a write before it is posted; you can set it on purchase requisitions above a threshold you choose. For planned orders, the planner’s acceptance in the planning application can count as the approval. A rule that writes automatically does so only for an object whose write-back is switched on and whose approval rule allows it.
Every write is recorded with the name of the person who approved it. The approver sits on the ledger line beside the key and the ERP’s confirmation, and goes into every export.
| Control | Default | How it is set |
|---|---|---|
| Write-back per application | Off | Switched on for an application after a test write has been confirmed by that ERP. |
| Write-back per object | Off | Switched on per object, such as planned orders or country codes, once the transaction for that object has been tested against the ERP. |
| Approval rule per object | A person approves each write | Configured per object: for example four-eyes on purchase requisitions above a threshold you set, or the planner’s acceptance in the planning application counting as the approval for planned orders. |
| Approver on the ledger | Recorded on every write | Part of every ledger line and every export. |
The rejection is captured on the ledger line with the ERP’s reason: on SAP from the return structure or the IDoc status, on Oracle from the error columns of the interface table or the API response. The write goes back into the queue under the same key. Once the cause is fixed, for example a plant opened for MRP or a locked material released, the retry runs and updates the same ledger line. The run’s reconciliation lists the key as re-queued until the ERP confirms it or an owner closes it with a reason.
Yes. Every write carries a unique key that is stored before the write is sent. A replay after a hold, a timeout or a network fault sends the same key, so the ERP posts each transaction at most once, and a second confirmation for the same key is matched to the same ledger line. It is the same property that makes checkpoint resume and ordered replay safe on the Orchestration page.
Write-back is off by default per application and per object, and is switched on after a test write has been confirmed by the ERP. Approval rules are configured per object: a person approves each write, four-eyes applies above a threshold you set, or the planner’s acceptance in the planning application counts as the approval. Every write is recorded with the name of the person who approved it.
Yes. The ledger is exported per run: key, object, target, transaction, confirmation or reason, approver, reconciliation state and who signed it off. Certified snapshots carry a hash; on the showcase estate the v_net_revenue snapshot (hash 96f2b4a1) passed Data Engineering, Finance and the external auditor in 6h 14m, with 0 follow-up queries. Audit logs on the platform are kept on write-once object storage.
Yes. On SAP, write-back uses released BAPIs, IDocs where the object is exchanged as an IDoc, and custom BAPIs the technical user is authorised for. The confirmation is captured the same way in each case, from the return structure of the BAPI or the status of the IDoc. On Oracle, the equivalent is the interface table or public API for the object, and the REST API on Oracle Cloud. The list of transactions per planning target is confirmed during the first load.
A planned order accepted in Kinaxis, keyed and posted to SAP, confirmed with the planned-order number on the planner’s screen, and the ledger line reconciled. The same loop returns an Oracle-owned plan through Oracle’s interfaces.