ERP to C4C Integration Checklist for Customer Projects
Cloud for Customer
SAP Cloud for Customer supports out of the box integration with ERP for all the master data and transactional data objects. The objects of discussion in this content topic are:
- Material Master
- Account Master
- Account Hierarchy
- Employee Replication
• It is essential to perform some checks prior to setting up integration for standard objects between ERP and C4C. This is required inorder to record the customizations that may have been done on ERP side and to understand the system’s processes in a holistic manner.
• We will also see the commonly faced issues/bottlenecks in integration and how do we overcome such limitations by workarounds.
Material Master Unit of Measure Codes (UOM) :
- ECC allows you to maintain common ISO Codes for several distinct UOMs. When the Material Master IDocs get replicated from ECC to C4C the Unit of Measure Codes in the outbound Idoc (MATMAS_CFS) contain the corresponding ISO Codes in the segment E1MARMM-MEINH.
This leads to generation of duplicate segments in C4C causing a failure in Material Replication.
- The duplicate UOMs cannot be processed in C4C and need to be restricted in ECC outbound or on Middleware. A BADI in ECC can be implemented which would not transmit Segments containing the duplicate ISO Codes, and would only transmit one of the segments.
BADI : BADI_MATMAS_ALE_CR
- Another case of duplicate UoMs were similar conversion units between physical base unit of measures (e.g. kilograms, litres, etc..) and trading units (pieces, boxes, bottles, etc.)
E.g. MARMM1 : 10 PCE100KGM
MARMM2 : 1 TONN100 KGM
Here, since 1Tonne == 10 Pieces,
The 2nd segment converts to the same UoM : 10PCE100 KGMs
Since this becomes a duplicate segment, such segments were also restricted in transmission on ECC side using the same BADI used above
- Account replication IDOC “DEBMAS” from ECC to C4C contains the – Account Master Data, Account’s sales specific Relationship data, Contact Person data as well.
- As there is a single IDoc for Business Partner General + Relationship replication, often is the case during replicating sales area specific data of business partners the relationships are also transmitted from ECC, however since the RELATIONSHIP BP has not yet been created in C4C system the ACCOUNT replication fails in. This leads to a failure of a large number of idocs when processed in BULK and cause clogging of processing queues.
- While replication Accounts with relationships in ECC, there would be several failures as the Relationship BPs would not have been created in the C4C system yet. For this, it is suggested to replicate all customers with a Dummy Sales Org “XXX” so as to ignore the sales area data of customers and hence the relationships. Next, we reset the filters for the correct sales area data and re-replicate the entire batch of customers for updating the Relationships. This leads to an Initial Load of data run-twice.
Replication of Natural Persons
- Replication of Accounts with title “Company” and marked as “Natural Persons” fails, as C4C does not identify Natural Persons (C4C Individual Customers) to be associated with Form Of Address Key as “Company”. After substantial analysis and help from Albert N (Product Team), we implemented an exit on ECC to remove the "Natural Person" Indicator and transmit such Accounts where "Form of address Key" is maintained.
This is implemented using the outbound Idoc on DEBMAS-MASTERIDOC_CREATE_DEBMAS
Restrict Replication of Contacts to C4C
If Contacts are not to be replicated to C4C along with ACCOUNT Master data.
In PI the indicator field “contactPersonListCompleteTransmissionIndicator” can be set to “false”This field is available in Message Mapping Structure - ERP_COD_BusinessPartnerERPBulkReplicateRequest
-Account Hierarchy is supported only for customers and not other business partners like Employees (which is identified by the party id type code-918)
-In some customer ECC systems the Employees are maintained in Account Hierarchies as Account Owners/Parent Owners. Replication of such Account Hierarchies can potentially fail in C4C. It would be best to analyse this at the beginning of the project to understand the workarounds.
-A workaround for this, would be to replicate Employees in ECC as Accounts in C4C, by changing the Party ID type Code in middleware to "3" for Business Partner Replication (please check the mapping for BusinessPartnerERPReplicateRequestMessage->BusinessPartner->SalesArrangement->PartnerFunction->PartnerInternalIDTypeCode)
This way Employees would be replicated as Accounts in C4C (a disadvantage). Hence please evaluate the systems here before starting the integration.
-The standard Employee Replication Service ''Employee Replication from External System" can be used only if ECC is integrated with HCM for Employee Master Data.
-If ECC is not integrated with HCM system, the Employee Data migration (replication) from ECC would have to take place manually i.e. using the Data Migration Tool to manually upload all the Employees in system.
Because of the manual upload of Employees, the ID Mapping (for integration) would have to be performed manually as well.
Any delta changes in Employees would need to be manually incorporated into C4C.
That's all Folks!
The above bullet illustrations are from a customer project experiences
Please do leave comments/updates if there have been similar experiences but implemented in a better/improved fashion.
Hope this document benefits all.
Author - Dedeepya