Vendor Functional Details

A vendor is a person or company that sells goods or services for a profit. They can operate in a business-to-consumer (B2C) or business-to-business (B2B) environment. In B2B, vendors are often known as suppliers.

Examples of vendors

A manufacturer in the pharmaceutical industry uses raw materials to produce items like cough syrup, antibiotics and pain medicine. The manufacturer distributes these goods to retailers such as retail pharmacies and drugstores. The retailers then sell the medicine to consumers, who are the end-users.

In Maersk context, the Vendor is an organization who are providing services to Maersk. All the Vendor details are maintained in Vendor application Postgres Database. The Vendors can be onboarded/maintained in Vendor MDM application via below 3 options:

Vendor onboarding options in Vendor MDM Application

1. Vendor portal application
2. Vendor Self Service Portal (TBD)
3. Bulk Create

The Vendor data is mainly consumed by SAP ECC and SAP TMS applications. These systems are invoicing/billing and payment systems which are very important systems.

Vendor create Life cycle in Vendor MDM Application

The Vendor entity can be created from Vendor Portal, Vendor Self Service Portal and through bulk create options as mentioned above.

1. Login to the Portal application with right access privileges to create a vendor entity.
2. Create new Vendor by providing general data, address information in local language, tax details, Bank Details, Company Codes and Purchasing Organizations.
3. Submit the request to persist the Vendor entity in database.
4. After submitting the request, system will check for duplicate vendors exist in the system already or not based on Vendor name, City, County. If duplicate exist systems will show the warning message to user else it will proceed for vendor creation.
5. System will also check for all business validations and country specific validation rules to validate the Vendor data.
6. Based on the certain conditions, the request will go for approval process to get it reviewed and approved by the respective approvers.
7. Until it is approved, the vendor entity will be in pending state and it will not get published.
8. Once it is approved, the vendor entity becomes active and it will get published to downstream systems.

Search Duplicate service

Before creating a vendor, the vendor will be searched to find such similar record exist in the systems or not. If any such similar record found, the system will display to the user to use. If no record found or user want to still create another record he can continue doing it.

Similar customer will be identified as duplicate based on the below vendor duplicate match rules.

Rule 1: Fuzzy Organization name + Exact Country + Exact City. Used to identify based on Fuzzy Organization name, country and City.

Below table provide details about match rules used in current system. Provides details like match type, match columns and Database column names and fields used in match rules.

Match Rule #	Match Type	Rule Description	Match Columns	Match Type	DB Col Name
1	Fuzzy	Fuzzy Organization NameExact Country Exact City	FEE

Field level validations

• The Ingest API’s will be the interface for any external applications including Vendor portal to interact with Postgres Database to create/update the Vendor data.
• The input payload fields (of Ingest API) values will be validated to make sure the all fields data is formatted as per expectation.
• Below are the list of Vendor fields which will be validated as per below validations. (Will keep updating once the latest validations are finalized*).

<List of Vendor Fields here>

Business Validation rules

As part of vendor creation journey, the vendor data should comply some country specific and business specific validations. If any such rule is violated the respective error message needs to be displayed and vendor creation journey will be stopped.

When vendor is created in Vendor application, there are country specific validation rules maintained in “Generic_country_rules” table, which will be applied to vendor data at IngestAPI level.

If any validation is failed the respective error will be thrown to user and vendor creation journey will be stopped until the errors in data are fixed.

TBD: Attach rules or page for country rules.

Data Enrichment/Standardization process

During Vendor create process, below third party services will be used to standardize or enrich the customer data;

• BVD Service - This Service is used to find the Vendor Matches from BVD source based on Vendor name + Country or Tax Number + Country and enrich vendor information like vendor core details, address, reference, tax, financial information. All the available details from BVD source will be auto populated in the Vendor Portal UI so that user need not enter details to improve the data quality.
• Address Data Enrichment Service - This Service is used to enrich the vendor address information. The address information provided by either user or auto populated will be given to any address enrichment service as input. Based on the input address the address provided the address will be enriched and also standardized address information will be returned as output. It can provided more than one address also based on the input. User will pick the relevant address in case multiple addresses.
• Tax Number Validation Service - This Service is used to validate the Tax Number data for all countries. Only the tax numbers validated will get persisted in database.
• Phone Validation Service - This Service is used to Validate the given Vendor phone number (tele and mobile number). The phone number is very important for communication with vendor so this data needs to be validated before it gets persisted.
• Email Validation service - This service is used to Validate the given email address. The email number is also very important for communication with vendor so this data needs to be validated before it gets persisted.

