All articles

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.

You would expect this information to be available on SAP's help page, but SAP does not explain to you how to do a mass-update of ID mappings in C4C. So for everyone trying to figure out how to do mass uploads of ID mappings, read on.

The red herring is SAP's note 3685331 - Unable To Perform Mass Upload Of ID Mapping For Integration In Cloud For Customer - SAP for Me, which is wrong on multiple levels and frankly quite an embarrassment to SAP. 

To me, useOneAsMany is to BTP Mappings what offside is in soccer: incredibly difficult to understand or explain to a newcomer.

I don't need to use it everyday, so I keep forgetting how it works myself - at the same time, I find the various explanations out there very complicated and hard to follow. So I'll give it a try myself, hoping it will at least help me remember next time I need to use it:

In short: useOneAsMany allows you to reuse a field that occurs only once in a context that occurs multiple times. Think header field on item level.

I had a conversation with SAP folks recently and brought up the future of C4C. My current impression in dealing with SAP Support is that it's "maintenance only" and their logic regarding bugs seems to be: SAP standard always "works as designed", so if the reported behaviour is part of SAP it - naturally - can't be a bug. I also noted that there are hardly any new features in C4C, all attention is on v2.

I recently wrote a reuse function that handled all kinds of scenarios and returned different values. However, I forgot to handle the negative case, i.e. where none of these scenarios apply and no (or an empty) value should be returned.

C4C does something funny in this case: It doesn't just return a "blank" value, it returns the value of the last successful "return". 

As we all know, SAP has changed the way exchange rates are replicated with the transition to S/4. In ERP, C4C would pull the exchange rates using a background job. In S/4, the exchange rates are pushed to C4C using a new interface.

I'm a big fan of the Lazy Admin approach. Little did I know that its spiritual father was Kurt von Hammerstein-Equord, a German general and prominent Hitler opponent, who died much too soon.

He classified military officers as follows:

I distinguish four types. There are clever, hardworking, stupid, and lazy officers. Usually, two characteristics come together.

Historically, many users preferred the simplicity of "set-and-forget" basic authentication over the hassle of expiring certificates. However, rising security scrutiny has shifted this mindset.

In SAP Cloud for Customer (C4C), switching to inbound certificate-based integration seems straightforward:

C4C has an interesting quirk (I wouldn't go so far and classify it as a bug): 

Assume you have a reuse function that returns a value.

In this case, you need to make sure that your script always (i.e. in all scenarios) explicitly (i.e. using the return statement) returns a value.

If you don't, it will return the same value it returned when it was previously called.

When IDOC processing raises request errors like " execute_processing 1008:SRT: Couldn't create Object: ("ICF Error when creating object for HTTP DESTINATION "xxx": UNKNOWN ERROR")", it's difficult to find the root cause for two reasons: