Table Of Contents

<style>
.toc-macro ul {display: block; counter-reset: item}
.toc-macro li {list-style-type:none}
.toc-macro li:before {content: counters (item, ".")". "; counter-increment: item}
</style>

Objective and Scope

Objective of this Procedure

This document describes the process to handle Customer Master Data to create, modify and extend a new/existing customer accounts in PRS (PF1_50) and RCS (WP1_400) environment and describes the roles and responsibilities of each actor in this process.

Scope

Data Operations Team based in Riga is responsible to handle all Technology Solutions, Composites, Novecare Customer Master Data for all regions and Intercompany extensions and Sales area data updates. 

Requests for Intercompany customer record general data creation/general data modification are within Lisbon SBS team’s scope.

Definitions

Systems overview

In Solvay customer master data is being maintained in four systems – PF1_050, PF1_020, WP1_400, PI_020.

CRM - (Customer Relationship Management Tool) - used to manage a company's interaction with current and potential customers. Salesforce (SF) is the CRM tool used at Solvay. 

Salesforce request is initiated in CRM by Customer Service. Once customer general data is completed by Customer Service Representative, created prospect can be converted into SAP account. It happens through Customer Workflow, which is created automatically once request for conversion is submitted. 

Customer Workflow functionality is used in PRS to request customer creation and changes. Data Management team modifies and approves Workflows initiated by CRM or submits Workflows manually in PRS (PF1_50). After that the Workflow is routed for validation and as soon as it is approved, customer code is generated in the system. Data Operations Representative completes the setup in PRS (PF1_50) and RCS (WP1_400) and Credit Manager completes credit data in CICC (PI1_20). 

PRS (PF1_050) – is used to maintain general data of the customer (name, address, registration number, general contact information, bank details). This information is automatically distributed to the rest of the systems (WP1, PI1, PF1_020 ).

RCS (WP1_400) – is used to maintain customer company code and sales organization information. Once customer general information has been changed in RCS (WP1_400) changes will appear in the CRM system.

PRS (PF1_020) – has similar functionality as RCS, but used by Solvay companies, which are not in Riga Data Operations scope.

CICC (PI1_20) - is used by Credit Management to set up and maintain customer credit data.  

Customer account structure

 Every regular customer consists of 4 roles:

Customer account group defines role of the customer and is chosen upon customer creation.

Receiving a request

New customer creation (including new ship-to accounts) requests must be initiated only through CRM (SF) by CSR. Once request has been submitted in CRM, workflow will be created in PRS and DM Riga will receive automatically generated CRM request form which should include all necessary documentation. 

Prerequisites

Following checks need to be performed before proceeding with customer creation/change.

Duplicate check

To check if the customer already exists in the system, execute transaction XD03. The check should be performed in both systems: PRS and RCS. Duplicate check in PRS is also done automatically by the workflow, but it’s not as specific, therefore manual duplicate check is mandatory.

It’s advised to use three types of searches:

• by Name (in combination with country code)
• by Address (postal code & country)
• by Tax Information

In order to access search enter transaction XD03 and click on the “search box”. In PRS/RCS you can choose several options on how to search for duplicates. It’s advised to use Customers (general), Customers by Address Attributes, Customers by Tax Information.

If the customer is not created in the system, you can proceed with its creation. If it is already created, check for possible updates and forward the number to the requester.

Required documentation

Upon receiving request for customer creation, changes, extension, re-activation check whether mandatory documentation is attached.

All rules and document requirements depending on GBU can be found by following the links below: 

Technology Solutions: https://docs.google.com/document/d/1_dVLkxxZJBVQ-_U3ECyoCPbpMKfM-BNXyn5MXUfb-Ok/edit

Novecare & Aroma: https://drive.google.com/file/d/1Nb0fUdMjTaUsT-dDiGbI1xL_NyyN75yt/view?usp=sharing

Aerospace:  https://docs.google.com/document/d/1CMnBHoT1MQlcqslMFlB2rFzH8Rdzzldtnvx7h84BCgU/edit?usp=sharing