Data persistence in Postgres Database

Once the data is validated and enriched based on above-mentioned rules and tools, the vendor details will be persisted in Postgress Database tables mentioned in below confluence link. The below link provides complete details of data model.

Approval process use cases

Not all Vendors created by user/application will have 100% correct information in all cases. There are few cases where the Vendor created should go for approval process where Area Data Steward will review the data and either approve or reject it. Once the vendor gets approved, the vendor will become as active vendor so that these vendors can be published to consumes. If the vendor gets rejected, such vendor will not be maintained in the system.

Once the vendor is created in Postgres Database, the workflow will be triggered. Below are the different conditions on which the Workflows will get generated which will go for Local, Country approvers, Central approval, WTCS Approver, or Support team approval.

List of workflows in Vendor creation flow
Workflow Type	Workflow description	Workflow Approver
Local Approval	Every vendor need to get through the local approval process to get created in the system.All the Creation/Amendments will be submitted to Local Approver(except auto-approved fields)	Local ApproverEx: VNDR_ML_IN
Country Approval	Wherever the Requestor amending the other country(s) vendors whichis not mapped to their role in SMDS, It will flow to Country Approveralong with Local Approver. It is mandatory that both Local & CountryApprover should be approving the Vendor Request in SMDS VMsystem.	Country Approver Ex: ML_IN_APPROVER
Central Approver	When user try to create vendor and which is duplicate vendor then this workflow will get generated. For both local and foreign vendor request if it is duplicate in SMDSthen central approver takes decision to approve or reject	Ex: ML_CENTER
WTCS Approver	When the creating Vendor is blocklist then only this workflow will get generated.Approver for Denied party vendor or bank keys	Ex: WTCS_REVIEWER

Vendor Publish process

Once the vendor data becomes master copy/golden copy (by avoiding creating duplicate vendor, data enrichment and standardization applied and data is reviewed by reviewer), such vendor data needs to be published to downstream systems (SAP ECC & SAP TMS applications) on real time or near real time basis to carry out their business activities (mainly invoicing and payments) to vendor.

Once the vendor is created or updated which is in active state or vendor is approved by respective approvers, the vendor becomes an active vendor . Such vendor, will be published to downstream systems as mentioned above via below 3 options:

1. EMP - The vendor details will be published to customer EMP topic in JSON format and from where the consumer will pick and consume data.
2. MQ - The vendor details will be published to vendor Message Queue in XML format and from where the consumer will pick and consume data.
3. Replica DB- This is exact mirror of Vendor data base from where few applications will consume data.

Vendor update Life cycle in SMDS Vendor Application

Below are the 10 steps of vendor entity update life cycle in Vendor application.

1. Search Duplicate service

Same logic as vendor create scenario.

1. Field level validations

Same logic as vendor create scenario.

1. Business Validation rules

Same logic as vendor create scenario.

1. Data Enrichment/Standardization process

Same logic as vendor create scenario.

1. Vendor Data Changes

User can edit the different vendor fields as per the business need and below are the list of different vendor fields.

Sl.No	Vendor Data Section	Description
1	Vendor General Data
2	External/Alter Identifiers
3	Tax Number Information
4	Alias Names
5	Vendor Bank Account Details
6	Customer Information
7	Business Unit Information Details
8	Purchasing Organization Details
9	Vendor Relationships (VNDR_VNDR_FSCL, CUST_VNDR, VNDR_BSNS_UNIT_ENTY)
10	Vendor Contact Information
11	Vendor BU Relationship Contact Details

Vendor Status change

In Vendor domain, the vendor can be in 3 different status which is Active, Pending and Blocked. When the vendor is created with all required details and if it is approved by respective then it will be in Active state.

The vendor can be in pending state during the approval process. Until unless all approvers approve the vendor create/update request the vendor will be in pending state.

