OCI integration for B2B and procurement commerce

OCI (Open Catalog Interface) is a procurement protocol that lets buyers punchout to your supplier catalogue from their own procurement system (often SAP), add items to a cart, and return the cart to their system as a purchase order. It is simpler than full EDI and focuses on catalogue browsing and order creation rather than full order-to-cash exchange. cXML is often used to transport OCI messages. Other EDI standards like PEPPOL or X12 handle order exchange and invoicing differently and may or may not support punchout sessions.

Your product catalogue (titles, descriptions, images, stock status) typically lives in PIM or your commerce platform. Buyer-specific pricing, lead times and product availability are maintained in your ERP. The integration layer reads both sources, applies the buyer's contract pricing and contract terms, and publishes the catalogue to the OCI platform (or gateway) so that when the buyer punchouts, they see only products and pricing relevant to their contract.

The buyer's procurement system sends a punchout request with their buyer ID and session token. Your OCI platform or gateway validates the buyer against your ERP, looks up their contract pricing and approved products, creates a session, and presents a customised catalogue view. The buyer browses, selects items, and returns to their procurement system with a cart payload that your system converts into a purchase order and routes to your ERP for order processing.

When a buyer confirms a cart in OCI, the order details (buyer ID, items, quantities, delivery address, cost centre if applicable) are sent to your order-capture system via cXML. Your system maps the OCI order to your ERP's purchase-order schema, applies buyer-specific rules (approvals, credit limits, dropship logic), and creates the order in your ERP for fulfilment and invoicing. Idempotency and order-number mapping are critical to avoid duplicates.

Your ERP confirms the order and generates an order acknowledgement with promised delivery dates and line status. When goods are picked and packed at your warehouse, the WMS or ERP generates an ASN (advance shipment notice) with tracking and expected delivery. The integration layer publishes both acknowledgements and ASNs back to the buyer's procurement system via OCI so they can track the order from receipt to delivery without chasing email.

Contract pricing (list prices, volume breaks, promotional pricing, lead times) is maintained in your ERP by your sales or procurement team. During punchout session creation, the integration looks up the buyer's contract ID and pricing rules in the ERP and applies them to the catalogue so the buyer sees and orders at their negotiated rates. If contract pricing changes, the ERP is updated and the next punchout session reflects the new terms without manual catalogue updates.

Your ERP can define approval rules for each buyer: minimum order value, cost-centre restrictions, payment terms, delivery-location rules, and so on. When an order arrives via OCI, the integration applies these rules before the order is released for fulfilment. If an order exceeds a buyer's approval threshold or cost centre, it can be held for approval, routed to a specific team, or rejected with feedback to the buyer's procurement system.

Your ERP generates invoices and credit notes based on despatch or delivery confirmation. The integration publishes invoices via OCI (usually as cXML) to the buyer's procurement system, matching the original purchase order and ASN. Buyer accounting teams receive the invoice in their system and can three-way match against purchase order, goods receipt and invoice for payment without exceptions.

The integration monitoring identifies failed order captures, missing ASNs, or invoice delivery failures. Operations teams receive alerts with context (buyer ID, order number, error type) and can investigate and retry. Common failures include invalid buyer ID, pricing lookup failure, network outage, or OCI platform unavailability. Clear exception handling prevents silent failures and ensures no orders are lost.

When a buyer returns goods or disputes an invoice, your customer service or returns team records the credit in your ERP. The ERP generates a credit note, and the integration publishes it to the buyer's procurement system via OCI. The buyer sees the credit in their accounting system and can offset it against future invoices or request a payment reversal.

Standard OCI punchout uses a snapshot of available stock and lead times captured at session creation. Real-time stock integration requires custom connectors to your WMS or ERP that update stock and lead-time data during the punchout session. This is more complex but can reduce oversell and give buyers accurate promise dates when they are browsing.

If your OCI platform is down, buyers cannot punchout. If your ERP is down, orders cannot be acknowledged or invoiced. Fallback strategies include storing pending orders in a buffer queue, retrying with exponential backoff, or notifying buyers of the outage. The integration design should define recovery time objectives and what happens to orders that cannot be processed immediately.

Product changes (descriptions, images, pricing, availability) are made in your PIM or ERP. The integration publishes updates to your OCI platform automatically. Buyers see updated catalogues on their next punchout session. Critical changes (price corrections, discontinued products, lead-time extensions) should be communicated to affected buyers outside OCI so they are aware before their next order.

The buyer initiates punchout from their procurement system (e.g., SAP), which sends their buyer ID and a session token. Your OCI platform validates the token and buyer ID against your customer master in the ERP, ensuring only valid buyers can access the catalogue. Security relies on the procurement system's authentication and OCI token exchange; your integration must validate tokens and reject expired or invalid sessions.

Your ERP must maintain: buyer master records with contract pricing, lead times, credit limits and approval rules; product master data with prices and availability; customer account hierarchy and cost-centre mappings; and order processing and invoicing workflows. The cleaner and more complete this master data, the more reliable OCI order processing will be.