Data Validation

In order to create customers correctly, there are mandatory data validation rules. Please follow this  link to see validation WI with all the rules for specific systems and web pages where validation is performed.

For WP1 customers mandatory validation applies to:

1. VAT numbers for EU customers
2. TAX ID for Brazilian, Peruvian, Chilien, Canadian, Norwegen, Australian and Thailand customers
3. DUNS number verification

Main rules for customer creation and modification

When creating a new WF request, there are some rules that must be strictly followed:

• All the information must be entered in UPPER CASE;
• No special characters and country specific alphabetical letters are allowed. Country specific alphabetical letters must be changed to English letters, for example,   Está to ESTA, Pröll to PROLL, Associação to ASSOCIACAO. 

• Abbreviate as follows (if applicable):

• No spaces are to be entered for company names with alphabetical abbreviation - example, ABC CO and not A B C CO
• For company business type, if it is written as : S.A.S., S.A. or S.A.S.U. no dots and spaces should be used - correct setup is SAS, SA and SASU.
• When customer has another name like a DBA (Doing Business As) / T/A (Trading as) is mentioned in the Credit Application/Purchase order, this name should be written in the second line with “DBA” in the beginning.

Customer creation via workflow

PRS (PF1) is the main system where all customer general data is stored. It’s connected with WP1 where data is transferred after submitting a Workflow.

Transaction Z1S_CWF_REQUEST_LIST can be used to review the list of requests and their current status.

If Salesforce generated WF for incorrect account group, or you want to create payer and sold-to in one WF, in order to avoid double work caused by separate account creations, you can use the steps described below:

1. Use transaction Z1S_CWF_REQUEST
2. Fill in search term, city and country, which exactly matches with information from Salesforce request for account conversion.
3. Select new account group you need.
4. In the result list click “Create from Request number “ and specify the request number received from Salesforce.
5. Check if the account group has been changed correctly.

See below fields to be completed/verified in the Workflow:

Save record: 

Confirm Sold-to creation (if needed):

Once confirmed, workflow is submitted and will appear in the inbox of Data Operations teams. Once the record is reviewed and approved by Data Controller you will receive a notification to your e-mail containing sold-to/payer or ship-to number in PRS - for sold-to and payer you will receive two separate notifications to your personal mailbox with PRS account numbers provided.

Workflow approval

Find request number and open it by pressing Execute .

Request type will be displayed as below - either it is a new creation or modification of an existing account.

Customer creation in WP1 (RCS)

Once this information is completed press on  icon or F8 to proceed. 

Payer General view setup 

Payer Company view creation (extension) 

Payer Sales view creation (extension)

For the initial creation in WP1 customer general view should be completed as described in Payer General view setup. But then customer should be extended to sales area by creating a sales view. Sales view creation is equal to extension.

In case if customer extension is requested, it means that existing customer account must be opened for new sales area. Company code will be generated automatically, if you perform extension by using transaction ZWOC06T.

