PunchOut catalog for SAP

What moves between SAP and your store

SAP has several products that open a supplier's catalog, and they do not all speak the same protocol. Facts on this page were checked against SAP's help portal on October 3, 2026.

The first three run the OCI session described on OCI PunchOut: the browser calls your store with login parameters and a return address, and posts the cart back as NEW_ITEM-<field>[n] form fields. SAP Ariba has its own page, PunchOut for Ariba. Neither OCI flow carries the purchase order; that follows on a separate route.

What the SAP administrator enters: the call structure

In SAP ERP and S/4HANA the catalog is a web service, set up in Customizing under Materials Management, Purchasing, Environment Data, "Web Services: ID and Description", or in S/4HANA in the Fiori app Settings for Web Services. In S/4HANA Cloud the communication scenario is SAP_COM_0046, OCI Integration. Each row of the call structure has a sequence number, a parameter name, a value and a type:

SAP's notes on the configuration add rules that change what your store receives. Parameters needed for login come before HOOK_URL in the sequence. The "Use HTTP GET" flag is set only when the catalog does not support POST. A web service with an empty description in the user's logon language opens a blank page. A buyer calling from Fiori needs a specific HOOK_URL value, described in SAP Note 2375333.

A call for customer 10432, decoded:

USERNAME=JDEVRIES
CUSTOMER=10432
HOOK_URL=https://s4.bakker.example/sap/bc/gui/sap/its/oci?sap-client=100

USERNAME here is the SAP user name of the person at the buyer, filled from SY-UNAME. Your store has never seen that name, so it identifies the company by the fixed CUSTOMER value and keeps the user name for the cart. SAP's own security guidance for S/4HANA advises against a catalog password stored in Customizing and recommends authentication per user through single sign-on or certificates; S/4HANA also supports OAuth 2.0 for OCI 4.0 catalogs.

Which system owns what

Units: the ISO code has to exist in SAP

The OCI specification defines NEW_ITEM-UNIT as an ISO code maintained in the buyer's system, and SAP SRM enforces it on arrival. The function UNIT_OF_MEASURE_ISO_TO_SAP takes the value of NEW_ITEM-UNIT as an ISO code and looks for a row in table T006 with that ISO code marked as primary. When it finds none, the buyer sees two messages: "Unit of Measure XX sent from catalog is not an ISO Code" and "Incomplete items in catalog. Only complete items were transferred". The line is deleted from the cart and the rest goes through.

The cart of Bakker Installatie B.V. has three lines: 120 receptacles at 9.60, 2 panelboards at 149.00 and 5 packs of cable ties at 3.75. The cable ties go out with unit PK. In this buyer's SAP system no unit has PK as its ISO code, so line 3 is dropped:

The shopping cart holds 1,152.00 + 298.00 = 1,450.00 USD instead of 1,468.75. The buyer orders without the cable ties, and the missing 18.75 never reaches you as an error. Two fixes work: the store sends a code the buyer's system knows, or the buyer's administrator assigns the ISO code in transaction CUNI or converts it in the BAdI BBP_CATALOG_TRANSFER. SAP's support notes describe the usual mistake: an ISO code created in CUNI and never assigned to a unit. Which code a buyer's SAP accepts for a piece differs per system, so the integration keeps a unit table per buyer. The general problem is on Units of measure.

Material groups and field mapping

NEW_ITEM-MATGROUP is 10 characters and refers to a product category in the buyer's system. In SAP SRM it has to match a unique entry in table COMM_CATEGORY. If it does not, SRM silently assigns the user's default category, and the item lands on the wrong approval path or G/L account. The alternative is NEW_ITEM-EXT_CATEGORY with a code from a standard schema such as UNSPSC or eCl@ss, together with NEW_ITEM-EXT_SCHEMA_TYPE; SRM then maps it through its own Customizing.

In SAP ERP and S/4HANA purchasing, the standard program LMEGUICK3 maps the OCI fields to the requisition and order tables EBAN and EKPO. The five fields NEW_ITEM-CUST_FIELD1 to CUST_FIELD5 have no fixed meaning; the buyer maps them in the BAdI ME_CATALOG_INTERFACE_CUST. In S/4HANA Cloud a key user does the same in Custom Logic with the business context "OCI, Purchasing catalogs". Whatever the buyer maps there is what your cart has to fill, so the field list is agreed per buyer and kept in the integration's mapping.

Price validation in S/4HANA

Settings for Web Services has three price validation options for self-service requisitions:

With validation enabled, a price change between the session and the save blocks the requisition. A price change in your ERP at 10:00 on a cart from 09:40 shows up at the buyer as a requisition that will not save. The integration publishes price changes to the catalog at a fixed moment agreed with the buyer, so a running session is not hit by one.

When it goes wrong

The full OCI field list and its lengths are on OCI PunchOut, the store-side items on the supplier checklist. The PunchOut set-up for other buyers, such as Coupa, is cXML and is compared in cXML vs OCI. What the whole flow looks like with your ERP is on the PunchOut hub. Tell us which SAP system your customer runs.