BAPI_CUSTMATINFO_GETLIST — Read Customer-Material Information Records
Returns customer-material information records matching the supported selection criteria. SAP lists it as a read interface for Sell from Stock integration. It is useful for resolving customer-specific material numbers, descriptions, and related sales context before order creation. Confirm the complete technical key and current object status before relying on the returned result.
Practitioner reference for BAPI_CUSTMATINFO_GETLIST: actual business purpose, high-impact parameters, transaction/commit behavior, RETURN-table handling, S/4HANA position, common integration mistakes, ownership, and the correct proof path.
Published 20 Sept 2026· 729 words
What it does
Returns customer-material information records matching the supported selection criteria. SAP lists it as a read interface for Sell from Stock integration. It is useful for resolving customer-specific material numbers, descriptions, and related sales context before order creation. The important implementation rule is to use the BAPI as the business interface, not to reproduce its posting or validation logic with direct updates to underlying SAP tables.
Important parameters
The exact SE37 signature remains the authority for field names and DDIC types. In practice, the parameters that matter most are the business object's technical key or selection criteria, the organizational context, the structures carrying changed or requested fields, and the RETURN/message structures used to report application validation.
- Use internal SAP key formats where the BAPI documentation requires them, including leading-zero conversion for keys such as material or document numbers.
- For create/change BAPIs that use X or indicator structures, set an indicator only for fields that the caller intentionally supplies or changes.
- Preserve document numbers, item numbers, plant/company code/sales area, fiscal year, and other compound-key fields together; one field alone is often insufficient.
- Read the active interface in SE37 before coding because optional parameters can differ by release and industry add-on.
Commit behaviour
BAPI_CUSTMATINFO_GETLIST is read-only and does not need BAPI_TRANSACTION_COMMIT. A successful RFC/function return is not the same as a meaningful business result: an empty result can be valid, or it can indicate wrong selection criteria, organizational context, formatting, authorization, or object state. Check RETURN and the actual output tables/structures before deciding that the lookup succeeded.
Return handling
Treat the complete RETURN/BAPIRET2 message set as the primary success/failure contract. Scan every row, not only the first one, and treat message types E and A as blockers. Warnings and information messages still matter when they explain partial processing, defaults, skipped items, status restrictions, or data conversions. For create/post calls, also verify that the expected document/object number or result table is populated before committing.
- Never use SY-SUBRC alone as the success test for a business BAPI.
- Log message ID, number, type and variables so the same issue can be reproduced in the standard SAP application.
- For multi-item calls, correlate messages to the affected item or object; one successful item must not hide another failed item.
- After a write, verify the object with the relevant display transaction/read BAPI when the integration requires immediate confirmation.
ECC vs S/4HANA
This BAPI remains relevant to classic RFC/BAPI integration in systems where the business object is supported, but S/4HANA increasingly exposes released OData, SOAP, event, and CDS-based APIs for new clean-core integration. Presence in SE37 does not automatically mean the BAPI is released for ABAP Cloud. For new architecture, check SAP's current communication scenario or released API before selecting an older BAPI merely because it exists.
Common pitfalls
- Calling the BAPI with display-formatted keys instead of the internal format expected by the interface.
- Checking only the first RETURN row or only SY-SUBRC and therefore committing a call that reported an application error later in the message table.
- Issuing a commit before all related BAPI calls in the same logical unit of work have completed successfully.
- Recreating missing business validation with direct table updates when the correct fix is master data, configuration, status, authorization, or a supported API.
- Assuming a BAPI that exists in ECC is automatically the strategic clean-core integration API for every S/4HANA deployment.
Whose problem this is
The SD_O2C functional team owns the business rules, master data, configuration, status, and organizational context behind this BAPI. ABAP or integration developers own parameter mapping, key conversion, RETURN handling, LUW control, retries, and idempotency. Basis becomes involved for RFC connectivity or system-level runtime issues rather than ordinary application validation errors.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-bapis/bapi-custmatinfo-getlistERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.