S4hana Create Po Confirmation

s4hana-create-po-confirmation

Create supplier order confirmations on SAP S/4HANA Cloud Public via the SOAP A2X service. Verified end-to-end against SAP S/4HANA Cloud Public Edition 2026-05-12 — confirmation visible in Fiori "Supplier Confirmation" tab on PO 4500000020/10 (Sequential 1, Category AB, qty 50 PC, delivery 05/25/2026).

When to trigger

Verbs: create / post / add / generate / seed / confirm / acknowledge / simulate Objects: PO confirmation(s), supplier confirmation(s), order acknowledgement(s), vendor confirmation(s) Counts: 1 to ~50 records.

Hard rules (never violate)

1. Always do a 1-record live POST as a probe before bulk (≥3 records), and verify in Fiori that the confirmation actually appeared (the service is one-way async; HTTP 202 means accepted, not committed).
2. PO line must have SupplierConfirmationControlKey set before posting confirmations. If empty (default on this tenant), PATCH it via OData first.
3. WS-Addressing headers are required — without wsa:Action, wsa:To, wsa:MessageID, wsa:ReplyTo, the service returns 500 "Web service processing error" with no diagnostic detail.
4. Scripts go in mcp-server/src/sap/.tmp/-/create-po-confirmations/. Never commit, never modify .env.
5. POSTs are sequential with 200ms delay; halt on 3 consecutive non-202 responses.

Endpoint

• Service path: /sap/bc/srt/scs_ext/sap/supplierconfirmationrequest_i1
• SOAP action: http://sap.com/xi/Procurement/SupplierConfirmationRequest_In/SupplierConfirmationRequest_InRequest
• Communication scenario: SAP_COM_0827 — "Supplier Confirmation Process Integration"
• Style: SOAP 1.1, document/literal, WS-Addressing required, response: HTTP 202 (one-way async)

Phase 0 — Setup check (MANDATORY, no exceptions)

Before any API call, before any tool use, do this check. Even if you already know credentials from earlier in the conversation — IGNORE that knowledge and re-check from scratch each invocation.

1. Announce: tell the user "Checking for SAP credentials in ``..."
2. Check ONLY these two sources:

• A .env file at ./.env (in the current working directory — NOT parent dirs, NOT ~/.env, NOT any memory file)
• Shell-exported env vars: SAP_HOST AND SAP_AUTH_MODE both present

