Skip to main content

C4C/S4: Address UUID Mapping

Submitted by Stefan Barsuhn on

With S/4, SAP has shifted the customer/business partner integration with C4C from the legacy DEBMAS IDOC interface to the Web-Service based business partner interface. Part of this interface is the replication of addresses, which are identified by UUIDs.

By convention, if the same object exists in two systems, it should share the same UUID in both. SAP makes no exception regarding this for Address UUIDs, as explained in note 3597552 - How Business Partner Addresses Are Identified Between Multiple Systems - SAP for Me.

New Customers

For new customers created in either S/4 or C4C this means that the source system will generate the address UUID when the business partner (or address) is created, and during inbound replication into the receiver system, the address will have the same UUID. As a result, no mapping is required between S/4 and C4C. In C4C the Address UUID can be identified via the UI debugger (AddressInformation/UUID) or Data Workbench export (Account Addresses standard object). In S/4 the Address UUID can be found in table BUT020.

Existing Customers

But what about existing customers, previously replicated between C4C and ERP? They only had an address UUID in C4C but not in S/4. When ERP is upgraded to S/4, the BUT020 Address UUID is generated as part of the conversion. As a result, the C4C and S/4 address UUID will differ.

To address this issue, SAP has introduced the possiblity to map address UUIDs in C4C (see ID Mapping for Integration: Map Address UUIDs | SAP Help Portal). You can either maintain them manually via Administrator -> ID Mapping for Integration -> Address UUIDs. Or you can upload them via Data Workbench (standard object Object Identifier Mapping). 

How to Map and Maintain Address UUID in C4C

The problem with the ID mapping for Integration is: It only exposes the C4C Address UUID and the "Formatted Address". It is also notoriously unsuited for mass-uploads. See my other blog post for details. I therefore recommend the following approach using Data Workbench:

  1. Create a quickview in S/4 and link the following tables:
    1. CVI_CUST_LINK and BUT000 (PARTNER_GUID on PARTNER_GUID)
    2. BUT000  and BUT020 (PARTNER on PARTNER)
    3. BUT020 and ADRC (ADDRNUMBER on ADDRNUMBER)
  2. Expose the following fields:
    1. Customer ID (CVI_CUST_LINK-CUSTOMER)
    2. Address UUID (BUT020-ADDR_GUID)
    3. Name (ADRC-NAME1)
    4. Street (ADRC-STREET)
    5. House Number (ADRC-HOUSE_NUM1)
    6. City (ADRC-CITY1)
    7. Postal Code (ADRC-POST_CODE1)
  3. Use the following select option:
    1. BUT020-NATION = initial (to ignore international address versions, which have the same Address UUID as the standard address in both S/4 and C4C)
  4. When executing, select output format Spreadsheet
    => You now have a spreadsheet with all addresses in S/4
  5. In C4C, create a custom odata service for business object Customer, exposing the following fields:
    1. Customer External ID (DefaultObjectIdentifierMapping-RemoteObjectID/content)
    2. AddressUUID (CurrentDefaultAddressInformation-UUID/content)
    3. Name (CurrentCommon-Organisation/Name/FirstLineName)
    4. Street (CurrentDefaultAddressInformation->Address->DefaultPostalAddressRepresentation-StreetName)
    5. House Number (CurrentDefaultAddressInformation->Address->DefaultPostalAddressRepresentation-HouseID)
    6. City (CurrentDefaultAddressInformation->Address->DefaultPostalAddressRepresentation-CityName)
    7. Postal Code (CurrentDefaultAddressInformation->Address->DefaultPostalAddressRepresentation-StreetPostalCode)
  6. Export these addresses using Data Workbench (only those where Customer External ID is filled)
    => You now have a speadsheet with all address in C4C
  7. Match the two spreadsheets using a two-way approach:
    1. First match based on matching address (Name, Street, House Number, City, Postal Code)
    2. For the remaining, match based on customer ID (provided customer has only one address in both systems)
    3. Still any remaining? Decide case-by-case
  8. Create a third spreadsheet with the following columns
    1. External Key: C4C Address UUID
    2. LocalObjectID: C4C Address UUID
    3. RemoteObjectID: S/4 Address UUID
    4. RemoteIdentifierDefiningSchemeCode: 948
    5. RemoteBusinessSystemID: the ID of your S/4 "communication system in S/4
  9. Upload via Data Workbench

No activity in S/4 is required.

Now, when you change one of the legacy accounts in C4C, the outbound payload will have the field ReceiverUUID filled with the S/4 address UUID under AddressInformation. As per the above note, S/4 will not create a key mapping entry! It is remains completely agnostic to the C4C address UUID. When you change the legacy account in S/4, the payload will only contain the S/4 address UUID. When C4C receives this, it checks the ID Mapping and automatically derives the C4C address UUID. It is worth noting that for new customers replicated from S/4, C4C will automatically create a mapping entry in ID mapping for integration (even though the address UUIDs are identical).

So in short: C4C to S/4 payloads will contain ReceiverUUID, S/4 to C4C payloads will not.

This is despite the fact that S/4 does support creating key mappings for address UUIDs as well (see above note), so I suspect that one could also do it the otherway around and upload the mappings in S/4 while leaving the C4C mappings empty - but I haven't tested this. S/4 does not provide a built-in mass-uploading tool for key mappings, so using the data workbench to fill the object identifier mapping in C4C is the easier approach in my opinion.

Tags