Exch. Rate Type is based on sales organization, so no matter where the customer is located, if it will be extended to a sales area in LAM, we have to fill the corresponding ERT. This is a mandatory field for all sold-to/payers customers under Sales Areas starting with MX, CL, BR, PE. Sales area ERT BR.. (Brazil) LBRD MX.. (Mexico) LMXD PE.. (Peru) LPED CL.. (Chile) LCLD Field Description Rebate always checkmarked Price determin. always checkmarked Terms of payment populated by Credit Management. In sales order payment terms are pulled from Payer account and it's important to verify that terms are correct on Payer account. See Appendix - Credit Control Representatives for the correct Credit Manager to be contacted. Taxes automatically populated with “1”. If blank, populate as “1”. Mandatory for all Payer and Sold-to accounts. For new creation the path to Additional data is Environment - Additional data. For account extensions the path to Additional data is Extras - Additional data. Field Description Customer grp 1 (location) used for Korea Sales Organizations. Populated for Payer, Sold-to and ship-to: 001 - Domestic 002 - Export Payment method populate as indicated in the request. If not provided, populate with value 004 - Bank Transfer. Invoicing rule populate as indicated in the request. If not provided, populate with value 002 - Billing by order. Applicable only for domestic Thailand customers (payer, sold-to, ship-to): Customer is located in TH. Active for TH01 Sales Org. Sold-to/Payer active for 7774 company code. Populate as '00000' for all Thailand customers (domestic sales). No need for International customers (export sales) as it impacts Thai Taxation.  Upon request value can be changed to 00001-00009/000010 Extra Master Data must be corrected/added in RCS and PRS systems Field Description PRS customer code Corresponding customer code in PRS PRS Main Payer Main payer of the customer. Usually the same as PRS Payer, with exception when payer-bis has been created. PRS payer Payer code in PRS. These numbers can be taken from automatic notifications, informing that WF has been approved and containing the new PRS codes. Save the record Once the record is saved, go back to PRS and by using transaction XD02 check an correct, if applicable,  Extra Master Data links there:  Field Description PRS Main Payer Main payer of the customer. Usually the same as PRS Payer, with exception when payer-bis has been created. PRS payer Payer code in PRS. RCS Customer code Corresponding customer code in RCS. These numbers can be taken from automatic notifications, informing that WF has been approved and containing the new PRS codes. Save the changes

Sold-to General view setup

Note that sold-to account general data has additional information to fill in on General data level which differs from Payer setup.

After going through all general data view screens press save and two more pop-up windows will appear - you can skip them by pressing enter or  and yes.

Sold-to Sales view creation (extension) 

