---
name: s4hana-create-po-confirmation
description: Create supplier (PO) confirmations in SAP S/4HANA Cloud Public or on-prem private edition via the SOAP A2X "SupplierConfirmationRequest" service. Use whenever the user wants to create, post, add, generate, seed, simulate, or record supplier acknowledgements / order confirmations / vendor confirmations on S/4HANA — phrases like "confirm these POs", "acknowledge order receipt", "post a supplier confirmation", "seed PO confirmation demo data", "simulate supplier accepting PO", "vendor confirmed delivery". Handles the WS-Addressing-required SOAP envelope, the SupplierConfirmationControlKey prerequisite (PATCHes PO lines that don't have it), the one-way async response model (202 Accepted), and idempotent bulk batches. Do NOT use for goods receipts (use s4hana-create-goods-receipt instead), inbound delivery / ASN, or service confirmations (those use different SOAP services).
---

# s4hana-create-po-confirmation

Create supplier order confirmations on SAP S/4HANA Cloud Public via the SOAP A2X service. **Verified end-to-end against `my438741.s4hana.cloud.sap` 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/<user>-<YYYYMMDD-HHMM>/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 (always do this first)

Before any other action, run the credential-presence check documented in [`shared/setup-check.md`](../../shared/setup-check.md). In short:

1. Is there a `.env` in the user's working directory, OR are `SAP_HOST` / `SAP_AUTH_MODE` already exported in shell? If yes, skip and proceed to Phase 1.
2. If neither, find the plugin's `.env.example` (typically under `~/.claude/plugins/`), offer to copy it to the user's `./.env`, append `.env` to `.gitignore` if present, and **wait** for the user to fill in values before running the main task.

## 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:

```http
PATCH /sap/opu/odata/sap/API_PURCHASEORDER_PROCESS_SRV/A_PurchaseOrderItem(PurchaseOrder='<po>',PurchaseOrderItem='<line>')?sap-client=<n>
X-CSRF-Token: <captured>
Cookie: <captured>
Content-Type: application/json

{"SupplierConfirmationControlKey": "0001"}
```

Valid key on `my438741`: **`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:**

```xml
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:wsa="http://www.w3.org/2005/08/addressing"
               xmlns:n0="http://sap.com/xi/Procurement">
  <soap:Header>
    <wsa:Action soap:mustUnderstand="1">http://sap.com/xi/Procurement/SupplierConfirmationRequest_In/SupplierConfirmationRequest_InRequest</wsa:Action>
    <wsa:To soap:mustUnderstand="1">{{full endpoint url}}</wsa:To>
    <wsa:MessageID>urn:uuid:{{guid}}</wsa:MessageID>
    <wsa:ReplyTo><wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address></wsa:ReplyTo>
  </soap:Header>
  <soap:Body>
    <n0:SupplierConfirmationRequest>
      <MessageHeader>
        <CreationDateTime>{{ISO datetime}}</CreationDateTime>
      </MessageHeader>
      <SupplierConfirmation>
        <ActionCode>01</ActionCode>
        <SuplrConfExternalReference>{{free text, max 35 chars}}</SuplrConfExternalReference>
        <PurchaseOrderID>{{po number}}</PurchaseOrderID>
        <SupplierConfirmationItem>
          <PurchaseOrderItemID>{{po item, e.g. 10}}</PurchaseOrderItemID>
          <SupplierConfirmationLine>
            <ConfirmedDeliveryDate>{{YYYY-MM-DD}}</ConfirmedDeliveryDate>
            <ConfirmedQuantity unitCode="{{ISO unit, e.g. PCE}}">{{qty}}</ConfirmedQuantity>
          </SupplierConfirmationLine>
        </SupplierConfirmationItem>
      </SupplierConfirmation>
    </n0:SupplierConfirmationRequest>
  </soap:Body>
</soap:Envelope>
```

**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
```http
POST /sap/bc/srt/scs_ext/sap/supplierconfirmationrequest_i1?sap-client=<n>
Authorization: Basic <base64(user:pass)>
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/<user>-<YYYYMMDD-HHMM>/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