Sales Office vs. Org. unit C4C

[mbetini]

Hi AlI, I have a scenario that includes the integration of C4C with ERP.

On ERP, the customer has 3 sales organizations and different sale offices working with these 3 organizations, in other words, a scenario of 1 employee for N teams.

OnC4C, the possibility for the assignment of a single (01) employee in an organization structure is on a 1 to 1 ratio.

Have you ever had a scenario like this one?  Any suggestions/recommendations?

Many Thanks

Mônica Betini

[Former Member · Accepted solution]

Hi Monica,

I would try to get an answer "why"? Why do you need this complexity of multiple sales orgs, sales offices, etc... in ERP? What do they do with this setup? Is their quoting/ordering process that complex or is the complexity the consequence of sales ops trying to organize their people to sell in different ways and the only way to model this in ERP is the complex org structure?

From a C4C/front office point of view you basically have two main functional considerations:

1. Access Control-> you need some way to restrict C4C data. This is best handled with Territory Management. You can define n-levels of Territory teams and an employee can be a member of more than 1 territory which allows extreme flexibility how you want to define how people work which will define how they access data using Territory management. This is meant as a LoB key user to define whatever structure they want to organize the people they see best fit to execute sales and be complex yet simply managed in Territory management.

This will restrict the user to accounts they can sell to or not, which starts the SD process. If you don't have access to an account you can sell to, there is nothing more. If you do have access to an account you can sell to, then next would be to apply any sales area specific conditions in SD, which is the second functional consideration...

2. Follow-up SD process-> you need some way to apply any specific price conditions in SD based on sales org, distribution channel, division etc...

This where you should replicate the above sales area data 1:1 into C4C account master and use this sales area data to drive the SD process of quoting and ordering and probably simplify the sales area setup in ECC (Does their quoting/ordering process need to be that complex?)

Assuming you have access to the account via territory management, why should you have multiple sales area information and result in different conditions? Shouldn't you have consistent conditions applied regardless of channel so that customers can't "game" the system to get preferential terms if they go through a specific channel or not?

Rei

[mbetini · Accepted solution]

Hi Rei, thanks for your reply! This is the process that the Customer already uses on ERP. So I am thinking about creating the sales/org team on organization structure (C4C) in such a way that we can map the IDs for initial load/integration. And to assign the employees to different sales office/team use the territory management. But how can I link the territory to sales org? I need to maintain the sales org/team for the ID mapping on the integration process. Do you agree with this solution? Thanks Mônica Betini

[Former Member · Accepted solution]

Great comments.

In C4C over the years we have invested in integrating the ERP Sales Area concepts into C4C as simple as possible so you have some choice in the two "functional considerations" of access control and SD follow-up processes.

For SD integrated scenarios, you will need 3 big concepts setup in C4C

1. ERP Sales Area master data. This is your Sales Org, Sales Group, and Sales Office, as well as Division and Distribution Channel that gets referenced in C4C

2. ERP Sales Area for the C4C Account, C4C Product, and C4C Employee master data

3. Authorizations to define who sees what based on ERP sales area and/or by C4C territory management

Here is the suggested setup. In this order…

1. C4C specific HR org hierarchy to define what is the correct approval process sales ops wants based on a HR "chain of command". 1 employee to 1 org, hierarchy of orgs. These orgs are not replicated from ERP and the assignment of employees to these orgs is managed in C4C only

2. A flat list of C4C sales orgs that represent all of the ERP sales orgs, sales offices, and sales groups. In C4C there is no difference between these types of ERP sales orgs. Also no relationships between the ERP Sales Org, Sales Group, Sales Office is needed to be maintained in C4C Org master as all you are doing is bring them as master data into C4C. You maintain these relationships in the next step...

3. Replicate the ERP Account, ERP Product, and ERP Employee along with the ERP Sales Area data with it that is maintained in ERP. You will also need to do the fine-tuning to define the C4C code lists for the Distribution Channel and Division as well. Each of the corresponding replicated C4C objects maintains the relationships between ERP Sales Org, Sales Group, Sales Office, along with the Distribution Channel and Division on the C4C master data.