The vendor can be in blocked state if business user explicitly block it from UI portal because of various reasons.

Customer Status change from Active To	Customer Status Change Reason	Business Impact
Pending	When new vendor is created and went for approval processWhen existing vendor is updated	Business users cant update pending vendor entityDownstream systems can not consume pending vendors
Blocked

When vendor is in Active state, User is allowed to update the vendor data.

When vendor is Pending- User is not allowed to update any vendor data from Vendor Portal.

When vendor is Blocked- User is allowed to remove the blocked state from Vendor Portal.

Vendor Master Deletion/Deactivation/Block

Vendor Master System allows marking an existing Vendor Master for deletion in the system. It enables the users to mark the existing Vendor for deletion at Central Level, Company Code level and Purchasing Organisation level.

The vendor can be blocked using the SMDS ”Block/Deletion Vendor master record”. The vendor details can be updated according to the Country.

Company Code Level Block: All Company codes - Specifies whether posting is allowed for this vendor master record for all company codes. Based on Locations request, GSC users check the box if vendor should be blocked for posting in all company codes. Selected Company code – Specifies whether vendor is blocked for posting in the specified company code. Based on Locations request, GSC users check the box if vendor should be blocked for posting in specified company code.

Purchase Organization Block: All Purchasing organizations - Specifies whether purchasing order processing is blocked for this vendor master record for all purchasing organizations. GSC users check the box based on locations request, if vendor should be blocked for order processing in all purchasing organizations. Selected Purchasing organization - Indicates whether vendor is blocked for order processing in the specified purchasing organization. GSC users check the box if vendor should be blocked for order processing in selected purchasing organization based on Location request.

Central Block for Vendor Master If vendor need to be deactivated fully from business side, respective Business users need to ensure there are NO open transactions in vendor ledger & vendor is not used by other business globally (it can be identified based on Company Code & POrg extended), post which business users shall send the request to SMDS Users to deactivate the vendor (overall or to a specific Company Code or POrg level) & no need for any specific pre-approvals in this case.

Vendors not used for 15 months: Blocking of Vendor Master which is not used for last 15 months (as listed below) will be blocked by SMDS [or] MDG-S Vendor Master BPO Team globally & this process followed as per the GRC Guidelines. (Policy)

• No transactions in Vendor books for last 15 months
• No Open Balance in Vendor Ledger (as on date at blocking the vendor)
• No Purchase Orders (PO) Created in last 15 Months (does not include if any open POs which created before 15 months

Post validation of above listed steps, Vendor Master BPO team to deactivate the vendor master in system SMDS.

Vendor search functionality in Vendor Application

Vendor portal provide feature to search the vendor based on various parameters or filter criteria.

1. Search By Vendor Name, Vendor Code ……

User can search the vendor with (Vendor name and address) or only by address also.

1. Search by References

User can also search with any unique code or with any reference value.

By Code
By Vendor Name
By Country

Overall Vendor lifecycle in OH

External Services used

1. BVD Service
2. VIES Validation service
3. Phone number validation service
4. Email validation service

Roles Required for Vendor Functionality

Below are the roles required to create/edit the vendor details in Vendor Portal. The role name and role functionality is explained in below table.

Role Name	Role Functionality

Vendors Account Group

A vendor master data record consists of three account groups

Inter-company Vendors (ZICV): Used for APMM companies that are also vendors including Container business companies, APMM non-container business companies and Joint Ventures. If vendor identified as ZICV, it is mandatory to update the “Trading Partner” code.

The following fields are mandatory for inter-company vendors: • Trading Partner • I/C Activity

Strategic External Vendors (ZEXS): Strategic External Vendors and non-APMM companies including trucks and intermodal parties. The vendor details are not replicated in Self Service Procurement system. This category is to be used for vendors providing recurrent services.

Non-Strategic External Vendors (ZEXV): Non-Strategic External Vendors and non-APMM companies whose details are to be replicated in the Self-Service Procurement system. This category is to be used for vendors providing services sporadically.

Vendor Number: Will be generated from SMDS / MDG-S based on “Vendor Account Group” category: ZICV - Starts with 1 to 999999 ZEXS – Starts with 1000000-3999999 ZEXV – Starts with 4000000-6999999