Work Instruction

Functional Area: S2S
Process Name: Vendor Maintenance
System: SAP PE1 – client 300

Instructions for creation of this document

Creation

• 1 work instruction per System environment (if multiple systems are used for same process flow)
• Update table of contents: This can be done automatically by right clicking in the table of contents and selecting "update field"
• Use a screen shot making software for easy 'copy-paste' screen shots of system screens or documents

• Purpose:
  • Describe in 1 or 2 sentences the essence of the process
• Work instructions - for the requesters:
  • Indicate by region/country/location the instructions in order to be able to execute the process in the DMO
  • Use appendixes for documentation in multiple languages, listings, local documents, etc. - this to keep the core work instructions concise
• Work instructions - for DMO:
  • Explain each 'box' in the swimming lane called 'SSO' indicated on the process flow; use for each 'box' a new sub header 'process step 1' etc. ('header 2' in Word template)
  • Add systems/document screenshots with complete description and fields in use.
  • Explain if there are local Specifics / Exceptions in table below each screenshot (Don't describe specifics / exceptions in the general process description)
  • Use 'naming convention' for process names, etc.
  • Use appendixes for documentation in multiple languages, listings, local documents, etc. - this to keep the core work instructions concise
• Appendixes:
  • Use for documentation in multiple languages, listings, local documents, etc.

Purpose

The objective of the vendor setup and maintenance in SAP is to enable the S2S processes within SAP in relation to direct and indirect spend purchasing and invoicing parties.

General Description

Every request for a vendor setup or maintenance should be requested through FreshDesk. Requests received through Data Operations Mailbox or Workflow system (AP related requests) should also be entered into Freshdesk. 

SAP Vendor Account Groups

The Account Group field is a high-level grouping which defines the primary use of a supplier. The account group selection drives certain aspects of system processing, such as whether the supplier can be used for invoicing or purchasing.

• All Vendor Master records in the system are assigned to an account group
• The vendor account group is a logical grouping of alike vendors in the system
• The vendor master view layout and field access is controlled via the account group

Determining Account Group

Vendor should be set up only as the invoicing party (ZINV) if:

• The address is a remit-to address, which will be used for payments only
• Vendor has been classified as a Non-PO vendor through the commodity code field

Data Steward should provide commodity code, based on that, you can recognize if vendor needs to be created as a PO vendor under ZVEN account group or as non-PO vendor under ZINV account group.
The list of Non-PO Commodity codes can be found in the table below:

NOTE: Non-PO vendors should not be set up for purchasing
Vendor should be set up only as the main supplier (ZVEN) if:

• The address is the primary and the only address provided for a supplier and it has not been flagged as a Non-PO vendor

Required Documents

A request for vendor setup/maintenance must be accompanied by approvals (see §4) and following documents:

• Completed template for all new creations.

Europe:

• Company Letterhead / Invoice or any official documentation, which contains vendor's name, VAT number, IBAN and address. An e-mail from vendor can also be accepted, if it contains all mandatory details.

Both VAT number and IBAN number must be validated as described in Validation For Customer And Vendor Master Data.

US:

• Company Letterhead / Invoice or any official documentation, which contains vendor's name, address, bank information (if applicable). An e-mail from vendor can also be accepted, if it contains all mandatory details.
• W-9 form except for:

• Applicant interview expense reimbursement;
• Donation payments (local charities, sponsor youth groups activities, etc.);
• Employees;
• Vendor setup for manual payment request to pay back a customer who has a negative balance;
• Amounts received as damages for personal physical injuries or physical sickness (liability settlements for asbestos);
• State institutions, taxes, garnishments
• Contingent workers, if the reason of payment are awards or recognitions;
• Vendors located in Canada – they do not have W-9 form.

Suppliers falling under W-9 form exceptions do not require additional approvals for the creation and have special parameters for the setup:

• Payment terms – NET1;
• Commodity code - non-PO commodity code, according to services
• Segmentation – Sensitive.

There are cases when W-9 form is required for payment request:

• Membership fee;
• If payment request does not fall under any of W-9 form exceptions;
• Contingent workers (consultants)

Customer Carrier: No additional documentation except for customer template is required. VAT number should be provided for European accounts.
NOTE! VAT number is mandatory for all EU based vendors.

Required Approvals

Extension from other systems/company codes:

If vendor exists in other systems or for other company codes:

• In case the payment terms are the same no additional approvals are required, but buyers/data stewards should be informed.
• No additional documentation is required, if the details can be checked against recent invoices. In case no recent invoices found in the system, official document should be provided (invoice, W9 for US, letterhead with bank details)
• No template is required. In case some system specific details are missing, please turn back to the requester to clarify.

Approvals for Direct suppliers (Raw Materials):

Please note!!! Packaging vendors can be set up as both DIRECT and INDIRECT depending if the goods they deliver are in the BOM or not. Please check with the requester, if Packaging needs to be set up as a Direct Supplier, follow Direct Spend setup, in case of Indirect- set up as an Indirect Spend supplier. Approvals for changes and setups should come from persons approving Indirect Spend suppliers.
Approval for creation: No approval for creation is needed if there are standard payment terms (see Appendix 3 – Overview Standard Payment Terms) and if request comes from Direct Spend Data Steward. If request comes from any other person, approval from Data Steward needs to be provided:

Payment terms approval: For new vendor creation if requested payment terms are less favorable to Solvay than Standard Payment terms (see Appendix 3 – Overview Standard Payment Terms) an approval from Procurement Director is requested. In addition, any modification of payment conditions of the existing vendor that is less favorable for Solvay requires a written approval from a Procurement Director.

For Standard or Non-Standard payment terms only "Harmonized payment term codes" also called "Approved Payment term codes" are allowed to be used (see Appendix 4– Overview Harmonized and approved Payment terms).

Transportation related suppliers

Approval for creation - Approval for new vendors can only be granted by Transportation/Logistics Manager.
Payment term approval - Any exception to the Standard Country Payment terms require written approval from a Transportation/Logistics Manager (see table).

Customer Carrier – Customer carrier is used by Customer Service to indicate the carrier used by customer. Additionally only the General data needs to be created (ZVEN is not opened for company code or purchasing organization). Approval/Request for the setup should come from Customer Service Representatives.
Important!!! When new carrier-forwarder is created carrier calendar table should be completed for carriers delivering outbound goods (all customer carriers). On how to do it please see Appendix 6.

Suppliers falling under Indirect Procurement scope of responsibility:

Approval for creation/payment terms: No approval for creation is needed if request comes from Indirect Spend Data Steward. If request comes from any other person, approval from Data Steward needs to be provided:

Suppliers falling under outside Procurement Scope of Responsibility (non-PO)

Approval for creation: No approval for creation is needed if request comes from Finance controller. If request comes from any other person, approval from Data Steward (Finance) needs to be provided:

Check completeness of the template
Upon receipt of the request for the maintenance or creation of a vendor, the completeness of the template (Appendix 6) must be checked and all required documents must be joined.
The template must be always fully completed. If Section 1 can be completed by a vendor, Section 2 is for internal use and should be filled out by the requestor.
 

Changes

Overview of the changes and necessary approvals / documentation can be found in Appendix 14.
Data Governance is responsible for all SAP processes.

• Any changes to vendors that involve the following fields:
• Commodity Code
• Payment Terms
• INCO Terms

REQUIRE approval from Data Steward. For PO suppliers approval for Payment Term changes should come from Procurement Director.
Any other changes to the vendor's address or account information do not require the Data Steward approval. 
NOTE! If payment terms on the invoice are longer (more favorable) than in the system, we can accept requests from AP and change payment terms based on the invoice without additional approvals.

• For following changes we do not require to fill out a request form:
• Contact details
• Banking information
• Currency
• Name
• Address

• For name change in US W9 form should be provided in order to verify that the Tax ID stays the same.

• For name change in other countries, address change and banking information change a letterhead with the new information should be provided. For ZOAD creation/change checklist or an e-mail with the new ZOAD should be provided
• NOTE! Address, currency and name changes for Direct Spend Suppliers should be duplicated in the corresponding Returns Vendor account in the customer master as well. After completing changes in vendor master please send the request to DM RIGA Customer Master Team. When creating the ticket, please provide vendor number, returns vendor number, and original FD ticket number. The purpose of Returns vendor is to maintain an address to which returned (or faulty) goods could be sent back to.

• Extension to another company code–In case the payment terms are the same no additional approvals are required, but buyers/data stewards should be informed.

• Address and currency changes for Direct Spend Suppliers should be duplicated in the corresponding Returns Vendor account in the customer master as well. After completing changes in vendor master please send the request to someone from DMO Customer team.

• If a new vendor needs to be created due to differing currency no additional documentation is requested. If a new vendor needs to be created due to an additional ordering address a checklist or an email with the new address should be provided.

TradeBeam Screening

Each vendor (new creation, address change) has to be entered into TradeBeam to perform the restricted party screening.
https://gtm.tradebeam.com/tb_1_0/login.jsp

General

Steps for restricted party:

NOTE: A copy of the TB screening record (screen shot); and the response from Legal & Compliance Services if applicable on file always must be attached to the request.
If determined the record is Prohibited, DM will notify the requestor that the record is cancelled.

Business partner records screening rules:

• Ship to locations must have complete addresses (Company Name, Street, City, State, Zip Code, Country) 
  PO Box's, districts, zones etc. will not be accepted as ship to locations.
• All invoice to, bill to, invoiced from records must be screened; for these records a PO Box is acceptable.
• All notify parties, intermediate consignees – any record entered into SAP by DM must be screened.
• Refer all Russia and Ukraine new business partners to the Compliance Team for review.
• Some countries will show a flag for "State Department Embargo" – this does not prohibit the business partners and can be approved. (CN is an example)
• Cytec / Solvay locations are not required to be screened.

Compliance team contact information:

• NAM/LAM/EUROPE - trade.control@solvay.com
• APAC – Diane Giglio

Process description

Accessing SAP

The first step is accessing SAP, on your desktop or on the desktop start menu you double-click the icon:

The following pop-up will appear:

Double click on PE1- Production ECC and you'll be connected to log-in screen from SAP. Complete following details and hit Enter.

Enter into the main menu of SAP:

Then transaction code needs to be entered:

Available transaction codes:
XK01 – create new
XK02 – change
XK03 – display
XK04 – view of account changes
XK05 – block
XK06 – mark for deletion
XK07 – account group change

Checking if a vendor already exists

Before creating a vendor, always check if the vendor doesn't already exist in the system. The system will also check for you once you start entering the data, but a small difference like a space, can still accept the creation of the vendor.

Select transaction code XK03, hit enter. On the next screen, put your cursor on the "vendor" field.

Select :

You will get to the following screen:

There are different options how to look up for existing vendor – by name, by registration number, by country etc. You can also press for more options:

Use the name or a part of the name of the vendor (Sentence case)
Use *** as a wildcard, which is replacing a part of the name which you don't enter in the field.

Hit enter and the next screen will appear:

You can select the vendor, by double clicking the record. You will return to the initial screen "Display vendor". Select the views you need to see in detail and compare the data in the system with the input from the requestor.
To find for which Purchasing Organization or Company code this vendor has been created press
Enter vendor number that you have found and press . You will get results for all the companies this vendor has been created:

Double click on vendor number.

If the vendor has not been created at all, you must create a new one.
If the vendor already exists for one company, just extend it for requested company.

IMPORTANT: If vendor's VAT number or tax code has been changed, new vendor needs to be created and old one needs to be blocked and marked for deletion.

Any financial information change for vendor (name, IBAN) needs to be accompanied by official company's letter/invoice/email and check list.

Bank detail verification

Due to Solvay audit requirements for bank detail addition/change requests bank information needs to be verified with the supplier.

It is done by sending an e-mail to the supplier and asking to confirm that the bank details provided upon vendor creation / update request are valid for W-9 exceptions and contacting GCC team for standard vendor creation. 

E-mail templates can be found here for Z011 supplier bank detail clarification. 

For bank detail addition/changes:

• Use the email address mentioned at the general data level (Contact persons section -Financial department contact);
• If email address is not available at the Contact persons section (Financial department contact), use the one in the general data - communication section;
• If email address is not available in the vendor master, check this company in Google and use that email address;
• If email address can't be found in the internet (sometimes companies have only Online web forms for contacting them), contact the responsible buyer;
• Do not send e-mail to the address mentioned on the invoice;
• For Miscellaneous Creditors bank details should be clarified by Data Operations to ensure that outbound is made within the same day, except Governmental Institutions. For Governmental Institutions the requester should provide bank account, contact ID and source of bank account.
  

Exceptions:

• E-mail domain used by supplier to provide new bank account matches Vendor Master Records.
• E-mail used by supplier to provide new bank account matches Vendor Master Records;
• E-mail mentioned in the supporting documentation with new bank account matches Vendor Master Records;
• Vendors located in China, India, Japan, as banking information is being checked during the payment run;
• If IBAN can be validated here GOV.PL for Poland.
  
  

Outbound should be done by GCC Team based on the vendor location:

• NAM/LAM vendors should be contacted by GCC Curitiba (PtP HD LAM/NAM)
• APAC vendors should be contacted by GCC Apac (PtP HD APAC)
• EMEA vendors should be contact by GCC Lisbon (PtP HD EMEA)
• For countries Poland, Finland, United Kingdom, Latvia contacted by GCC RIGA (PTP HD RIGA)

Fresh desk ticket for contacting GCC
In order to contact GCC team, please submit new or existing request in a FD ticket following request type/process.

With following group:

Please see below the points of what should be added in the ticket:

1. Vendor ID and Country (in Freshdesk ticket subject)
2.  SAP Vendor Master Data contacts

3. Vendor contacts from official page in the Internet

4. Which data needs to be confirmed (VAT, Contacts, Bank account, Bank ABA routing number, check remit address for US payments by check,...)

5. If SBI/RIB/Evidence is required (Vendor Creation Required Documents)

GCC Team’s Procedure.

If the GCC Team receives anything related to bank details, they will transfer the ticket to Data Team to determine the necessary actions as only Data will be able to better tell if an outbound is required, which team should perform it and if necessary, transfer the ticket back to GCC for outbound.

If the outbound from GCC has been unsuccessful after their 3 attempts, the ticket will be transferred back to Data Team for further actions:

• If there is no Bank Data in Vendor Master, Data Operation will inform requester that they were not able to confirm the Bank Account and due to that the same will be empty until the first invoice will be received and posted. When this is done, invoice is posted and blocked and then the supplier will have an Invoice Reference to identify why we have contacted them. 
• If there already is Bank Data in Vendor Master, payment is performed to what we already have and no changes are made until further contact from the supplier.
  • If GCC has forwarded the documentation and screenshots from the system to the supplier the outbound is not considered as valid. 

Creating a vendor

Create Vendor: Initial Screen

The transaction for new vendor creation is 'XK01':

VendorFor a new creation vendor number must stay blank. The system will automatically assign a number to the vendor at the moment of saving the record.

Company Code Vendor should be opened in Company Code if the remittance address is the same as the general address for PO suppliers or if it is a non-PO supplier.

Purch. Organization

CP01 for ZVEN vendors;
Blank for ZINV vendors.

Account group

ZVEN – for PO Vendors;
ZINV – for non-PO vendors, or for PO vendors with differing invoicing address;
ZOAD – for Ordering address.

NOTE! For Customer Carriers vendor should not be opened for Purchasing Organization or Company code.

Create Vendor: Address

Name Company name. In this line the name should not be longer than 40 characters. If the name exceeds 40 characters, second line (it is field Name 2) is to be used for next 40 characters. Do not use commas or any special symbols in the name (except for the '&' sign if specifically requested). NOTE! Name 1 and Name 2 fields are printed on documents and labels – try to accommodate all name info in those 2 fields. (Sentence case) 

Search Term1 Should capture the "essence" of the vendors name:

• Suppress any business entity types, such as "Corporation", "Company", "Co", "SRL", "GMBH" etc.
• Don't use any special characters - dots/hyphens/commas etc.
• Suppress eventual first name if this is a person (only use the last name)
• If the name contains initials, put a space after each initial (e.g. EPC POWDER should read as E P C POWDER)
• If the name contains more than one word, populate as much as it fits (even if the last word fits only partially)

Search Term2 Filled in for:

• ZEMP vendors - PeopleSoft ID
• ZINT vendors – 'PAYER' for Payers, Plant numbers for Plants.
• ZVEN and ZINV – 'WITHOLDING' for vendors eligible for Witholding (Mondovi).
• 1099 reportable suppliers – '1099', except if
  • company is a Raw Material supplier;
  • "Corporations" or " Incorporations" is checked on the W-9 form;
  • Box is checked next to "Limited liability company", but in the comment is letter "S" or "C" = Corporation in W-9 form.

C/O - 'Care of' / 'Attention to' name (if applicable). Part of the address if the recipient is different from the occupant and the names are not similar. Starts with "C/O" or "FAO", else blank.

NOTE! Information entered in C/O field is not printed on documents, therefore to make this information visible for document users it may be copied to Name 2 field.

(Sentence case)
Street - Main field for street address of vendor, max 35 characters to be filled in this field. As Street 2 and Street 3 fields are not printed on all documents, street should be fitted in this field. 

This field is used to capture PO Boxes as well. If a PO Box is used only for remittance information a ZINV account with it should be created.
(Sentence case)
District - Will be populated automatically for USA and Canada depending on the Country, State and Postal Code.
Postal Code - Postal code / ZIP code. SAP provides standard postal code format checks depending on the country maintained.
City - City name. For USA and Canada SAP may overwrite the City name with a value depending on Postal Code. (Sentence Case)
Country - Country code (Appendix 9 –list of country codes in SAP).
Region -  State / Province / County. Choose according to the City.
Mandatory for US and Canada and optional for other countries.
Time zone - Automatically determined by the system.
Tax Jurisdictn - Automatically assigned by the system for US suppliers.
Transportation zone - Transportation Zone is defined based on Country Code (CC) and Postal code (PP..) as follows:

For US: Country Code (US) + first 3 symbols of postal code, CCPPP (Example: US750 if the postal code is 75053-2029)

For other countries: Country Code + first 3 symbols of postal code if postal code is less or equal to 5 symbols, CCPPP
Country Code + first 4 symbols of postal code if postal code contains more than 5 symbols, CCPPPP

For countries which do not have zip codes: SAP Country Code + 3 or 4 zeros, CC0000.

Inner spaces and dashes are eliminated before concatenation:

                            Ex1: Country CA, Post code H7L 4R9 = 6 symbols = CCPPPP = CAH7L4 (no space)
                            Ex2: Country KA, Postal code 110-360 = 6 symbols = CCPPPP = KA1103 (no dash)

TZones are dependent upon Country Code master (T005).
Customer, Vendor and Routes are dependent upon TZones.

Note! In case correct TZone cannot be found based on the codification above, please consult Appendix 15.

Language - For structural material sites language defaulted to EN – English

Local language details are maintained for Process Material Vendors which only deal in French and Italian

• If a Process Vendor has a country address in France and is only open for Toulouse company code then set the language indicator to French
• If a Process Vendor has a country address in Italy and is only open for Mondovi company code then set the language indicator to Italian

Wen extending existing vendor from Toulouse or Mondovi to a different company code please make sure to check that language code is set to EN for all company codes. 

Telephone - Telephone number, consisting of dialing code and number, but without the country code as it is being picked automatically based on the country entered as part of the address. If more than one telephone number is maintained for an address, the first telephone number is marked as the standard number. Press Other Telephone Numbers button to maintain more numbers.
If the country code of the telephone number is different from the country in the address, it can be changed in the pop up "Maintain Telephone Number".

Fax - Main fax number of the vendor (Without country code and without blanks).
E-mail - Main e-mail address of the vendor. Mandatory field, POs will be send to this e-mail address.
StandardComm.Mtd - Standard communication type with vendor. Preferred/default value should be e-mail

Create Vendor: Control

Customer - In cases mentioned below this field is populated with SAP number of the customer counterpart of the supplier:

• Direct spend suppliers (Returns vendor number);
• Customer refund vendors;
• Intercompany vendors.

For all Direct spend related vendors: send to someone from DMO C2C team in order to create customer general view and sales org. screen (VD01) (attach all received documentation). When customer part is completed, add customer reference number in the Control screen and then ticket can be closed.

Tax number 1 - For US - SSN from W9;
                           For China – registration number (old);
                           For Italy – Fiscal code;
                           For France – Siret number
Tax number 2 - For US vendors populate EIN from W9.
                           For Additional Tax number for reporting to the tax authorities (Country Specific).

For the US SSN or EIN is mandatory unless it is a W9 exception. Missing SSN or EIN can be added, but if a company has changed its registration number a new account should be created and the old one inactivated.

Tax number 3 -  For China - registration number (new).

Tax number 5 - For China – registration number for natural persons.

Fiscal address - If ZLEG (Legal Address Vendor) record is created, it should be linked to the main vendor – ZLEG account number in the Fiscal address field. Currently is not used.

VAT Reg. No. For EU vendors, populate VAT registration number (all VATs to be preceded by country code). In case a company is registered in several countries we can maintain more than one VAT registration number using the "Other" option. There should not be more than one VAT for one country.
If the VAT number is missing it can be added, but, if the company has changed its VAT number, new account should be created and the old one inactivated.

Industry - Strategic – 0001;
                  Non-strategic – 0002;
                  Sensitive – 0003.

(If not specified in the checklist, please use 0002 - non-strategic for regular vendor setups and 0003 – sensitive for employees)

SCAC - Populated only for US Forwarding Agents/Carriers with standard Carrier Access Code (SCAC)

Stat. gr. Service - Refers to a statistics group for transportation service agent to determine transportation/logistics data.

Should be defaulted to:'01' - Relevant for statist for all Forwarding Agents (Commodity codes – FREIGH, FRLEAS, FSTPLO, FSFMSV);

'02' - Not rel. for statist for all other vendors.

NOTE: Please forward W9 forms to Janis Zvaigzne (cc Martin Bright) in all cases, except the following:

• if company is a Raw Material supplier;
• if "Corporations" or " Incorporations" is checked on the W-9 form;
• Box is checked next to "Limited liability company", but in the comment is letter "S" or "C" = Corporation.

At the beginning of a new year a report with all 1099 reportable suppliers will be provided to Accounts Payable team.

Payment Transactions. Setting up banking details.

If a different vendor number has to be used for remittance information banking details should be added only for ZINV account.
Ctry- Enter country code of the banking details
Bank Key

NOTE! If routing number for US validates as Joint UPIC Account the bank name should be JOINT UPIC ACCOUNT.

Bank account Account number (For more details see Appendix 1). For Belgian accounts the format should be as follows 3 digits-7 digits-2 digits.

BnkT 0001 for default banking details, for the other 0002, 0003 etc. This option is used if the vendor is using different accounts simultaneously. If a bank account will not be used anymore the line with the outdated banking information should be removed.

For EU banking details, press under the IBAN column and check the proposed IBAN or add the IBAN manually, if it is necessary.

You can check and adjust the banking details by pressing . Please check if SWIFT, ABA and Bank name is correct before proceeding to the next view.

If there are no banking details available for the Banking Key used, you will be requested to populate the following fields:

Bank Country - Country of the Bank. Will be populated automatically.

Bank Key - Bank key/Sort code for Europe, ABA for US, CSA for Canada. Will be populated automatically.

Bank Name - Name of the bank. Do not use commas or any special symbols in the name. Mandatory field.

Region - State for US and Canada, county for UK etc. Optional.

Street - Street of the Bank. Optional.

City - City of the Bank. Optional.

Branch - Bank Branch. Optional.

SWIFT/BIC - Mandatory for European banks and for international transactions (for US banks as well). This field can be populated if empty, but any changes which are not requested by Payment team should be approved by Edgars Bigacs. If SWIFT ends in "22" or "XX" Payment team should be contacted to clarify the full SWIFT.

NOTE: Creation of new bank codes can be accessed through transaction code FI01 and editing through FI02.

Contact Persons

First name - Contact name. (Sentence case)

Name-  Contact last name. (Sentence case)

Additional information, such as telephone and email, can be added through "Partner details". 

Department - 0002 – Purchasing contact (please note, POs will be sent to the e-mail, entered on General Data - Address screen - Communication section).
0009 – Financial department (e-mail for payment notifications, remittances).

Language - EN English by default.

Telephone - Telephone number, consisting of dialing code and number, but without the country code as it is being picked automatically based on the country entered as part of the address. If more than one telephone number is maintained for an address, the first telephone number is marked as the standard number. Press Other Telephone Numbers button to maintain more numbers.
If the country code of the telephone number is different from the country in the address, it can be changed in the pop up "Maintain Telephone Number".

Fax - Fax number of the contact (without country code and without blanks).

E-mail - E-mail address of the contact.

Comm. Meth. - Standard communication type. Preferred/default value should be e-mail.

Accounting Information

Recon. account should be populated

Sort Key 001 "Posting date" by default

Payment Transaction Accounting

Payt terms - Payment terms agreed with the vendor. Should be provided in the "Setup Details – Information from Requester" part of the template. Only Solvay Harmonized and approved payment terms can be used (Appendix 7 – Overview Harmonized and approved payment terms).

Chk double inv.- To be checked always. This means that incoming invoices and credit memos are checked for double entries at the time of entry.

Individual pmnt - If this indicator is set, every customer/vendor open item is paid separately during automatic payment transactions. This means that open items are not grouped together for payment. Should be checked upon a request from AP department.

Payment methods: For company codes 1237 and 1246

For company codes 7218, 7223, 7250, 7252, 7257

Specifics/ Exceptions:

Withholding Tax Accounting

For now, this view is not populated.

Purchasing Data

Order currency - Purchasing currency.

Terms of paymnt - Payment terms agreed with the vendor. Should be provided in the "Setup Details – Information from Requester" part of the template. Only Solvay Harmonized and approved payment terms can be used (Appendix 7 – Overview Harmonized and approved payment terms).

Incoterms - Should be provided by requestor (see Appendix 8 for available incoterms).

Schema Group, Vendor - For Intercompany (ZINT) vendors - 'ZS' – Cytec STO vendors;
For the rest of the account groups defaulted to 'ZC' - Cytec Vendors.

Pricing date control -  "1" by default.

Gr-Based Inv.Verif - Marked for all vendor records.

Acknowledgment Reqd - Marked for all Direct spend related vendors: classified with 'RAWMAT' or a 6-symbols COMMODITY CODE starting with 'PA….'

Automatic Purchase Order - Marked for all Direct spend related vendors: classified with 'RAWMAT' or a 6-symbols COMMODITY CODE starting with 'PA….'

Subsequent Settlement - Marked for all vendor records.

Subseq. Sett. Index - Marked for all vendor records.

B.Vol.Comp./Ag.Nec - Marked for all vendor records.

Doc. Index Active - Marked for all vendor records.

Returns Vendor - Marked for all Direct spend related vendors: classified with 'RAWMAT' or a 6-symbols COMMODITY CODE starting with 'PA….'
Check mark should be added only after returns vendor has been created. In the popup screen add returns vendor number in the "Customer" field.

Srv.-Based Inv. Ver. - Marked for all vendor records.

Relevant For Price Determ. (Vendor hierarchy) - Should be flagged for all vendor records liable for vendor hierarchy. At the moment is not used.

Shipping conditions
For ZVEN:

• 01 (Standard) - for Direct spend related vendors
• Blank for Indirect.

For ZINT: ZO (One Step) for intercompany accounts (with several exceptions provided by F2F team)

Purchasing Group - Key for a buyer or a group of buyers. Default Blank

Confirmation Control - Determines which confirmation categories are expected for a PO Should be populated with 'Z004' for all Direct spend related vendors. Blank for the rest.

Note!: When the vendor is opened for company code, it is automatically opened for plants under this company code. There are cases when currency or payment terms for one vendor code differ in different plants or for different company codes. This can be managed through opening plant level details.
If vendor has multiple currencies for one plant a new vendor should be created!

Go to Different Data:
Enter the Plant number (please see Appendix 11 – Locations and plants) and mark the Purchasing data check box.

In purchasing view enter:

• Order Currency
• Terms of Payment
• Incoterms
• Pricing Date Control
• GER-based inv. Verif.
• Acknowledgment reqd
• Automatic PO
• Srv.-Based Inv. Ver.
• Confirmation Control

Partner Functions

These fields define additional rights and responsibilities of each partner in a business transaction.

OA - Ordering address: usually is the same as SAP number we're creating. This address can also be set up under ZOAD account group. Please note that ZOAD account group maintains only the address used for placing purchase orders.

VN - Vendor is always defaulted to the SAP vendor number we're creating. This vendor number is usually used for placing Purchase Orders.

PI - if the vendor remittance address matches the main address then the invoicing party is the same as the vendor number we're creating.
If company's remittance address is different, it is created as a separate invoicing party ZINV and linked to the main vendor in the Partner Functions screen.
Please note, only ONE invoicing party can be populated on this screen. Before removing Invoicing party, make sure, that there are no open invoices.

Important!!! In case if a separate invoicing party ZINV is added and linked to the main ZVEN vendor, company code Data need be blocked for ZVEN account, as invoices will be processed through ZINV vendor.

Commodity Code

Commodity code - In the field of Value add commodity code. This is mandatory field and should have the same value for all company codes vendor is opened for. Using this field you can determine vendor type (Direct spend, Indirect spend non-PO, Indirect spend – PO). (List of commodity codes can be found in Appendix 7).

How to add Commodity code:

After adding Commodity Code go back to the main menu and save the record.

Inactivating a vendor

There are several cases when vendor inactivation might be necessary:

• Supplier has gone out of business;
• We are no longer in business with the supplier;
• Registration number change has taken place;
• Account is a duplicate.

There also might be cases when vendor needs to be blocked/marked for deletion only for specific company code or purchasing organization:

• Supplier has been incorrectly opened for P.Org.;
• Supplier has been opened for incorrect company code;
• Separate remit-to party has been added for the main account, and main account should cease to serve as invoicing party.

Note!: It is safe to put purchasing block after PI party has been updated in open PO's, but Deletion flag can only be put after every open item is cleared.

Note!: Please remember to inactivate Returns vendor as well. Create a ticket for DM RIGA Customer Master Team stating in the ticket replacement vendor account (in case of new creation), old vendor account, returns vendor account and original FD ticket.

Note that as per SWAP project, Toulouse and Mondovi sites are under responsibility of Lisbon AP and Provisioning Teams. Other sites are being operated here in Riga. Detailed list of SWAP affected CC can be found here.

Steps for the inactivation

After approval for inactivation of the vendor account has been received please follow the steps below. Please note that we cannot inactivate the account until all open items have been cleared.

1. Check for open items (Chapters 9.2-9.6 ):
   1. PO's (ME2L)
   2. PIR's (ME13)
   3. Contracts (ME3N)
   4. Invoices (FBL1N)
   5. WorkFlows (Sharepoint)
2. If there are no open items proceed with the inactivation as described in 9.7 Vendor inactivation (blocking and marking for deletion) and inform Provisioning and AP teams.
   
   
3. If there are open items please contact AP/ Provisioning/Data teams asking them to move or update open items.

In case replacement account has been created please use the template below: 

“Dears,

 New account #123456 NEW VENDOR NAME has been created in order to replace #654321 OLD VENDOR NAME.

 Dear Procurement team,

 Could you please move the open items [PO’s] to the #123456 NEW VENDOR NAME or, if not possible, update the PI party of the open PO’s from #654321 OLD VENDOR NAME to  #123456 NEW VENDOR NAME?

 Please let us know whether the PO’s have been moved or updated.

 Dear AP,

 Could you please move invoices, if needed from #654321 OLD VENDOR NAME to  #123456 NEW VENDOR NAME?

 Please let us know whether the invoices have been moved or will they remain on the old account until processed.”

           4. Based on the response from the teams please take the following actions:

1. 1. PO's are not moved and there are open invoices – apply purchasing block and deletion flag for specific company codes
   2. No PO's and there are open invoices – apply purchasing block and deletion flag for specific company codes
   3. PO's are not moved and there are no open invoices – make sure that PO's have been updated with the new PI party and apply purchasing block and posting block
   4. Non-PO supplier with open invoices – apply deletion flag for specific company codes

           5. In case you are left with some pending open items please

1. 1. For open PO's check whether they have been processed monthly
   2. For open Invoices check whether they have been processed based on Net due date

Check for open PIR's (ME13)

Info records can be seen using transaction ME13.

Open search function in Info Record field.

Use search option "Info Records for Vendor" and search by Vendor number.

If any records are returned by the system:

• If supplier is Raw Material/Packaging supplier please contact Material people from our Data Team and ask them to re-create the PIR's on the new account (if any).
• If supplier is Indirect spend no action is required, as these PIR's are created automatically by the system.

Check for open Contracts (ME3N)

After PIR check vendor should also be checked for active contracts. This can be done using transaction ME2L.
In order to quickly view the open contracts enter:

• Vendor number;
• Scope of list - Best;
• Validity Key date (usually today's date to see if any contracts are open for this day);

Select Chose button at the top, checkmark Contract and Sch.Agmt and execute the view:

In the following screen you will see all open contracts for this vendor at the moment of the date chosen with the exact contract number at the top left corner:

In case of open contracts, please contact our Team's material people team and ask them to arrange creation of a new contract on the new supplier and inactivation of old contract.

Check for open PO's (ME2L)

Open PO's can be located using transaction ME2L.

Purchase order is still open, if To be del. and/or To be inv. fields are not "0,00".

In order to see only open PO's, you can choose /DM_OPEN layout.

In case there are any open PO's please contact the procurement team and ask them to either move open PO's or update them with the PI party of the replacement vendor (if applicable):

• If PGr (Purchasing Group) is GEU or GNA contact Riga Provisioning Team by FD group: PTP Provisioning Riga
• If other PGr contact:
  • Responsible planner = PO creator.

If the open PO's are not going to be moved please:

• Make sure that the PO's have been updated to the PI party of the replacement account;
• Apply "Purchasing block". This will enable goods receipt, but will prevent new PO creation;
• Check regularly (monthly) whether the open items have been processed.

Note! In case provisioning needs to update some details afterwards the purchasing block can be temporary removed.

Check for open Invoices (FBL1N)

Use transaction FBL1N to check for open invoices.
Populate the number of the vendor and all company codes the vendor is open for.

Checkmark Open Items and all invoice types, to make sure that all open items are displayed.

In case you receive any return form the system it means that there are invoices pending payment. Here you can check the due date for the invoice as well.

In case there are any open invoices please contact AP team and ask them to move the invoices to the replacement account, if required. FD ticket should be created to AP Team for group: PtP AP Riga, but for Toulouse and Mondovi sites it should be PtP AP EMEA Team.

In case invoices could not be re-posted on the replacement account, please apply deletion flag for specific company code and check whether they have been cleared after the net due date.

Note! Payment runs are happening on Monday and Thursdays. This means that the invoice will be cleared on the first Monday or Thursday after the net due date.

Check for open Workflows (Sharepoint)

There might be some invoices not yet posted in SAP, but already has workflow initiated in SharePoint. Go to Accounts Payable SharePoint page here and go to "Invoices" section. 

Look for invoices based on vendor number.

In case you see any entries with invoice status other than "Completed" or "Duplicate Invoice" please check whether the invoice information matches the replacement account and inform AP team to post the invoice on the new vendor account, FD ticket should be created to AP Team for group: PtP AP Riga, for Toulouse and Mondovi sites it should be PtP AP EMEA Team, cc'd SSC Operator.

Vendor inactivation (blocking and marking for deletion)

In order to block vendor in the main menu select transaction code XK05 → hit enter →  enter vendor code →  Company code. In case of vendor needs to be deactivated in Purchasing area, Purchasing Org should be marked as well:

Alternatively this transaction can be accessed through transactions XK02 or XK03. After entering vendor account go to Extras → Block Data

Posting Block – prevents users from using company code data (e.g. posting invoices)

Purchasing Block – prevents users for using purchasing data (e.g. posting purchase orders)

In order to mark vendor for deletion select transaction code XK06 →  hit enter →  enter vendor code → Company code. In case of vendor needs to be deactivated in Purchasing area, Purchasing Org should be marked as well.

Alternatively this transaction can be accessed through transactions XK02 or XK03. After entering vendor account go to Extras → Deletion flags

Deletion flag – vendor is marked to be deleted. Note! This does not block vendor functions and it still can be used by other departments.

• When the whole vendor needs to be inactivated.
  • Go to Block Data (Transaction XK05 or Extras →  Block Data) and mark:
    • Posting block – for All company codes
    • Purchasing block – for All purchasing organizations
  • Go to Deletion Flags (Transaction XK06 or Extras →  Deletion Flags) and mark:
    • Deletion flags – All areas.

• When vendor needs to be inactivated only for company code:
  • Go to Block Data (Transaction XK05 or Extras →  Block Data) and mark:
    • Posting block – for All company codes
  • Go to Deletion Flags (Transaction XK06 or Extras →  Deletion Flags) and mark:
    • Deletion flags – for Selected company code.

Note! If vendor has been opened for several company codes this step needs to be done separately for each of the company.

• When vendor needs to be inactivated only for Purchasing organization:
  • Go to Block Data (Transaction XK05 or Extras →  Block Data) and mark:
    • Purchasing block – for All purchasing organizations
  • Go to Deletion Flags (Transaction XK06 or Extras →  Deletion Flags) and mark:
    • Deletion flags – for Selected Purchasing Organization.

 

Appendixes

Appendix 1 – IBAN structure

Please find the Bank Key to be used in red. For some countries bank key has not yet been determined, if in doubt please contact Payment Team or Edgars Bigacs.

★ Andorra (24) IBAN format: ADkk BBBB SSSS CCCC CCCC CCCC ::B = bank code, S = sort code, C = account No.

★ Austria (20) IBAN format: ATkk BBBB BCCC CCCC CCCC::B = bank code, C = account No.

★ Belgium (16) IBAN format: BEkk BBBC CCCC CCCC ::B = bank code, C = account No (the last 12 digits are used as an account).

★ Bosnia and Herzegovina (20) IBAN format: BAkk BBBS SSCC CCCC CCKK::B = bank code, S = sort code, C = account No., K = check digits 

★ Bulgaria (22) IBAN format BGkk BBBB SSSS DDCC CCCC CC::B = alphanumeric bank code, S = Branch (BAE) number, D = numeric account type, C = alphanumeric account No. digits

★ Croatia (21) IBAN format: HRkk BBBB BBBC CCCC CCCC C ::B = bank code, C = account No.

★ Cyprus (28) IBAN format: CYkk BBBS SSSS CCCC CCCC CCCC CCCC::B = bank code, S = sort code, C = account No.

★ Czech Republic (24) IBAN format: CZkk BBBB CCCC CCCC CCCC CCCC::B = bank code, C = account No.

★ Denmark (18) IBAN format: DKkk BBBB CCCC CCCC CC::B = bank code, C = account No.

★ Estonia (20) IBAN format: EEkk BBBB CCCC CCCC CCCK
::B = bank code, C = account No., K = check digit

★ Faroe Islands (18) IBAN format: FOkk BBBB CCCC CCCC CC::B = bank code., C = account No.

★ Finland (18) IBAN format: FIkk BBBB BBCC CCCC CK::B = bank code, branch number and account type, C = account No., K = check digit.

★ France (27) IBAN format: FRkk BBBB BGGG GGCC CCCC CCCC CKK::B = bank code, G = code guichet (branch), C = account No.

★ Germany (22) IBAN format: DEkk BBBB BBBB CCCC CCCC CC::B = sort code (BLZ), C = account No.

★ Gibraltar (23) IBAN format: GIkk BBBB CCCC CCCC CCCC CCC::B = first part of BIC, C = account No.

★ Greece (27) IBAN format: GRkk BBB BBBB CCCC CCCC CCCC CCCC :: B = bank code and branch number, C = account No.

★ Greenland (18) IBAN format: GLkk BBBB CCCC CCCC CC::B = bank code, C = account No.

★ Hungary (28) IBAN format: HUkk BBBB BBBC CCCC CCCC CCCC CCCC::B = bank code, C = account No.

★ Iceland (26) IBAN format: ISkk BBBB CCCC CCCC XXXX XXXX XX::B = bank code, C = account No., X = the account holder's unique ID number, issued by the Bureau of Statistics.

★ Republic of Ireland (22) IBAN format: IEkk AAAA BBBB BBCC CCCC CC::A = start of the SWIFT, B = bank code, C = account No.

★ Italy (27) IBAN format: ITkk ABBB BBCC CCCX XXXX XXXX XXX :: KK = is the CIN EU, A = CIN IT, B = is the ABI, C = is the CAB, X = account No.

★ Latvia (21) IBAN format: LVkk BBBB CCCC CCCC CCCC C::B = bank code, C = account No (which can include both letters and numbers).

★ Liechtenstein (21) IBAN format: LIkk BBBB BCCC CCCC CCCC C::B = bank code, C = account No.

★ Lithuania (20) IBAN format: LTkk BBBB BCCC CCCC CCCC::B = bank code, C = account No.

★ Luxembourg (20) IBAN format: LUkk BBBC CCCC CCCC CCCC::B = bank code, C = account No.

★ Republic of Macedonia (19) IBAN format: MKkk BBBC CCCC CCCC CKK::B = bank code, C = account No., K = check digits

★ Malta (31) IBAN format: MTkk BBBB SSSS SCCC CCCC CCCC CCCC CCC ::B = fist part of BIC, S = sort code, C = account No.

★ Monaco (27) IBAN format: MCkk BBBB BGGG GGCC CCCC CCCC CKK::B = bank code, G = code guichet (branch), C = account No., K = check digits

★ Morocco (24) IBAN format: MAkk BBBA AACC CCCC CCCC CCKK ::B= bank code, A= Area code, C = Account number, K = check digits

★ Netherlands (18) IBAN format: NLkk BBBB CCCC CCCC CC::B = bank code, C = account No.

★ Norway (15) IBAN format: NOkk BBBB CC CCCCC::B = bank code, C = account No.

★ Poland (28) IBAN format: PLkk BBBB BBBk CCCC CCCC CCCC CCCC :: B = bank code (1-3 institution ID, 4-7 branch), C = account No., k = check digits.

★ Portugal (25) IBAN format: PTkk BBBB BBBB CCCC CCCC CCCK K::B = bank code (1-4 bank, 5-8 branch; some banks use '0000' for digits 5-8), C = account No., K = check digits.

★ Romania (24) IBAN format: ROkk BBBB CCCC CCCC CCCC CCCC::B = bank code, C = account No.

★ San Marino (27) IBAN format: SMkk ABBB BBCC CCCX XXXX XXXX XXX::kk = is the CIN EU, A = CIN IT, B = is the ABI, C = is the CAB, X = account No.

★ Serbia (22) IBAN format: RSkk BBBC CCCC CCCC CCCC CC::B = bank code, C = account No.

★ Slovakia (24) IBAN format: SKkk BBBB CCCC CCCC CCCC CCCC::B = bank code, C = account No.

★ Slovenia (19) IBAN format: SIkk BB BBB CCCCCCCC KK::B = bank code (2 digits) and branch (3 digits), C = account No, K = check digits

★ Spain (24) IBAN format: ESkk BBBB GGGG KKCC CCCC CCCC::B = bank code, G=Branch/office number, K=Check digits, C = account No.

★ Sweden (24) IBAN format: SEkk BBBB CCCC CCCC CCCC CCCC::B = bank code, C = account No.

★ Switzerland (21) IBAN format: CHkk BBBB BCCC CCCC CCCC C::B = bank code, C = account No.

★ Turkey (26) IBAN format: TRkk BBBB BRCC CCCC CCCC CCCC CC::B = bank code, R = 0, C = bank branch and account No.

★ Tunisia (24) IBAN format: TNkk BBBB BCCC CCCC CCCC CCCC::B = bank code, C = account No.

★ United Kingdom (22) IBAN format: GBkk BBBB SSSS SSCC CCCC CC::B = alphabetical bank code, S = sort code (often a specific branch), C = account No.

Appendix 2 - European VAT identification number structure

Appendix 3 – Overview Standard Payment Terms

Appendix 4 - Overview Harmonized and approved Payment Terms

New payment term creation needs to be approved by Mario Bruins and

• Ken Sharp, Michael Adler, Tracy Ng and Davide Mina for Indirect Spend suppliers and Packaging.
• Jean-Pierre Demeunynck and Tracy Ng for Direct Spend suppliers.

Appendix 5 – SEPA countries

Below is the list of countries and territories or dependencies which are part of the Single Euro Payment Area (SEPA). The countries, territories and dependencies are recognized by their ISO codes to be used in BICs and IBANs as required by the SEPA schemes.

Appendix 6 - Vendor Master Data Setup Request (Checklist)

Check list and instructions how to use it can be found on G Drive:
https://drive.google.com/drive/folders/0Bz1L-UDgm5MEQjFOU2ZhWEpiS2c

Appendix 7 – Vendor Master Data Setup Request (Checklist – customer carrier)

Appendix 8 – Commodity codes

Appendix 9 – Incoterms 2

Appendix 10 – Country codes

Appendix 11 – Additional data check for vendor "Customer with a negative balance".

When vendor is created, go to Customer master data, use transaction code XD02. Enter customer number, company code:

Go to Control data. If customer number has been added in Control data (2^nd screen of setup) upon vendor creation, customer number will appear on this screen, if not add vendor code:

Appendix 12 – Change Vendor account group

Go to transaction code XK07, add a vendor number:

Hit Enter:

Hit Enter and add new account group:

You should receive Warning message about account group change:

Hit enter and add purchasing data, according to Work Instruction.
If previously this vendor was a non-PO vendor; don't forget to change commodity code.

Appendix 13 – Locations and plants

Appendix 14 – Process Specifics for Vendor Master

** given the possibility that the request might come from a different party - other than the Data Steward

 Appendix 15 – Locating correct Transportation Zone

When new vendors or customers are set up, a transportation zone (t-zone) needs to be assigned to its address master data. The only real need for the t-zone is to determine the proper route and transit time for outbound shipments to customers (they serve no similar purpose for inbound deliveries from vendors).

Since routes are not more specific than a day, as long as we can derive the correct number of transit days, the requirement is met. Consequently, we are now taking the approach of using existing t-zones wherever possible from other business partners who are located fairly close (within a few hours away).

Also important in determining the need for a new t-zone is to insure that the proper route determination is in place if the business partner is a customer.

Finding the correct t-zone

Criteria:

• Same country
• Within a few hours transportation time by road

Steps:

1. First identify what the vendor's t-zone would be under the original Project GO configuration rules.
2. Try to locate this t-zone among the existing ones using ZTZONE transaction or you can search (F4) on the t-zone field of the vendor master.
3. Find the existing t-zone code that is most similar to the desired code. For example, t-zone DE047 (DOEBELN GERMANY)is the desired code (FD ticket 964458), but it does not exist.

       4. Once you have identified a potential code, determine the actual distance between the cities of the t-zones. Google is helpful for that.

       5. Since Google indicates these two towns are less than an hour apart, DE048 is acceptable to use instead of setting up a new code for DE047. For vendors since there are no route implications, any existing t-zone within 12 hours should be acceptable                 as long as the country code is the same.

       6. In case no applicable t-zone cannot be located open a ticket to COE_SD group indicating:

1. 1. t-zone code;
   2. whether the code is required for vendor or customer;
   3. original requester;
   4. address;
   5. roles for which the vendor will be used.

Appendix 16 – Carrier calendar table

When new carrier vendors are set up, if they will deliver outbound goods, they need to be added to the carrier calendar table which defines the days of the week that the carrier can pick up goods at all applicable plants to be used to determine availability dates in sales orders.
Request:

• Carrier's available pick up days;
• Plant, from which the goods will be picked up.

Be sure you can translate pick-up days into the correct factory calendar code before entering a new record in the table.

• The t-code for maintaining the table is ZZ_DEL_DAT
• The table updated is ZTC2C_DEL_DATE

Using the t-code specified above, enter a new record in the table by Selecting New Entries. Enter the proper plant(s) applicable to this carrier. These could be a single plant or any/all plants for the company for which the vendor was established.

Refer to the chart below for plants by company:

The proper factory calendar code is determined by the country of the shipping plant and the carrier's available day(s) of the week as provided by the business. Select from the list below.

Changes/additions to factory calendars (including the setting of holidays by country for each year) are configuration changes which are transports from Dev to QE to PE. If these types of changes are required, please open a ticket for COE_SD.