CREMAS message type — CREMAS IDoc Vendor Master Distribution

CREMAS moves vendor master data as a single logical business object: the general vendor record, the company-code-specific accounting data, bank details, and purchasing organization data. It is almost always outbound from whichever system owns the vendor record, distributed via ALE to other SAP clients or systems, to a central master data governance hub, or out to non-SAP procurement and payment platforms. In multi-client or multi-system landscapes it replaces manual re-keying of vendor data when a vendor is created or changed. It is triggered by change document activity on the vendor master (creation, modification of address, bank data, payment terms, tax data) and pushed to every receiver defined for that vendor in the distribution model. It does not carry purchasing documents or contracts; only master data attributes of the vendor as a business partner.

The IDoc is built around a small set of segments, each mapping to a vendor master table area.

On the sending side the vendor's change documents must be feeding the change pointer mechanism, with change pointers active generally and specifically for message type CREMAS, and the distribution model (transaction BD64) must define the sending and receiving systems with CREMAS as an active message type, including any segment or field filters that restrict what is actually sent. The partner profile (WE20) on the sending client needs an outbound parameter for CREMAS pointing to the correct port and process code, with the message control or ALE layer generating the IDoc rather than a manual BAPI call. On the receiving side the partner profile needs an inbound parameter for CREMAS with the matching process code that calls the vendor master posting function, and the port (RFC destination or file port, per BD64 or WE21) must be reachable. If output is meant to run on a schedule rather than immediately, the change pointer collection report must be scheduled as a background job; without it, pointers accumulate but no IDoc is ever created.

Work from the IDoc status backward toward the master data change, not forward from the interface.

Functional (MM or FI vendor master ownership) decides which fields distribute and to whom, and owns the distribution model and account group mapping. Basis owns ports, RFC destinations, and background job scheduling for change pointer collection. ABAP is pulled in only when a user exit or BAdI on the CREMAS segment population or inbound posting needs to be traced or changed; do not open a development request until the WE02 status and BD64 filter have both been checked.

CREMAS looks simple because it is a single object, but several things make troubleshooting it misleading.

The habit is to select the failed IDoc in BD87 and mass-reprocess it, or to manually set it to status 53 (successfully processed) to clear a monitoring alert. Both hide the underlying problem: if the receiving company code is missing or the vendor is blocked, reprocessing fails again on the next attempt, and forcing the status green makes the vendor record look synchronized on the receiver when it never actually posted, which surfaces later as a payment run or invoice posting that references a vendor that does not exist there.