Issue Importing Customer Master Data with Multiple Combinations of Sales Area in SAC Model

[AzaanFarooqui]

Hello SAP Community,

I'm currently working on a dimension in SAP Analytics Cloud (SAC) where I'm importing Customer Master Data from an SAP S/4HANA data source via a query.

Each customer  in the source system is mapped with multiple combinations of:

• Sales Organization 

• Distribution Channel 

• Division 

This means the same Customer ID appears multiple times across different sales areas. However, while importing this data into SAC, I'm facing a validation issue during the import step — duplicate keys are not allowed because SAC expects a unique ID per master data row.

I'm attaching the screenshot as well explaining the problem.

What I Need Help With:

• How can I structure the dimension so I can import all combinations of Customer + Sales Org + Dist. Channel + Division without violating SAC's unique key constraint?

[gunesbt · Accepted solution]

Hi,

You can concatenate all key fields to generate your unique ID in SAC along with keeping all of them as properties.

Such as ID  = customer ID  + sales org  + distr channel + division or

concatenate with "_" like ID = "customer ID" _ "sales org"  _ "distr channel" _ "division" . Concatenate function should be available in import 

[gunesbt · Accepted solution]

Hi,

In addition to my previous comment:

I think the key here is if this scenario is needed for planning or analytics only ( or both).

If analytics only :

Having them all separate dimensions without properties is fine because the link between all those dimensions will come from the transactional data and along with cascading effect, your reports will just be fine.

If planning as well:

If you model all customer , sales org, distribution channel, division as separate dimensions, you’d likely need some validation logic to keep them in sync — otherwise users will need to select all of them separately in planning templates which could create a poor / disconnected user experience. Keeping them as properties and defining validation rules avoid this issue ( validation limits apply ).

Also, adding too many dimensions can make the model harder to maintain / design for planning. The SAC modelling checklist suggests keeping models to around 8–12 dimensions when possible – in reality it is usually difficult to keep this limit with clients having complex data model / planning requirements. Therefore, it might be worth checking / challenging if this level of granularity is really required. For example why would Company Code alone is not enough  or is there a strong business need for planning at the Sales Org level within the same company code? If it is really required, having them as separate dimensions, but also properties along with validation rules could be a solid option.

[AzaanFarooqui · Accepted solution]

Hi gunesbt,

My scenario is planning based. Can you please explain me with some more clarification on how I can go about this scenario by keeping salesarea as properties and then defining validation rules?

[gunesbt · Accepted solution]

Hi

I understand you are considering the option of

- having all cust_sales ( concatanated dimension), customer(without concatenation), sales org, division etc as seperate dimensions and

- Having customer, sales org, division etc as also attributes of cust_sales and

- defining validation between cust_sales and customer/sales org etc via cust_sales attributes.

please see the details of "how to create validation rules based on attributes of another dimension".

https://community.sap.com/t5/technology-blog-posts-by-members/sap-analytics-cloud-planning-validatio...

https://learnsap.enable-now.cloud.sap/pub/mmcp/index.html?show=project!PR_12FD79C240A0CCA4:uebung#4 .

If you will go with that design, please check the limits in the same blog / interative learning because in your case there are many validation relevant dimensions and links. I don't think you can have that many properties in the same validation rule ( as the limit I believe was 3 properties - don't have a system to check). As I mentioned before, it may worth checking if this granularity requirement for planning is really inevitable.

[William_Yu1]

In this case, I would suggest to make Sales Organization , Distribution Channel  and Division as independent dimensions instead of properties of customer ID.