Field Description Sales Office A physical location that has responsibility for the sale of certain products or services. Provided by requester. Also can be determined by location of CSR, requesting creation/extension. Sales Group Sales manager. Provided by requester in SF request - account owner. Customer group Mandatory field for all GBU’s and is used for Solvay Export Compliance Policy purposes. In SF request - GBU Account Sub-type Customer group GBU Account Sub-type Description 01 Industry End-User Mainly 01 for Direct Customers 02 Trade Trader 02 for some internal flows (Raw Materials purchase) 03 Distribution Distributor For Distributors 04 Service Provider Service Provider (Consultant, Testing Laboratory) When no goods are invoiced but only financial costs (freight charges, compensation etc.). Very rare as servicing invoices/credit notes should be used. Exch. Rate Type Based on sales organization, so no matter where the customer is located, if it will be extended to a sales area in LAM, we have to fill the corresponding ERT. This is a mandatory field for all sold-to/payers customers under Sales Areas starting with MX, CL, BR, PE. Sales area ERT BR.. (Brazil) LBRD MX.. (Mexico) LMXD PE.. (Peru) LPED CL.. (Chile) LCLD Cust.pric.proc. Always ‘1’ Cust.Stats.Grp Always ‘1’ Field Description Shipping Conditions General shipping strategy for the delivery of goods from the vendor to the customer. Provided by requester. Relevant for POD Check-marked if proof of delivery (POD) processing needs to be activated for the customer. Provided by requester. Order Combination always unchecked Complete delivery always checked Part.dlv./item always ‘C’ Underdel  Tolerance always ‘5’ Overdelivery Tolerance always ‘5’ Field Description E-Invoicing Indicates if the invoice should be sent via email. Mark it if invoicing contact is provided. Do not checkmark for Latin America & APAC SO's Rebate Always checked Price determination Always checked Invoicing dates Completed for JP & KR customers if applicable. Identifies the calendar that determines the schedule of billing dates for the customer. By default, the invoice date will be the delivery date. Check CRM request. InvoicingListDate Completed for JP & KR customers if applicable. Identifies the customer's factory calendar that is used during the processing of invoice lists. Incoterms Commonly used trading terms that comply with the standards established by the International Chamber of Commerce (ICC). Provided by requester Incoterms 2 Additional information for the primary Incoterm. The characters must be in capital letters and without accent. If not provided, use dot “.”, since this can be corrected on order level by CSR. Terms of payment Usually not populated for Sold-to accounts. Do not modify even if it is not grayed out. See Appendix - Credit Control Representatives for the correct Credit Manager to be contacted in case any changes are needed. If terms are populated and do not match Payer account, there is no need to reach out to Credit Management, as terms are populated in Sales Orders from Payer. Tax Data Auto Filled with ‘1’ - if blank, populate with ‘1’ Used for activating E-invoicing output. If E-invoicing is not requested, leave it blank. Field Description Output type always 'ZEI1' Language Customer main language. Should match with language set up in main address screen. Transmis. Medium always '8' Dispatch Time always '1' Number Please see below description on more standard Partner Functions. Please see Appendix Contact Persons & Partner functions for more details. Field Description SP Sold-to Grayed out as this number should be never changed. SH Ship-to First SH function must always remain the same number as Sold-to, indicating that Sold-to address also functions as Ship-to address. Additional ship-to parties can be added as additional SH functions. PY Payer Change Sold-to number to its RCS Payer number. BP Bill-to Change Sold-to number to its RCS Payer number. If Billing address is different from Sold-to and Payer address, then separate Bill-to account needs to be created and linked here as Bill-to party. For Japan Sold-to and Bill-to numbers should be equal - do not change it to Payer number. ZI Customer Service Representative Add as per the request Q1, Q3, Q4, Q5, ZX - COA receiver Add as per request. Q1, Q3, Q4, Q5 - COA receiver via email; ZX - COA receiver via fax. ZC - invoice receiver Add as per request. Automatic invoicing contact. For Distribution Channel 9O we should never link any non-Solvay/Cytec invoice receiver Not used for APAC (except for Japan, however e-invoicing is not check-marked) Z6 - MSDS receiver Add if needs to be specified on sales org. level. Otherwise adding it in General Contacts Tab with Function ZS is sufficient. Mandatory for all Payer and Sold-to accounts. For new creation the path to Additional data is Environment - Additional data. For account extensions the path to Additional data is Extras - Additional data. Field Description Customer grp 1 (location) used for Korea Sales Organizations. Populated for Payer, Sold-to and ship-to: 001 - Domestic 002 - Export Payment method populate as indicated in the request. If not provided, populate with value 004 - Bank Transfer. Invoicing rule populate as indicated in the request. If not provided, populate with value 002 - Billing by order. Applicable only for domestic Thailand customers (payer, sold-to, ship-to): Customer is located in TH. Active for TH01 Sales Org. Sold-to/Payer active for 7774 company code. Populate as '00000' for all Thailand customers (domestic sales). No need for International customers (export sales) as it impacts Thai Taxation.  Upon request value can be changed to 00001-00009/000010 Extra Master Data must be corrected/added in RCS and PRS systems Field Description PRS customer code Corresponding customer code in PRS PRS Main Payer Main payer of the customer. Usually the same as PRS Payer, with exception when payer-bis has been created. PRS payer Payer code in PRS. System can pre-populate this field incorrectly with PRS Sold-to number. Please check and amend to Payer code if needed. These numbers can be taken from automatic notifications, informing that WF has been approved and containing the new PRS codes. Save the record You will see confirmation of the extension at the bottom of SAP window. Once the record is saved, go back to PRS and by using transaction XD02 check an correct Extra Master Data links there: :  Field Description PRS Main Payer Main payer of the customer. Usually the same as PRS Payer, with exception when payer-bis has been created. PRS payer Payer code in PRS. RCS Customer code Corresponding customer code in RCS. These numbers can be taken from automatic notifications, informing that WF has been approved and containing the new PRS codes. Save the changes

Appendix - List of Sales Areas 

Appendix – Credit Control Representatives 

Appendix - Requirements for Tax Numbers 

Appendix – Contact Persons & Partner Functions 

Appendix – Miscellaneous tasks outside DMO Riga scope