Keeping Accounts Ids consistent in C4C – ERP Integration,
considering Special Characters

Business case:

Customer requires Account Id consistency between systems.
Instead of managing internal and external Account Ids, as C4C standard
proposes, they prefer to have one and the same ID for all systems, regardless
what was the system of creation.

In order to keep Account ids as the same it is necessary to
build a new logic using SDK to maintain the C4C ID Mapping Table and it is
necessary also to change some mapping in the middleware.

In this document i explain a possible solution applicable
to Cloud for Customer and ECC using Hana Cloud Integration, adding the
particularity of alphanumeric number ranges.

Configure C4C:

Allow external Alphanumeric Number ranges

Business Configuration settings

Fine Tuning Activity “General Business Partners”

In this case, the Description “external” means that the user
can enter a value manually, it doesn’t reference an external system.

UI personalization:

In order for users to enter an Alphanumeric Account ID
manually, it is necessary to unhide the field from the quick create screen.
This can be done via Personalization.

Keeping External number ranges

Business Configuration settings

Fine Tuning Activity : Integration of Business Partner data
from your Cloud Solution to SAP ERP

When configuring this intervals in the standard it is
imperative that we select the same ranges for Accounts and Prospects we will
use in ERP Transaction SNUM, according to the integration guide. In this case
we can keep the defaults because Ids will be overridden any way in a later
step.

SDK Configuration:

Scripting

In the case of Account creation in ERP; in order to “fix”
the id mapping table before sending the message out to ERP, we need to develop
the following logic:

Business Object:
ObjectIdentifierMapping

           
Node: Root

           
Event: BeforeSave

We override the Account External ID with the alphanumeric value entered by the user in the Account id field.

This changes the id mapping table

import ABSL;

import AP.FO.BusinessPartner.Global;

var OUTBOUND_IDENTIFIER_MAPPING_CODE = “4”;

var ERP_CUSTOMER_NUMBER = “918”;

var BUSINESS_PARTNER_TYPECODE = “147”;

var BUSINESS_PARTNER_NODETYPECODE = “5368”;

if(  
this.OriginTypeCode
== OUTBOUND_IDENTIFIER_MAPPING_CODE
&&

       this.RemoteIdentifierDefiningSchemeCode
== ERP_CUSTOMER_NUMBER &&

       this.LocalObjectNodeReference.ObjectTypeCode.content
== BUSINESS_PARTNER_TYPECODE &&

       this.LocalObjectNodeReference.ObjectNodeTypeCode.content
== BUSINESS_PARTNER_NODETYPECODE)

{

       var customer = Customer.Retrieve(this.LocalObjectNodeReference.UUID);

       if(customer.IsSet()){

           
this.RemoteObjectID.content = customer.InternalID;

       }

}

Creating Scoping Question

For regular users to be able to see the newly created changes in the business object, it is necessary to create a scoping question
that should be checked as “In scope”

This example belongs to a Brazilian Customer, thus the text
is in Portuguese. It translates to:

“Solution for External
ID Mapping  – Service Center”

“Please check to
enable the automatic ID mapping”

HCI Mapping:

From C4C to ERP:

Standard behavior

In our C4C structure in Hana Cloud Integration Designer we can see that there are two fields corresponding to the Account ID. These are
the “Internal ID” and the “ReceiverIntrnalID”. As appreciated in this screenshot of the standard settings, the one that is mapped to KUNNR  (Account id) in ERP is the “ReceiverInternalID”; which is known in our C4C UI as the “External ID” field.

In the standard this ID we send to ERP,  is drown from the Interval we indicated in
the business configuration, under the “Integration of Business Partner data
from your Cloud Solution to SAP ERP” activity.

Changes in the Mapping (optional):

We already did a change in PDI to have the same
“ReceiverInternalID” as the one we entered manually in the Internal ID (Sender
id) , this means the two fields are the same now.

We can keep the standard mapping and keep sending the
“ReceiverInternalID” to ERP, because it now contains the right value we need,
but it is valid also, to have a contingency plan, just in case something goes
wrong with the developed script.

1. Instead of keeping the standard mapping “ReceiverInternalID” to KUNNR;  we change it to

• “Internal ID” to KUNNR

From ERP to C4C:

Standard behavior

In our C4C structure in Hana Cloud Integration Designer we
can see that from ERP , the KUNNR Field is mapped to  “Internal ID” .

In this case, InternalID refers to the ERP id, and ReceiverInternalid refers to the C4C id. Exactly the
opposite of what we see from C4C to ERP, (in which case the InternalID refers to the C4C id)

InternalID is a key field of the Id Mapping table in C4C.

So when the Internal ID (ERP ID) is informed to C4C, the field External id is looked up in the ID mapping
table

If the External ID doesn’t exist, then  the system understands  that this account has not been synchronized with the external system yet. And creates another Account.

In the creation logic (before save event) is where our PDI logic exists so the field will be overriden here anyway

Required changes in the Middleware:

1. We keep the standard mapping  KUNNR à “Internal ID” and we also Map KUNNR to “ReceiverInternalID”.

So in this case KUNNR is mapped to 2 fields at the same
time.

KUNNR (ERP id) is now written on both fields.

Further Integration:

Having the mapping table corrected, the communication of any other further message, like Opportunities or Quotes can happen normally.

We don’t need to change the mapping in any of those documents.

Considerations:

This solution will not work as is if besides using Alphanumeric
number ranges, customers also have special characters in their Ids.

Special Characters in the ERP Ids.

ERP Customer id field allows special characters. The most common is &, but for Brazilian customers, in example , Á, ç, Ô, etc , could be used too.

The Account ID Field in C4C doesn’t allow special characters and it is not possible to switch off this validation in the backend. If we remove this validation (it is standard for all identifiers in C4C) it would have a major impact on the function of the C4C solution.

To achieve this kind of special integration we have 2 options:

1. To remove or replace special characters in
   the middleware

Consideration: If two accounts have similar ids like A&B and AçB and we remove the special characters. Both accounts will appear as AB, causing a duplication error.

2) to Create an Extension field for Account ID that would allow special characters and map that one to ECC: This requires internal
numbering in C4C, so the system would assign ids, user won’t be completing this field manually.

Mapping should be standard.

The only SDK logic is to populate the Account id extension field value with the External id value, if user is System user. (This means the
Account is being created from ERP).

And to override the External ID value created by the system according to number ranges, with the extension field value entered manually by
the User if user is different than system user (this means a real user is creating an account manually in C4C)

I hope this information helps!

Cheers

Natalia