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

Roles & responsibilities of each actor 

The initial  requester - Requests for new customer creations and/or changes can be received through Freshdesk (FD) https://sbs-support.solvay.com/ as a ticket, which can be submitted in FD directly or generated (with low priority) by email sent to  datamanage@solvay.com.

Data Operations Team (Part 1) - Every customer setup or maintenance request should be registered in Freshdesk. Requests received through personal Mailbox should also be entered into Freshdesk.
When initial requests are received through FD, 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) If account creation is approved on credit side then Credit Manager completes credit data and sends formal approval to DM.

Data Operations Team (Part 3) - When approval is received from Credit Manager, responsibility of DM is to perform adjustments (if any) requested by Credit. Responsibility of Data Team is also to close FD ticket in order for the initial requester to receive notification that requested creation/change has been processed in SAP.

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 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 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. See Appendix - Credit Control Representatives for the correct Credit Manager to be contacted. 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. 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'. 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 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 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 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. 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. 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. 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 FD 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.  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. 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. 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. 

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 customer creation

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

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”. 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; CN40 - 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 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

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

*For simple name changes for EMEA accounts (registration number remains the same), there is no need to create a new customer – based on the received documentation/information changes can be done by Data team without approval from Credit, but notification has to be sent to Credit to inform them. In case of any doubts, please ask Credit for advice.

If it is an ownership change, though, we have to create an entirely new account. Therefore, in order to differentiate between the two we have to request a supporting official letter (an email from the customer will NOT do – they can send us a notification via email, but an official document must be attached; PO is also NOT enough – it has to be an official letter). If it’s indicated that there has been a restructuring/merger/acquisition and that’s why the name changes, create a new customer account after approval from Credit.

*No need for approval for name change from Credit EMEA (Nuno Mendes), if no VAT or ownership, business type change. No need for approval for TAX ID addition (if can be validated and has not been previously populated). - Only FYI should be sent to Credit Management, once updated.

Changing general data

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

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

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

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.

Appendix - List of Sales Areas 

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 

Appendix – Credit Control Representatives 

Credit Control Representative must be selected according to customer location or business. Please use G-Drive file for reference in order to determine to which generic mailbox request should be sent (depending on customer country) if the country code is not mentioned in the table below.

• For NAM & LAM & EMEA, please use indicated Credit managers and add generic email in CC.
• For APAC please use Credit Control Team generic email and Credit Manager email in CC.

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 (Dunning letters receiver, 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