PO collaboration and invoicing through Business Network

PO collaboration is the core of Business Network: the buyer's system sends the order, the supplier confirms it, ships against it, and invoices it, all as structured documents. In cXML the main documents are OrderRequest (order and changes), ConfirmationRequest (order confirmation), ShipNoticeRequest (advance ship notice), ServiceEntryRequest for service sheets, InvoiceDetailRequest (invoice and credit memo) and PaymentRemittanceRequest (remittance advice). The managed gateway maps each to and from S/4HANA.

Worked example: Riverbend vibration analysis

Rosa needs a vibration analysis on the rotor line. Omar creates a service PO to Riverbend Facility Services for 4,800.00 USD (illustrative), account assignment cost center 17101107 Detroit Rotor Line. The PO goes to Riverbend's Business Network account. Riverbend confirms, performs the work, and submits a service sheet for 4,800.00 USD; the service entry sheet in S/4HANA is approved by Omar (on Rosa's confirmation). Riverbend then creates the invoice from the PO in its account ("PO flip"), which reaches S/4HANA as a supplier invoice. Ana checks it in the supplier invoice apps, it matches PO and service entry, and it is posted. After the payment run, the remittance appears in Riverbend's account.

Invoice rules on the network

Business Network can validate invoices before they reach the buyer, using invoice rules set in the buyer account: for example, rejecting invoices that exceed the PO amount, have no PO reference, or lack tax data. Rejections go back to the supplier with a reason, so they never reach Ana. These rules are configuration in the buyer account and must be tested like Customizing: one invoice per rule that should be rejected, with the rejection visible in the supplier account.

The supplier view

Suppliers see the process in their Business Network account: orders, their confirmations, ship notices, invoices with status, and remittances. Testing the supplier view means logging in to the supplier's test account linked to Contoso's test environment, or working with a cooperative supplier who shares screenshots. Contoso asked three pilot suppliers to create test accounts and run scripted cases. The evidence from the supplier view is often what proves a defect: "the PO change arrived as a new order" is visible only there.

Ship notices and goods receipt

For catalog items shipped to Detroit, the MRO supplier sends a ship notice when the goods leave its warehouse. In S/4HANA it becomes an inbound delivery against the PO, so the receiving clerk posts goods receipt against the inbound delivery rather than searching for the PO. Tests check that the inbound delivery quantity equals the ship notice, that a partial ship notice leaves the rest open, and that the supplier sees the receipt status if Contoso shares it. Confirmation control on the PO decides whether confirmations and ship notices are expected at all; a supplier that sends ship notices for a PO without the right confirmation control produces errors that look like integration defects.