Table Of Contents

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

Roles & responsibilities of each actor 

The initial  requester - Requests for new customer creations and/or changes can be received through Service One as a ticket.

Data Operations Team (Part 1) - Every customer setup or maintenance request should be registered in Service One. Requests received through personal Mailbox should also be entered into Service One.
When initial requests are received, Data team member will perform required validation checks and will initiate/modify Salesforce workflow for new creation or modification in PRS. If only sales data is changed then changes will be performed directly in RCS.

Data Operations Riga & Lisbon - Data Operations team in Riga and Lisbon are responsible for validation of the submitted WF’s. This includes general data setup, duplicate check in PRS and establishing a link in Extra Master Data between RCS and PRS customer records as well as link between Payer (account group 0003) and Sold-to (account group 0001).

Data Operations Team (Part 2) - Completed WF returns to Data Team after approval of Data Controller with PRS customer reference number. It is under Data Team responsibility to check whether all the required information was provided to continue with customer set up in RCS. DM creates customer for respective SO/Distribution Channel/Division combination and forwards all setup related documentation to Credit Manager in order to have credit data completed.

Credit Manager - Credit Manager is responsible for credit data maintenance that includes payment terms and credit limit established for customer account in PI1. (PI1 synchronizes with PRS only once a day).

Process Flow

Technology Solutions & Novecare (New Setups)

Aerospace (New Setups)

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

Novecare, Aroma & Silica:  

Aerospace:  

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, India 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 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.

Sales

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

If due to some reasons, system shows the following error for another sales area (red error, which doesn't allow to save the record), choose exchange rate type from the list (full list available in SAP) based on Country code from Sales Org. E.g. for IN12 → LINE (as per screenshot below)

Billing Documents

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. This information is maintained by Credit department.
Taxes	automatically populated with “1”. If blank, populate as “1”.

Environment/Extras - Additional data

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 sales area CN41 and sales areas starting with KR. 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.

Thailand Branch Details

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

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

Payer Company view creation (extension) 

Company code view normally is created automatically upon sold-to and payer account extension to new sales area. In case company code has not been created automatically, you can create it manually via transaction XD01.

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) 

Sales

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. For Novecare all new creations/extensions in which the account will be handled in Lisbon the sales office must be 0113 even if the CSR is not yet in Lisbon, ecept APAC region - there could be different sales office.
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.
Currency	Currency used for the customer. Provided by requester. Aerospace customers located in China will have either US37/0B/75 with USD currency OR CN41/0B/75 with RNB/CYN currency.
PP cust. proc.	For Aerospace Sales areas always "B". For Novecare NAM customers always "A" Enables cross selling products button in Sales Order creation/maintenance.
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 If due to some reasons, system shows the following error for another sales area (red error, which doesn't allow to save the record), choose exchange rate type from the list (full list available in SAP) based on Country code from Sales Org. E.g. for IN12 → LINE (as per screenshot below)
Cust.pric.proc.	Always ‘1’
Cust.Stats.Grp	Always ‘1’

Shipping

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
	Technology Solutions, Novecare, Aroma, Silica	Aerospace
Complete delivery	Always checked	Always unchecked
Part.dlv./item	Always ‘C’	Blank
Max. partial deliveries	Always '0'	Always '9'
Underdel  Tolerance	Always ‘5’	Always '10'
Overdelivery Tolerance	Always ‘5’	Always '10'

Billing Documents

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	Identifies the customer's factory calendar that is used during the processing of invoice lists. For JP sales organizations always use value ZM Services Monthly Invoicing Calendar
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. For Aerospace following table can be used: Incoterms Destination EXW ORIGIN FCA* ORIGIN   *if customer pick-up (prefered Incoterm over ExW) FOB** ORIGIN  **for US ground domestic customer pick-ups Only.  DAP DESTINATION DDP DESTINATION Other Port/Place name (If not provided use ".")
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’

Documents

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	always '1'

Partner Functions

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. Novecare - mandatory requirement to have E-invoicing  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) If txcustomerservice@solvay.com is requested to be added to Aerospace customer, payment method should be changed to 035 (credit card) for payer & sold-to and Ana Pozenato should be added in copy for resolution in ticket.
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. For Technology Solutions is Mandatory to have MSDS contact
BU - Buyer	Add as per request.
CR - Carrier	Add as per request. For Aerospace sales areas: If Solvay pays for freight, add regular freight forwarder. If Customer pays for freight, add carrier with (CUSTOMER) indicated in the name. If new customer carrier is requested, create ticket to DM vendor team to set up customer carrier. Provide customer checklist along with the request. If new Solvay carrier is requested, please ask CSR to reach out to Logistics, to arrange new carrier creation.  For customers located in Brazil Customer carriers must be setup as EU (End User) , since ordinary CR doesn't appear in their local logistics system.
EU - End user partner	EU should be created as ship-to account with no sales view. Only general data should be created. Salesforce/data template are not required for the setup.

