Customer Features
In CMD context, the customer is an organization who are customers to Maersk. All the customer details are maintained in CMD application Postgres Database. The customers can be onboarded/maintained in CMD application via below 3 options:
Customer onboarding options in CMD Application
- CMD portal application
- Customer Ingest API (SAP-BOH Flag/ Maersk.com)
- Initial Data Load process (Used for any M&A / Integration Activities)
- Bulk Create (TBD)
Customer create Lifecycle in CMD Application
Below are the 7 steps of customer entity create life cycle in CMD application.
- Search Duplicate service
Before creating a customer, the customer 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 customer duplicate match rules.
Rule 1: Exact Country + Tax reference (without TAX type). This is used to identify match based on tax number
Rule 2: Exact Country + Reference Number + Reference Type . Used to identify match records based on Reference number and type and Country
Rule 3: Fuzzy trading name + Exact Country + Phone Number. Used to identify based on Fuzzy trading name, country and Phone number.
Rule 4: Fuzzy Organization Name + Exact Country + Fuzzy Address Line 1,2,3 + Fuzzy City + PoBox Code. Used to identify based on address details.
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 | Selected Columns | Match Type | DB Col Name | Existing Fileds in SearchDuplicateCustomer |
|---|---|---|---|---|---|---|---|
| 1 | Exact | Exact Country + Tax reference (without TAX type) | CTRYTax_Num | CountryTax Number | E | CTRY_ROWIDTAX_NUM | ISOCountryCodeTaxNo |
| 2 | Exact | Exact Country + Reference Number + Reference Type | CTRYEX_REF_NUM | CountryReference NumberReference Type Code | E | CTRY_ROWIDREF_NUMREF_TYPE_CD | ISOCountryCodeReferenceTypeNumberReferenceTypeCode |
| 3 | Fuzzy | Fuzzy trading name + Exact Country + Phone Number | Attribute1CTRYEX_PH_NUM_CUSTOrganization_Name | CountryPhone NumberParty Role Name | FEE | CTRY_ROWIDPH_NUMPARTY_RL_NM | ISOCountryCodeNumberCustomerTradingName |
| 4 | (Fuzzy | Fuzzy Address Line 1,2,3 | Address_Part1 | PO BoxHouse NumberStreetAddress Line2Address Line3 | F | PO_BOXHOUSE_NUMSTREET (StreetName)ADD_LN_2 (Building)ADD_LN_3 (Suburb) | PoBoxHouseNoStreetNameBuildingSuburb |
| Fuzzy City | Attribute1 | City/Town | F | CITY | City | ||
| Exact Country | CTRY | Country | E | CTRY_ROWID | ISOCountryCode | ||
| Fuzzy Organization Name | Organization_Name | Party Role Name | F | PARTY_RL_NM | CustomerTradingName | ||
| Fuzzy Postal Code | Postal_Area | Postal Code | F | PSTCD | PostalCode | ||
| With Match Score > 83 |
2. Field level validations
- The Ingest API’s will be the interface for any external applications including CMD portal to interact with Postgres Database to create/update the customer 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 Customer fields which will be validated as per below validations. (Will keep updating once the latest validations are finalized*).
| List of Customer Fields | Mandatory | Filed Type and its Size | Regular Expression |
|---|---|---|---|
| Trading Name | X | Text Field - 128 | pattern: ^[a-zA-Z0-9.,:;$%&+\]\[*\"( )'\\/^\\-]{3,128}$ |
| URL | Text Field - 292 | ||
| Country | X | Lookup Field | |
| City | X | Lookup Field | |
| Street name | Either Street Name or P.O. BOX is Mandatory | Text Field - 36 | pattern: ^[a-zA-Z0-9.,:;$%&+\]\[*\"( )'\\/^\\-]{0,36}$ |
| Street number | Text Field - 10 | pattern: ^[a-zA-Z0-9.,:;$%&+\]\[*\"( )'\\/^\\-]{0,10}$ | |
| Apartment, Suite, Floor, etc | Text Field - 36 | pattern: ^[a-zA-Z0-9.,:;$%&+\]\[*\"( )'\\/^\\-]{0,36}$ | |
| Postal code/Zip code | Depends on Country Generic rule | Text Field - 10 | pattern: ^[a-zA-Z0-9.,:;$%&+\]\[*\"( )'\\/^\\-]{0,10}$ |
| City sub-area/City District | Text Field - 36 | pattern: ^[a-zA-Z0-9.,:;$%&+\]\[*\"( )'\\/^\\-]{0,36}$ | |
| Region or Province | Depends on Country Generic rule | Lookup Field | |
| P.O. Box | Either Street Name or P.O. BOX is Mandatory | Text Field - 10 | pattern: ^[a-zA-Z0-9.,:;$%&+\]\[*\"( )'\\/^\\-]{0,10}$ |
| Customer Group Type | Drop down | ||
| Telephone number-- Landline -- Mobile | Depends on Country Generic rule and SCPI Rule | Text Field - 20 | pattern: ^[0-9]{1,20}$ |
| Tax Registration-- Country-- Tax registration type-- Tax registration number | Depends on Country Generic rule and SCPI Rule | Country - LookupTax Type - Drop downTax Number - Text Field - 120 | Tax Type: string_pattern: ^[A-Z0-9_]{1,50}$_Tax Number: stringpattern: ^[a-zA-Z0-9.,:;$%&+][*"( )'\/^\-]{1,50}$ |
| Customer Reference-- Customer reference type-- Customer reference value | Reference Type - Drop downReference Number - Text Field - 40 | ||
| Invoicing language | Drop down | string_pattern: ^[A-Z]{2,3}$_ | |
| BE Code | X | Text Field - Max length 8 chars |
3. Business Validation rules
As part of customer creation journey, the customer 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 customer creation journey will be stopped.
When customer is created in CMD application, there are country specific validation rules maintained in “MDM_SMDSMD.Generic_country_rules” table, which will be applied to customer data at IngestAPI level.
If any validation is failed the respective error will be thrown to user and customer creation journey will be stopped until the errors in data are fixed.
TBD: Attach rules or page for country rules.
4. Data Enrichment/Standardization process
- During customer 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 Customer Matches from BVD source based on Customer name + Country or Tax Number + Country and enrich customer information like customer core details, address, reference, tax, financial information, hierarchy (GUO|HQ) information, SIC information. All the available details from BVD source will be auto populated in the CMD UI so that user need not enter details to improve the data quality.
- Azure Maps Service - This Service is used to enrich the Customer address information. The address information provided by either user or auto populated will be given to Azure Maps 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.
- VIES Tax Service - This Service is used to validate the Tax Number data for the EU countries. Only the tax numbers belongs to European countries will be validated before it gets persisted in database.
- Phone Validation Service - This Service is used to Validate the given Customer phone number (tele and mobile number). The phone number is very important for communication with customer 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 customer so this data needs to be validated before it gets persisted.
5. Data persistence in Postgres Database
Once the data is validated and enriched based on above-mentioned rules and tools, the customer details will be persisted in Postgress Database tables mentioned in below confluence link. The below link provides complete details of data model.
CMD Modernization Data Model
6. Approval process use cases
Not all customers created by user/application will have 100% correct information in all cases. There are few cases where the customer created should go for approval process where Area Data Steward will review the data and either approve or reject it. Once the customer gets approved, the customer will become as active customer so that any business transactions can be done on such customers. If the customer gets rejected, such customers will not be maintained in the system.
Once the customer 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 ADS or Finance approval.
| List of workflows in Customer creation flow | ||
|---|---|---|
| Workflow Type | Workflow description | Workflow Approver |
| Duplicate | When Customer is identified as duplicate customer based on the duplicate match rules and still user want to create such duplicate customer. | Country specific Area Data Steward (ADS) |
| Address Override | When user is enter address and user is not preferring to use Address Doctor suggested address but he want use his own entered address. In some cases, when user use address which is suggested by Address Doctor still it will go for approval if address quality is low. | Country specific Area Data Steward (ADS) |
| VIES Tax Fail | When European Customer Tax number is not valid as per the VIES Tax Service. Note: It is for only EU Countries | Country specific Area Data Steward (ADS) |
| SCPI Tax Exempted | When user selects Customer group type as SCPI Tax Exempted. In this case user will not provide tax details so ADS need to review it whether it is valid customer or not. | Country specific Area Data Steward (ADS) |
| Internal Customer | When Customer is identified as Internal Customer based on Internal Customer logic explained below in this document. | Finance Approver |
| Recreate Customer | User can recreate the inactivated customer by clicking on Recreate button. When Customer is getting recreated against/from Inactive Customer. | Country specific Area Data Steward (ADS) |
| BVD Status | When BVD status of the Customer is either 'dissolved' or 'Bankruptcy' or 'In liquidation' then it should be reviewed by ADS. | Country specific Area Data Steward (ADS) |
| BVD Trading Name Change | When Customer Trading name is changed by user after retrieving customer details from BVD source. | Country specific Area Data Steward (ADS) |
7. Customer Publish process
Once the customer data becomes master copy/golden copy (by avoiding creating duplicate customer, data enrichment and standardization applied and data is reviewed by reviewer), such customers data needs to be published to downstream systems (around 20+ applications) on real time or near real time basis to carry out their business activities (mainly booking the shipments) on customers.
Once the customer is created or updated which is in active state or customer is approved by ADS or Finance, the customer becomes an active customer. Such customers, will be published to downstream systems listed in section () via below 3 options:
- EMP - The customer details will be published to customer EMP topic in JSON format and from where the consumer will pick and consume data.
- MQ - The customer details will be published to customer Message Queue in XML format and from where the consumer will pick and consume data.
- CMD SCV Replica - This is exact mirror of CMD data base from where few applications will consume data.
There is another option for downstream systems to consume the data from CMD directly hitting the WSQuery service end point by passing the customer code to the service which will retrieve complete snapshot of the customer details on real time basis.
Customer update Lifecycle in CMD Application
Below are the 10 steps of customer entity update life cycle in CMD application.
1. Search Duplicate service
Same logic as customer create scenario.
2. Field level validations
Same logic as customer create scenario.
3. Business Validation rules
Same logic as customer create scenario.
4. Data Enrichment/Standardization process
Same logic as customer create scenario.
5. Customer Data Changes
User can edit the different customer fields as per the business need and below are the list of different customer fields.
| Sl.No | Customer Data Section | Description |
|---|---|---|
| 1 | Customer Address fields | Any address field can be changed |
| 2 | Customer Tax | Tax number/Type can be changedNew Tax number can be addedExisting tax number can be removed |
| 3 | Customer Reference | Reference number/Type can be changedNew reference number can be addedExisting reference number can be removed |
| 4 | Customer Phone details/URL | Customer URL or Phone number can be changed. |
| 5 | Customer Segmentation | Customer Segmentation can be changedNew Segmentation type can be addedExisting Segmentation type can be removed |
| 6 | Customer Web Bill | Customer web bill can be changedNew Customer web bill can be addedExisting Customer web bill can be removed |
| 7 | Customer CBU | Customer CBU can be changedNew Customer CUB can be addedExisting Customer CBU can be removed |
| 8 | Customer status | Customer status can be changedNew Customer status can be addedExisting Customer status can be removed |
| 9 | Customer group type | Customer group type can be changedNew Customer group type can be addedExisting Customer group type can be removed |
| 10 | Customer invoicing language | Can be changed. |
6. Customer Status change
In CMD the customer can be in 3 different status which is Active, Suspended and Inactive. When the customer is created with all required details and if it is approved by ADS then it will be in Active state.
The customer can be suspended or can be inactivated because of various reasons. As per business requirement, customer can be marked as Suspension and Inactivation with one of the reason as mentioned in below list.
| Customer Status change from Active To | Customer Status Change Reason | Business Impact |
|---|---|---|
| Suspended | Fraud | Keep booking, bill manifestation, cargo release on hold. Consult with Front line agent, for further actions.Contracts filed on this code needs to be expired. |
| Suspended | Unethical Behavior | Keep booking, bill manifestation, cargo release on hold. Consult with Front line agent, for further actions.Freeze contract |
| Suspended | Booking Hold - Difficult collections | Keep booking, bill manifestation, cargo release on hold. Consult with Front line agent, for further actions.Freeze contract |
| Suspended | Dormant (no transaction) | Request Status Change through System. |
| Suspended | Company dissolved/no longer exist | Keep booking, bill manifestation, cargo release on hold. Consult with Front line agent, for further actions.Contracts filed on this code needs to be expired. |
| Suspended | Duplicate | Use the correct code / Master code, Merge with master code contract |
| Suspended | Legally Denied Party | Keep booking, bill manifestation, cargo release on hold. Consult with Front line agent, for further actions.Freeze contract |
| Suspended | Inactivate for LNS and FFW | |
| Suspended | Missing Or Invalid Mandatory Information | |
| Inactive | Fraud | |
| Inactive | Unethical Behavior | |
| Inactive | Booking Hold - Difficult collections | |
| Inactive | Dormant (no transaction) | |
| Inactive | Company dissolved/no longer exist | |
| Inactive | Duplicate | |
| Inactive | Legally Denied Party | |
| Inactive | Inactivate for LNS and FFW | |
| Inactive | Missing Or Invalid Mandatory Information |
When customer is in Active state, User is allowed to update the customer data.
When customer is Suspended - User is not allowed to update any customer data from CMD Portal, however the data can be changed from IngestAPI.
When customer is Inactive - User is not allowed to update any customer data from either CMD Portal or IngestAPI.
7. Approval process use cases
In case of customer update scenarios, below are few scenarios by which the customer approval workflow will be triggered for approval process.
| List of workflows in Customer Updation flow | ||
|---|---|---|
| Workflow Type | Workflow description | Workflow Approver (Country specific ) |
| Duplicate | When Customer is identified as duplicate customer based on the duplicate match rules and still user want to create such duplicate customer. | Country specific Area Data Steward (ADS) |
| Address Override | When user is trying to update address and user is not preferring to use Address Doctor suggested address but he want use his own entered address. In some cases, when user use address which is suggested by Address Doctor still it will go for approval if address quality is low. | Country specific Area Data Steward (ADS) |
| VIES Tax Fail | When European Customer Tax number is not valid as per the VIES Tax Service. Note: It is for only EU Countries | Country specific Area Data Steward (ADS) |
| SCPI Tax Exempted | When user selects Customer group type as SCPI Tax Exempted. In this case user will not provide tax details so ADS need to review it whether it is valid customer or not. | Country specific Area Data Steward (ADS) |
| Trading Name Change | When user modifies the Trading name of the customer. | Country specific Area Data Steward (ADS) |
| Tax Change | When user modifies the Tax value of the customer | Country specific Area Data Steward (ADS) |
| Reactivating Suspended Customer | When user tries to reactivate the suspended customer to active customer. | Country specific Area Data Steward (ADS) |
8. Relationship Update
User can edit customer data to add/remove/edit the relationships data.
| Entity 1 | Entity 2 | Relationship Type |
|---|---|---|
| Customer | Customer | Master Duplicate Relationship. When user want to link child customer as duplicate and parent as Master and Suspend duplicate child record, this relationship will be used. |
| Customer | Concern | Customer Concern Relationship with relationship type as IS_CONCRN and CONCRN_MEM.When user create new Concern, user should link at least one customer with relationship as IS_CONCRN. After concern is created user can link any customer to concern with CONCRN_MEM relationship. |
| Customer | CBU | Customer CBU Relationship with relationship type as Local CBU and Foreign CBU. User need to use any once CBU relationship when user associate any CBU to customer. |
| Customer | Contact | Customer Contact Relationship with relationship type as CUST_CONT and ON_BEHALF_OF.User can associate many contacts as CUST_CONT relationship with same customer.User can associate many contacts as ON_BEHALF_OF relationship with same customer. |
| Customer | Facility | User can associate multiple customer facilities to a customer with Customer Facility Relationship CUST_FACILITY relationship. When customer has multiple locations/addresses then use will update in this relationship. |
| Customer | Customer | When customer data is enriched from BVD source, BVD can provide customer GUO and HQ details but in CMD we maintain only BVD ids of GUO and HQ customers. When there is GUO and HQ customers found the relationships will be maintained in CMD as CUST_HQ_BVD and CUST_GUO_BVD. |
9. Data persistence in Postgres Database
Same logic as customer create scenario.
10. Customer Publish process
Same logic as customer create scenario.
Customer search functionality in CMD Application
CMD portal provide feature to search the customer based on various parameters or filter criteria.
1. Search By Trading Name and Address
User can search the customer with (Trading name and address) or only by address also.
2. Search by References
User can also search with any unique code or with any reference value.
| By Code | Customer Code (Fact/CMD Code) |
|---|---|
| Customer Alternate code ( SCV Code) | |
| Customer BE Code | |
| Customer BPMA Code | |
| By Tax Reference | Tax Value/number |
| By Customer Reference | Reference Type + Reference value |
Overall Customer lifecycle in CMD
External Services used
- BVD Service
- VIES Validation service
- Phone number validation service
- Email validation service
Roles Required for Customer Functionality
Below are the roles required to create/edit the customer details in CMD Portal. The role name and role functionality is explained in below table.
| Role Name | Role Functionality |
|---|---|
| smds_CMDAccountGroupManager | |
| smds_CMDConcernCodeManager | |
| smds_CMDDataQualityAssurance | |
| smds_CMDGlobalBusinessAdministrator | |
| smds_CMDHierarchyManager | |
| smds_CMDReadOnly | |
| smds_CMDSegmentationManager | |
| CMDWebBLManager | |
| CMDVipRole | |
| CMDFinance | |
| CMDOnBehalfOfRole | |
| Smds_CMDCustFacilityManager |
Internal/External customer identification Logic
The customers in CMD can be categorized as Internal or External customers. Customers which will do business internal to Maersk are called Internal customer and which are external to Maersk are called external customers. When user create a customer, below logic will be executed and decided whether the customer needs to be marked as Internal or external.
- Compare newly creating customer tax number with existing internal customers tax numbers, if match found then newly created customer will be marked as Internal customer.
- Compare newly creating customer trading name with existing internal customers trading name, if match fuzzy match % is more than 80% then newly created customer will be marked as Internal customer.
- Compare newly creating customer trading name with existing GEMS customer data (in GEMS_CUST_DTLS table), if match fuzzy match % is more than 80% then newly created customer will be marked as Internal customer.
- Compare newly creating customer trading name with key words from MDM_INFP_SMDSMD.CUST_NAME_KEYWORDS table, if match fuzzy match % is more than 80% then newly created customer will be marked as Internal customer.
SCPI & Non-SCPI Customers
In CMD user can create below customer group types in CMD.
| Customer | Description |
|---|---|
| SCPI | SCPI customer are customers which should have minimum mandatory information (MMI) such as Customer with contact email id, Customer level tax information and Customer level phone number information. MMI information is based on country specific rules maintained in MDM_INFP_SMDSMD.SCPI_COUNTRY_RULES table.SCPI customer are the actual customer with all data with which Maersk can do business. |
| Non-SCPI | These are customers which will pass generic country rules and field validations before it gets created and not necessarily follow the SCPI rules. |
| SCPI Tax Exempted | There are SCPI customers with minus of Customer level tax information ie. SCPI-Tax. |
NMB(No More Business)/BOH(Booking on Hold) Functionality
When there is billing issues and customer is not paying the payments properly then we will stop doing business with such customers temporarily. SAP system will update customer with BOH(Booking on Hold) which will flow from SAP ECC to CMD.
- SAP ECC system will own the BOH status and BOH status update on a customer will always be initiated from SAP ECC system.
- CMD will consume these updates received from SAP ECC and CMD will suspend such customers with reason as “Booking Hold - Difficult collections” and also updates the NMB/BOH flag.
- CMD system will not be allowed to reactivate any customer having NMB/BOH flag set by SAP ECC, It can only be reactivated once SAP ECC initiates lifting NMB/BOH flag.