| Version | Date | Description | Author |
|---|---|---|---|
| v.1 | 30.03.2017 | Creation | Jeremie Seabra |
0. Definitions
0.1 Account Definition
Accounts are Solvay’s customers, partners and distributors.
Each account stores information such as a name, address, phone numbers and customer attributes.
For each account, you can link information such as opportunities, activities, cases, visit reports, notes and attachments.
| Types of Accounts | Definition |
|---|---|
| Corporate Group | Account specifically created for grouping accounts under one parent. Corporate Group is not interfaced with SAP |
Prospect | Solvay's potential customers (sold-to or ship-to), not yet recorded in SAP |
| Indirect Customer | Customer Solvay is not directly doing business with, but is buying Solvay's products |
| Non-Buying Entity | Account not buying products to Solvay, but in relationship with Solvay (i.e. Corporate Centers, Research Centers, Universities, Laboratories, etc.) |
| Ship-to | SAP customer to whom Solvay is shipping the products |
| Sold-to & Ship-to | SAP customer to whom Solvay is selling and shipping the products |
| Key Account | Current or potential account who represents a major & strategic part of Solvay's growth potential and contribution, with an important marketing stake for Solvay. |
0.2 Account Owner
Each Account in Salesforce must have one and only one “Account Owner”. This rule is in place differently depending if the account is a customer or a prospect:
- For prospects, Account Owner is the creator, the sales rep who created the prospect in Salesforce
- For customers, Account Owner is “Admin User”, a generic name meaning the account is controlled by SAP.
Consequences
After conversion, the Account Owner becomes an Account Team member with “Read/Write” access. As a consequence, he will only be able to add people with “Read” access in the account team
Roles & Responsibilities
The Account Owner is in charge of the maintenance of his accounts. He keeps the related data up to date and maintains the account team upon request from other BU's/GBU's
0.3 Account Permissions
| Action | All Sales users | Account Owner / GBU Data Steward (&above) | Account Team Member with Read access (&above) | Account Team Member with Read/Write access (&above) |
|---|---|---|---|---|
| View | yes * | yes | yes | yes |
| Create | yes | yes | yes | yes |
| Request Conversion / Update | no | yes | no | yes |
| Edit | no | yes | no | yes |
| Delete | no | no | no | no |
* Confidential accounts can only be seen by Owner and Account Team members
1. Functional Process 1 - Account Management
1.1. Sold-to/Ship-to customer creation requested in Salesforce (prospect in SFDC and non-existing in SAP)
Figure 2: Sold-to/Ship-to customer creation process (prospect in SDFC and non-existing in SAP)
In this scenario, when checking the request, assumption is that the request is valid and no duplicate account is found. Next scenario covers the situation when a duplicate account is identified.
1.2. Duplicate sold-to/ship-to customer creation requested in Salesforce (existing in SFDC and interfaced with SAP) (SFDC à SAP)
Figure 3: Duplicate sold-to/Ship-to customer creation Process (existing in SFDC and interfaced with SAP)
Note: If the prospect created already exists as an account in Salesforce.com, the “merge” operation will be done by IS Support Team.
1.3. Duplicate sold-to/ship-to customer creation requested in Salesforce (prospect in SFDC but existing customer in SAP used by another GBU) (SFDC à SAP)
Figure 4: Duplicate Sold-to/Ship-to customer creation Process (prospect in SFDC but existing customer in SAP used by another GBU)
1.4. Sold-to/Ship-to customer update requested in Salesforce (SFDC à SAP)
Figure 5: Sold-to/Ship-to customer update request in Salesforce Process
1.5. Sold-to/Ship-to customer update in SAP (SAP à SFDC)
Figure 6: Sold-to/Ship-to customer update in SAP Process
1.6. Sold-to/Ship-to customer deletion in SAP (SAP à SFDC)
Figure 7: Sold-to/Ship-to customer deletion in SAP Process
1.7 Sold-to/Ship-to customer creation requested rejected by CSR (SFDC à SAP)
Figure 8: Sold-to/Ship-to customer creation rejected by CS Process
Note: typical use case: A dummy account is created by mistake by a user confusing Test and prod environments
1.2 API and Mail
Following information are transferred through the interfaces between Salesforce and SAP
1.2.1. APIs
- API : customer creation request from Salesforce
- Salesforce account ID
- Account Owner
- Account Name
- Address (street, zip/postal code, city, country)
- Address (local language) (street, zip/postal code, city, country, language key)
- Customer Service Representative Name
- Customer Service Representative Email address
- Account Partner Type (sold-to, ship-to or sold-to & ship-to)
- If ship-to à take the Salesforce account ID of the sold-to account defined in the relationship (in order to create the relationship ship-to/sold-to in SAP)
- API C: customer creation order from SAP
- Salesforce ID
- PRS ID
- RCS ID
- Account Name
- Address (street, zip/postal code, city, country)
- Address (local language) (street, zip/postal code, city, country, language key)
- Account Partner Type (sold-to, ship-to or sold-to & ship-to)
- Account Status ( = Validated)
- API D: customer update order from SAP
- Salesforce ID
- PRS ID
- RCS ID
- Account Name
- Address (street, zip/postal code, city, country)
- Address (local language) (street, zip/postal code, city, country, language key)
- Account Partner Type (sold-to, ship-to or sold-to & ship-to)
- Flag for deletion
- API E: Account Status
- Account Status ( = Validated)
1.2.2. Mails
- Mail B : customer update request from SFDC (will trigger a mail that contains the following values)
- Salesforce account ID
- PRS ID
- RCS ID (could be blank in RCS)
- Requested by
- Salesforce must request the user to select the appropriate CSR based on the Account team.
- Update requested:
- Account Name
- Address (street, zip/postal code, city, country)
- Address (local language) (street, zip/postal code, city, country, language key)
- Relationship (between a sold-to and a ship-to)
- Flag for deletion
- Mail F : additional information requested at customer creation in Salesforce
- Account Information
- Salesforce ID
- Additional information on the Sold-to:
- VAT Number
- End-Use
- Application
- Contact (lookup to select an existing contact)
- If the Sold-to account is also a Ship-to account, additional information :
- Shipping Conditions
- Full/Partial Loads
- Delivery Hours
- Incoterm 1
- Incoterm 2
- If the Sold-to account is not a Ship-to account as well, existing ship-to account and additional information:
- Ship-to Account (lookup to select an existing ship-to in Salesforce)
- Shipping Conditions
- Full/Partial Loads
- Delivery Hours
- Incoterm 1
- Incoterm 2
- If the Sold-to account is also a Bill-to account, following checkbox:
- Checkbox
- Checkbox
- If the Sold-to account is not a Bill-to account as well, additional information:
- Bill-to Name
- Bill-to Address
- If the Sold-to account is also a Payer account, additional information:
- VAT Number
- Payment terms
- Currency
- Payment mode
- Bank Country
- Bank Account Number
- Bank IBAN/SWIFT
- Estimated Turnover
- Estimated Volume
- Credit Limit Requested
- If the Sold-to account is not a Payer account as well, additional information:
- Payer Name
- Payer Address
- VAT Number
- Payment terms
- Currency
- Payment mode
- Bank Country
- Bank Account Number
- Bank IBAN/SWIFT
- Estimated Turnover
- Estimated Volume
- Credit Limit Requested
- Account Information
1.4 Processes non including an interface with SAP
1.4.1. Creation of an Account
Figure 9: Creation of an Account Process
1.4.2. Update of an account
Figure 10: Update of an Account Process
If the sales rep is actively involved at an account, and cannot edit it, then he will ask to the Account Owner via Chatter or email, to be added in the Account team. (§6.4.2.1 – Update of the account team)
1.4.3. Corporate Group Creation [R-0635]
Figure 11: Corporate Group Creation Process
- Corporate Group Creation
- Sales Reps enter in SFDC the new Corporate Groups after Go-Live in draft status.
- S&M will review / approve on regular basis these corporate groups in SFDC
- SBS will create the Corporate Group in GBR, then the code is replicated in SAP (PRS)
- Hierarchy Updates
- Sales Reps update the link Corporate Group – Customer in Salesforce
- On regular basis, S&M review these links based on a report executed by GBUs data steward. This report will include the info on how many GBUs are working on the Corporate Group.
- SBS will assign on regular basis the customers to the Customer group either in PRS and GBR.
1.4.4. Transfer of Account Ownership
Figure 12: Transfer of Ownership Process
2. Data Model & security
Main objects
- Accounts: Standard Salesforce Object to manage the information about the Ship-to and Sold-to related with the Complaint
- Account Team:
- Customer Segmentation:
- Contacts: Standard Salesforce Object to manage the contact person from the Ship-to or Sold-to
- Contacts to Multiple Accounts:
- Case: Standard Salesforce Object to store and manage all general information regarding a Complaint
- Opportunity:
- Visit Reports:
Last modifications : |
|---|
| User | Last Update |
|---|---|
| Laurent Champiot-ext | 3329 days ago |
| Jeremie Seabra-ex | 3173 days ago |
| Sophie Millet-EXT | 2867 days ago |
| GILLES, Anne | 997 days ago |
| PEYTRAUD, Josiane | 964 days ago |
| Julien Andreoli-ext | 2763 days ago |
| MARKUS, Evita | 530 days ago |
| BRAHIM, Walid | |
| KANJA-ext, Zakaria | |
| NWANGWU, Daniel | |
| Sebastien Rouxel |
The best way to get IT support is to use the new
Service One Platform.