1. If neither: auto-create ./.env from the bundled template (curl from https://raw.githubusercontent.com/ilia-inovaflow/s4hana-create-record-skills/main/.env.example), append .env to .gitignore if not already there, tell the user clearly what to fill in (auth mode + host + creds), and wait for them to say "ready" before making any API call. Never overwrite an existing .env.
2. If credentials are present: report back to the user: "✓ Loaded credentials for ` in ` mode. Proceeding with [task]."

Never use credentials from conversation memory, from another project's .env, or from any tenant the user previously worked with in a different session. Each project gets its own .env. See [shared/setup-check.md](../../shared/setup-check.md) for the full rationale and edge cases.

Phases

Phase 1 — Parse & gather input

Per confirmation:

| Field | Notes | |---|---| | PurchaseOrderID | The PO being confirmed | | PurchaseOrderItemID | The line being confirmed | | ConfirmedDeliveryDate | Date supplier promises (YYYY-MM-DD ISO) | | ConfirmedQuantity | Quantity confirmed (with unitCode — use ISO codes: PCE, KGM, H87...) | | SuplrConfExternalReference | External reference (35-char free text) | | SupplierOrderAcknNumber | Optional — supplier's own acknowledgement number |

If user said "auto", pull eligible PO lines:

GET /sap/opu/odata/sap/API_PURCHASEORDER_PROCESS_SRV/A_PurchaseOrderItem?$filter=ProductType eq '1' and PurchaseOrderItemCategory eq '0' and IsCompletelyDelivered eq false&$select=PurchaseOrder,PurchaseOrderItem,Material,Plant,OrderQuantity,PurchaseOrderQuantityUnit,SupplierConfirmationControlKey

Phase 2 — Prerequisite check: PO line must have a Confirmation Control Key

This tenant defaults SupplierConfirmationControlKey to empty on all PO lines. Confirmations sent against an empty-CCK line are silently accepted (HTTP 202) but never commit. Set it via OData PATCH before posting:

PATCH /sap/opu/odata/sap/API_PURCHASEORDER_PROCESS_SRV/A_PurchaseOrderItem(PurchaseOrder='',PurchaseOrderItem='')?sap-client=
X-CSRF-Token: 
Cookie: 
Content-Type: application/json

{"SupplierConfirmationControlKey": "0001"}

Valid key on a Cloud Public tenant: 0001. Returns HTTP 204 on success. After this, confirmations against that PO line will commit.

If you're seeding many confirmations: PATCH all eligible PO lines first (one OData call each), then start posting confirmations.

Phase 3 — Build SOAP envelope

Verified working envelope:

 
 http://sap.com/xi/Procurement/SupplierConfirmationRequest_In/SupplierConfirmationRequest_InRequest
 {{full endpoint url}}
 urn:uuid:{{guid}}
 http://www.w3.org/2005/08/addressing/anonymous
 
 
 
 
 {{ISO datetime}}
 
 
 01
 {{free text, max 35 chars}}
 {{po number}}
 
 {{po item, e.g. 10}}
 
 {{YYYY-MM-DD}}
 {{qty}}
 
 
 
 
 

ActionCode enum (from WSDL — only 3 values allowed):

| Code | Meaning | Verification | |---|---|---| | 01 | Create | ✅ Verified end-to-end — creates category AB (Order Acknowledgement) | | 02 | Update | ⚠️ Accepted (202) but outcome requires Fiori verification — likely requires SupplierConfirmation ID to identify which existing one to update | | 03 | Delete | ⚠️ Accepted (202) but outcome requires Fiori verification — likely requires SupplierConfirmation ID |

Skill default: use ActionCode 01. Update/delete are exposed but treated as advanced — confirm with user before using them and require user to verify in Fiori after.

Phase 4 — POST

POST /sap/bc/srt/scs_ext/sap/supplierconfirmationrequest_i1?sap-client=
Authorization: Basic 
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://sap.com/xi/Procurement/SupplierConfirmationRequest_In/SupplierConfirmationRequest_InRequest"
Accept: text/xml

Expected response: HTTP 202 (Accepted, no body). This is normal for one-way async services.

If response is HTTP 500 with fault Wrong SOAP Version → you used application/soap+xml Content-Type. Switch to text/xml.

If response is HTTP 500 with fault Web service processing error... details in the web service error log on provider side → WS-Addressing headers missing OR malformed. Re-check wsa:Action, wsa:To, wsa:MessageID, wsa:ReplyTo.

Phase 5 — Verify (manual)

The service is one-way async. HTTP 202 doesn't guarantee commit. To verify:

Via Fiori: Open PO in "Manage Purchase Orders" → item → Supplier Confirmation tab. The confirmation should appear with:

• Confirm. Category = AB (Order Acknowledgement) for ActionCode 01
• Delivery Date / Time / Quantity matching what you sent
• Sequential number assigned automatically (1, 2, 3, ...)

Via API: Not possible on this tenant — to_ScheduleLine shows the original PO schedule, not confirmations. The confirmation data lives in EKES (table) which isn't exposed via OData V2 in the standard PO service.

For bulk runs: spot-check 2–3 records in Fiori after the batch completes.

Output structure

mcp-server/src/sap/.tmp/-/create-po-confirmations/
├── eligible-po-lines.json
├── cck-patches.jsonl # log of which PO lines we PATCHed with confirmation control key
├── create-log.jsonl # one line per SOAP attempt
├── results.json # summary
└── verify-checklist.md # printable list of POs to spot-check in Fiori

Reference files

• references/soap-envelope-template.md — full XML template with WS-A headers + ActionCode notes
• references/known-quirks.md — the 3 gotchas (WS-A required, CCKey prerequisite, async-202-doesn't-mean-success)
• scripts/bulk-poc-poster.mjs — reference implementation with PATCH-then-POST flow

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: ilia-inovaflow
• Source: ilia-inovaflow/s4hana-create-record-skills
• License: MIT

Install and usage instructions live in the source repository linked above.