You allow ERP to manage the Sales Org structure in ERP, allow ERP to assign accounts, products, and employees to this ERP structure, and then replicate it down to C4C automatically. This is great for IT as they have one place to manage the SD authorizations for people, products and accounts.

4. Setup Territory management to allow the sales ops to define the front office authorizations (you have already defined the back office authorizations when you replicated down the ERP Employee and the ERP sales area data with it). This is optional if IT does not want to allow sales ops to use Territory management.

5. Setup a business role one for Territory Management authorizations and another business role for Sales Area authorizations

Allow sales ops to decide how they want authorizations to be managed in C4C -> either apply the business role for territory or for sales area for their users.

This gives flexibility for sales ops as some sales teams may want complete control to how they want accounts accessed (via territory management) or others would like IT to manage it via sales area. This is a business decision.

What this setup will do is the following

1. User logs into the solution (business role is applied) and authorizations are given to what accounts they can see either by sales area or by territory

2. Once they open the account they will see the available sales area data that is applicable for the account (replicated and managed by ERP)

3. Once they open their employee profile they will see the available sales area data that is applicable for them (replicated and managed by ERP)

4. Once they create a sales doc like an oppty, quote, order, then the right sales area data will get determined automatically which is basically an intersection of their employee sales area data and the account sales area data. If more than sales org is available, then the user has to choose the right sales org to apply to the oppty, quote, order

From here then when you create the follow-ups in ERP, request price, showing the right products that ERP allows to be sold through the sales area, etc… will exactly work based on what is defined in their sales area data in ERP

Hopefully you can see that it will be a business decision for the customer to decide how they want the authorizations to be handled in their CRM->

1. All via sales area (which is the traditional ERP view of the world and what most SD customers who do not use a CRM are used to) -> Good for IT

2. Hybrid of sales area data for the SD transactions and territory management for account management -> Good for Sales LoB/sales ops

There is no right or wrong with any of them, it just depends what the needs are for the stakeholders of the CRM solution.

[Former Member · Accepted solution]

We are using the Sale Territories. This provides access to the accounts we want each sales rep to see. Managing these by the rules, based on zip code primarily.

The issue becomes is that we set the Read access via the role to be unlimited for Activities ( Appointments, tasks, phone calls, emails). This allows persons to see the activity from other users. They write access is set to Restricted. So they can not change these appointments and other activities, but they can still read them.

Our issue becomes if we create reports, they see everything. It is not even limited to their org structure. That becomes a problem as these reports now would need to have different filters for each person or location. If not, the data gets to be so large and makes the report very crowded.

Could sale orgs help us with this if we uses dome hybrid version? We are not integrated with anything at this point as our ECC project has not gotten to implementation yet. C4C is leading the way. We want to make sure we set our structure correctly so that when we integrate we do not have a lot of rework to do.

Suggestions?

[Former Member · Accepted solution]

Hi Rei,

We have implemented the Cloud for Service.I have a query regarding Org Structure replication from SD to C4C.I wanted to understand the relevance of Org Structure replication from SD to C4C also the impact of creating standalone Org structure in C4C given the case we will maintain the Distribution Channel , Sales Org, Division exactly same a s what is maintained in ERP.

Thanks,

Rituja

[JTR · Accepted solution]

Hello Kasai,

Great document! Thanks in advance.

I have a question regarding sales area determined automatically in the business doc creation, specifically for SO creation in C4C.

If you have an account with 1 sales area Sales Org X, Dis Channel Y, Division Z and you also have maintained the product and the employee for this sales areas. Employee assigned to the respective Sales Organization.

However, when i create SO, division is not being determined automatically. Only Sales Org and Dist Channel. Do we have to maintain these at organizational structure?

If not, do you have any ideas what should i check to make it work? I've migrated Org units from ERP and maintained Dist Channel and divisions manually and they are mapped against ECC codes.

Thanks in advance for your inputs.

Cheers,

João Ribeiro

[saurabh_saxena · Accepted solution]

Please check if the below article helps.

http://scn.sap.com/community/cloud-for-customer/blog/2016/05/13/combined-sales-area-determination-in...