Environment/Extras - Additional data

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 sales area CN41 and sales areas starting with KR. Populated for Payer, Sold-to and ship-to: 001 - Domestic 002 - Export
Customer grp 2 (GBU segment)	Mandatory for All GBU sold-to new creations/extensions *  CS1 Strategic CS2 Key Account CS3 Critical Account CS4 Standard CS5 Distributor CS6 Not valid CS7 Not yet assigned
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.

*Customer grp 2 (customer segment)
         1. For the new sold-to's:

• please always make sure to take the segment coming in the conversion form from SalesForce and add it into the Additional Data as in the screen shots above. It is not allowed to leave the value blank.

• The value can be 'not yet assigned' but the field cannot be blank.

  2. For customer extensions (when other sales areas already exist for the same GBU as requested):
  please take segment code from extension GForm or (if not provided) populate the same segment as used in other existing sales areas of the same GBU.

           3. For customer extensions (in cases, when existing extensions are to different GBU)

            take segment code from extension GForm or clarify with CSR, since this is mandatory field for the sales view of all GBU.

Extra Sales Area Data

Applicable only for Aerospace customers. Maintained for Sold-to and Ship-to accounts.

Field	Description
Whole Number Req	Per request
Single Packing List	Per request
Single Parent Batch	Per request
Customer Segment	'NW' - for new creations. Can be changed per request.
Shipping calendar	Per request. If Monday to Friday - leave blank.

Extras - Texts 

Added on Sold-to level. No need to add for Payer accounts. For ship-to accounts to be added if requested. Can be changed without any approvals and there is no need to validate the number. 

1.EORI number: added in field "Inland Carrier's Instr. B&P(1)"
If your GBU uses the Transwide tool the text "Inland Carrier's Instr. B&P(1)" should be filled too. >>> Because with this action the text will flow to the Transwide too.

Add EORI number in the following format → EORI: (EORI number)

2.Customs Broker details: added in field "Inland Carrier's Instr. B&P(1)"
Add Customs Broker details if provided in the request.
Details will include Customs Broker name, address and contacts. 

3.EORI number: added in field "Mentions on all Com.doc. (1)"
This will allow the text to be printed in the Order Confirmation, Delivery Note, Transport Request, Invoice, Debit and Credit note and Packing List.

