Keeping Accounts Ids consistent in C4C – ERP Integration, considering Special Characters
Keeping Accounts Ids consistent in C4C – ERP Integration,
considering Special Characters
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.
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.
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
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:
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
var OUTBOUND_IDENTIFIER_MAPPING_CODE = “4”;
var ERP_CUSTOMER_NUMBER = “918”;
var BUSINESS_PARTNER_TYPECODE = “147”;
var BUSINESS_PARTNER_NODETYPECODE = “5368”;
== ERP_CUSTOMER_NUMBER &&
== BUSINESS_PARTNER_TYPECODE &&
var customer = Customer.Retrieve(this.LocalObjectNodeReference.UUID);
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”
From C4C to ERP:
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.
- Instead of keeping the standard mapping “ReceiverInternalID” to KUNNR; we change it to
- “Internal ID” to KUNNR
From ERP to C4C:
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
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:
- 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
KUNNR (ERP id) is now written on both fields.
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.
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:
- To remove or replace special characters in
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!
Thanks, Natalia - SUPER!
Thanks Natalia. This seems to be a common query for many customers. 🙂
Thanks for sharing...................
Really a nice blog, useful to entire C4C community
can you please share some more insight on how the customer numbers are synchronized in these cases where ECC is the leading system for numbering:
Hi I have problems changing the number in the external from 0000010000 and 0000099999. To the numbers 0001000000 and 0009999999 any suggestions ?
It gives me an error that is overlapping.
Hola Juan Carlos,
Are you trying to change the external interval in the General Business Partners Activity?
Maybe you can send me an email with a screenshot of your settings and the error you get.
Thanks for sharing Natalia.
Danke für deine Erklärung. Ich habe neue Iflows angelegt, da unsere benutzten Iflows von 2015 waren. Da ich nicht gesehen habe das die Kundennummer im Standard Iflow nicht entsprechend deiner Beschreibung gematched war, habe ich jetzt das Problem, das ich jetzt neue Kundennummern mit interner Nummerrierung habe und nur die externe übereinstimmt. Gibt es eine Möglichkeit das ich die falschen Einträge löschen kann, damit ich sie vom ERP erneut korrekt replizieren kann.