Add EORI number in the following format → EORI: (EORI number

4.Explanation about customs formalities: added in field "Mentions on Ord.Ack/Invoice (1)"
For Order Confirmation, Invoice and Debit/credit note

• If Solvay UK exporter => EU external customer importer
  
  Attention : Brexit - customs formalities! Since the UK is a third country to the EU, customs formalities must be accomplished on export from the UK and on import in the EU as from January 1st 2021. Solvay will act as an exporter of records from the UK and your company will act as an importer of records in the EU. Please would you kindly communicate to your main Solvay contacts prior to delivery the import customs clearance instructions (your EORI number, EU customs office of destination for transit formalities, your customs’ broker details). For major customs issues please contact solvaycustoms@solvay.com
  
  
• If Solvay EU exporter => UK external customer importer 
  
  Attention : Brexit - customs formalities! Since the UK is a third country to the EU, customs formalities must be accomplished on export from the EU and on import in the UK as from January 1st 2021. Solvay will act as an exporter of records from the EU and your company will act as an importer of records in the UK. Please would you kindly communicate to your main Solvay contacts prior to delivery your GB EORI number. For major customs issues please contact solvaycustoms@solvay.com
  
  
  

Thailand Branch Details

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

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

Sold-to Company view creation (extension) 

Company code view normally is created automatically upon sold-to and payer account extension to new sales area. In case company code has not been created automatically, you can create it manually via transaction XD01.

Approval for creation

Ship-to General view setup

Ship-to general data maintenance is the same as for Sold-to. 

In Contacts Tab For Technology Solutions is Mandatory to have MSDS contact

Ship-to Sales view creation (extension)

Bill-to creation

Separate bill-to party is created when bill-to address differs from Sold-to and Payer address. Bill-to party is created directly in WP1 under the account group 0004 and it should be extended to the corresponding sales organization/distribution channel/division as the sold-to party with which it will be linked.

One time customers

One time customers are those whom we supply only once or rarely. These accounts are used for Free goods and Sample orders, meaning - there is no receivables expected from the customer.

We create a special One time customer record in account group Z004 where we do not store customer specific data in one time account, since this account is used for more than one customer. The customer specific entries such as name, address, bank details and sales data are entered when the document for the transaction is entered into the system by Customer Service.

Things to note:

1. No documentation required;
2. These One time customers are created directly into RCS;
3. There must be only one account per country. Always check if there is no existing account;
4. Account number range starting as 9999XX;
5. Do not confuse this account group with regular one-time customers. 
   ! The main difference between between One time customer (acc. group Z004) and regular One time customers is that the second is going to be set up as a regular customer and will pay for their order, even if it is one time purchase, while the first is receiving Free goods or Sample from Solvay.

Transaction used to create One time customer in RCS: XD01

Transaction to extend One time customer(open for sales view):  ZWOC06T

Intercompany account extension

There are few things to note prior extending IC accounts:

1. There is no documentation required;
2. Payer accounts must be extended first.
3. Most IC accounts in RCS are set up under Sold-to account group (including payers) (Z**1 in PRS). The easiest way might be using RCS cross references to find the Payer & Bill-to account. 
4. Viviane Beraud - is contact for intercompany maintenance. You may contact her in case of complicated requests only! 

IC account extension is performed by using transaction ZWOC06T.

Returns Vendor and Subcontracting (Toller) creation for GBU Composite Materials

Returns Vendor and Subcontracting (Toller) Sales Area

Sales area for both Returns Vendor and Subcontracting customers should be added based on plant code provided. 

On the right side of the resulting table you will find Sales area details - Sales Organization (SOrg), Distribution Channel (DstCh) and Division (Div). 

Returns Vendor and Subcontracting (Toller) Payer Sales view creation (extension)

Billing Documents

Field	Description
Rebate	always checkmarked
Price determin.	always checkmarked
Terms of payment	default terms “0028” or “0442” (Brasil)
Taxes	automatically populated with “1”. If blank, populate as “1”.

Environment/Extras - Additional data

Mandatory for Returns Vendors & Subcontractors

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
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.

Extra Master Data

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

Returns Vendor and Subcontracting (Toller) Sold-to Sales view creation (extension)

Sales

Field	Description
Sales Office	physical location that has responsibility for the sale of certain products or services. For Aerospace: DE13 - 0200; GB40 - 0204; US32 - 0197; US37 - 0197; US33 - 0196; CN41/CN36 - 0191
Sales Group	always “999” INTRA-GROUP SALES
Customer Group	always '01'
Currency	EUR for EMEA region USD for all other regions, if not requested otherwise
Cust.pric.proc.	Always ‘1’
Cust.Stats.Grp.	Always ‘1’

Shipping

Field	Description
Shipping Conditions	Same as Vendor (if not provided, should ask)
Order Combination	Always unchecked
	Technology Solutions, Novecare, Aroma, Silica	Aerospace
Complete delivery	Always checked	Always unchecked
Part.dlv./item	Always ‘C’	Blank
Max. partial deliveries	Always '0'	Always '9'
Underdel  Tolerance	Always ‘5’	Always '10'
Overdelivery Tolerance	Always ‘5’	Always '10'

Billing Documents

Field	Description
Rebate	Always checked
Price determination	Always checked
Incoterms 1	Same as Vendor (if not provided, should ask)
Incoterms 2	Same as Vendor (if not provided, should ask)
Payment terms (for Payer)	Default terms “0028” or “0442” (Brasil)
Taxes	Auto Filled with ‘1’ - if blank, populate with ‘1’

Partner Functions

Payer & Bill-to: link Payer record number extended to its Sold-to - change sold-to number to payer RCS number.

Extra Master Data

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

1. Modify ticket subject to : 
URGENT - Customer xxxxxx name/address change
xxxxxx states for customer RCS number, if customer is distributed also to PF1_20, in the subject must be mentioned PRS & RCS codes 

 2. Go to your private mail and write an email to all involved CSRs with  the following subject: 
Re: Ticket ID [#zzzzzzz] URGENT - Customer xxxxxx name/address change
zzzzzzz states for FD ticket number, 2nd part of the subject is same as subject of FD ticket

 3. Email should be addressed to all involved CSRs, which used the account within the last 24 months  
 4. Attach all supporting documentation and mention that if no response/ out of office notification is received within 48 hours it will be considered as confirmation, that changes can be applied.   

*If email will be sent out from Freshdesk, Out of Office notification will not be received. That's why private mail is the only way to request this type of approval.  
*If you receive an OOO email, the same email should be sent to backup CSR working under the same GBU/manager of CSR, who is out of office. 

Customer changes

Approvals table

Before proceeding with any changes for the customer, make sure to obtain all necessary approvals (usually for Sold-to & Payer parties).

Changing general data

General data: name change, address change, registration numbers addition or typo correction, generic contact information, international translations. 

Before changing general data:

1. Check documents provided that the requests corresponds to information on documents (e.g. copy of PO). If VAT confirms the new name there is no need to wait for Official letter but it would be good to have any supporting documentation. 
2. Perform the necessary validations - validate VAT number/registration number if possible, check if DUNS numbers has changed. 
3. Perform duplicate check directly in WP1 with the new information as there might be another account already existing. Or more accounts to be updated if it is a name change. 
4. Once all the checks has been performed, you can submit workflow for the modification. 
   REMEMBER! If it is a shared customer and it had sales in other sales areas in the past 2 years - you need to contact other CSRs and wait for their confirmation of the change requested. 
5. After changes are done, inform the responsible Credit Management team about changes performed (applicable to name and registration number changes). No need to inform them about address changes. 

Via Workflow

Customer general data changes are being processed via Workflow (Z1S_CWF_REQUEST) in PRS system.

Via transaction XD02

Customer general data should be modified via XD02 only in those cases when the information that needs to be changed cannot be modified through the Workflows.  For example, cross references, Additional data, Blocks, Deletion flags, Text notes etc).

Attribute 7 - Multi currency customer

Once in a while we might receive requests from Customer Service Representatives to add or remove multi-currency customer check-mark.

Whenever an order is entered with different currencies on header & item level, CSRs would get a soft warning. This warning will not prevent order from being processed. 

Changing sales or company code data

Changes in company code or sales area data are managed in WP1. For more information regarding fields please see chapters on company code or sales area creation (extension).

Customer Text Notes

Account upgrade

Account group upgrade is mostly used to change existing Ship-to or Prospect customer to a Sold-to customer. 

Before upgrade make sure that:

• Customer is not linked to other sold-to accounts in both WP1 and PF1_020
• Data matches the request

To change Account Group of a customer use transaction XD07 – Change Customer Account Group.

Customer inactivation & reactivation

A customer master record can be blocked whenever there is a need to temporarily stop all or part of business relations with a customer.

Once all confirmations and approvals are received proceed with the following steps (for inactivation all below mentioned blocks and deletion flags must be set, but for reactivation the same flags and blocks must be removed, search term corrected).

PRS - Customer Block/Unblock and Flag for Deletion

PRS - Customer Block/Unblock

Before to Unblocked should be check any duplicates and the reason why is block.

Then, if it is a Payer go to FD33 in PF1_050 (Using PRS code) and check what is the Credit Status.

If Credit Status = 001 , Customer Master Data Team should hold the request and create a Task for Credit Team asking an Assessment to that customer.

If Credit Staus = 002, 003, 004 and 005 it is OK to proceed with Unblockage Process.

To Create a Task to Credit Team you should assign like this:

 

In Summary /Tittle should be add: Customer to Unblock. Credit Assessment Needed.

There are two ways to block/unblock the customer:

• Transaction XD05 – Customer Block/ Unblock (enter only customer code)
• Transaction XD02 → Extras → Blocking Data

To block the customer complete the fields as follows:

Field	Description
Posting Block	Checkmark
Order Block	Always 'ZZ'
Delivery Block	Always 'ZZ'
Billing Block	Always 'ZZ'
Block Sales Support	Checkmark

PRS – Customer Flag for Deletion

There are two ways to flag customer for deletion:

• Transaction XD06 – Customer Flag for Deletion (enter only customer code)
• Transaction XD02 → Extras → Deletion Flags

To block the customer complete the fields as follows:

Field	Description
Deletion flags - All areas	Checkmark
Deletion blocks - General data	Checkmark

To proceed with the inactivation following steps must be perfomed:

1. Through XD02 transaction change search term to one of the options below.

   Search term	Description
   ****INACTIVE	if customer has been inactivated due to no sales in past 18 months
   ****DUPLICATE	if customer has been inactivated due duplication
   ****INVALID	if customer has been inactivated due invalid/incorrect registration number
   ****DO NOT USE	rarely to be used for setups which is not possible to fix  in any way

2. In Extra Master Data delete DUNS codes and change Reason for the absence of DUNS to DEL.
   
3. Apply blocking/deletion steps in the target systems WP1 (RCS) and/or PF1_020.

RCS - Customer Block/Unblock and Flag for Deletion

It is possible for a customer to be blocked/marked for deletion in all company codes and sales areas as well as only selected ones.

Specific Situations of Block And Unblock - End Of TSA (Transitional Services Agreement)

When Intercompany codes (or codes link to them) are in a TSA situation, it could happen to have duplicate customers since the old "Intercompany" can not be used for new orders but need to close all items and need to be created new "regular" codes in order to keep the business ongoing.

In these peculiar situations the Search Term should be define **END OF TSA and in Name 4 Field add "DO NOT USE FOR NEW ORDERS"

And in the Specific Sales Areas only for the orders:

That way we can check if this client can be used to not or advise any other team (CSR, Credit, etc).

Review of the status of invoices

To check the payment status for assigned documents, we can use Z3F_FA_DOC_FLOW in WP1.

Appendix - List of Sales Area combinations 

List of Sales area combinations  

List of Distribution Channels  

Asia Model

*APAC countries to which this is applicable:  India, Indonesia, Malaysia, S. Korea, Philippines, Singapore, Taiwan, Thailand, Vietnam

NOT applicable to: China, Japan, Australia. For these countries other Sales Areas can be used, e.g., DE13, GB40.

Appendix – List of transactions

Appendix – Example of forms & documents 

Example of documents for Chinese customers

Appendix – Credit Control Representatives 

Credit department can be contacted by creating a Service One ticket:

Appendix – Parties to be notified

Appendix – Queries

To extract data from SAP you can use two transactions:

• SE16 - used to extract data directly from data tables (instructions can be found in Miscellaneous Tasks) 
• SQ00 - predefined queries, used to extract data. These queries have different tables already combined. Please see details below.

There are multiple user groups with different queries available. To switch between them use . Please see below list of some useful queries.

Appendix – Contact Persons & Partner Functions 

There are two types of contact persons:

1. Based on the contact information (MSDS & COA receiver, Invoices receiver)
2. Based on the physical address information (Notify partner, Consignee etc.)

Partner functions numbers can be set up as:

1. Contact persons (Invoices receiver; COA & MSDS receiver etc.)
2. An actual customer/vendor accounts (Ship-to, Bill-to, Vendor etc.)
   
   

Contact persons based on the contact information

Contact persons based on the address information

Other partner functions

Existing customer and vendor accounts can be added in partner functions.

Appendix - Requirements for Tax Numbers 

Appendix - Customer credit status and credit limit check in PI1

It is possible to check, whether credit limit has been already assigned to the customer and whether there are no credit blocks, which prevent order creation (order goes on block).

Appendix – Existing SAP customer creation in CRM and merging of existing CRM accounts

When extending sold-to and/or ship-to to sales areas belonging to GBUs that use CRM, check whether SalesForce ID is present.