Customer Facility Functionality
In CMD context Customer facility is a location where the shipping materials will be stored. In CMD application we will only maintain customer facilities not commercial and operational facility. Customer facility can be associated with one or more customers with customer-facility relationship. In CMD application Customer facility entity can be created, updated, Inactivate and can be associated with customers.
Customer Facility onboarding options in CMD Application
- CMD portal application
- SSDO/ HSM / SSIB applications via Customer Facility Ingest API
- Bulk Create (Q1 2025)
Customer Facility 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 Facility, the customer Facility 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 Facility will be identified as duplicate based on the below customer Facility duplicate match rules.
Rule 1: Facility Name (Exact match) + Country (Exact match) + City (Exact Match) + State (Exact match) + Pin code (Exact match) + Street Name (Near match - field level match at 85%) + Street Number (Exact match)
Rule 2: Facility Name (Exact match) + Country (Exact match) + City (Exact match) + Street Name (Near match - field level match at 85%)
- 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 Facility fields which will be validated as per below validations.
| List of Customer Fields | Mandatory | Filed Type and its Size | Regular Expression |
|---|---|---|---|
| Customer Facility Name | X | Text Field - 128 | pattern: ^[a-zA-Z0-9-,*'/()&+ ]{3,128}$ |
| 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 | X | 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}$ |
3. Business Validation rules
As part of customer Facility creation journey, the customer Facility 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 Facility creation journey will be stopped.
When customer Facility is created in CMD application, there are country specific validation rules maintained in “MDM_SMDSMD.CMD_Generic_Country_Rules” table, which will be applied to customer Facility data at IngestAPI level.
If any validation is failed the respective error will be thrown to user and customer Facility 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 Facility create process, below third party services will be used to standardize or enrich the customer Facility data;
- Azure Maps Service - This Service is used to enrich the Customer Facility address information. The address information provided by user will be given to Azure Maps as input. Based on the input 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.
5. Data persistence in Postgres Database
Once the data is validated and enriched based on above-mentioned rules and tools, the customer Facility 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
As of now there is no Workflow process involved in Customer Facility Journey. Once it is introduced then will update this info.
7. Customer Facility Publish process
Once the customer Facility data becomes master copy/golden copy (by avoiding creating duplicate customer Facility , data enrichment and standardization applied and data is reviewed by reviewer), such customer Facilities data needs to be published to downstream systems (around 5+ applications) on real time or near real time basis to carry out their business activities (mainly booking the shipments) on customer Facilities.
Once the customer Facility is created or updated which is in active state, Such customer Facilities, will be published to downstream systems listed in section () via below 3 options:
- EMP - The customer Facility details will be published to customer Facility EMP topic in JSON format and from where the consumer will pick and consume data.
- MQ - The customer details will be published to customer Facility 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.
Customer Facility update Lifecycle in CMD Application
Below are the 10 steps of customer Facility entity update life cycle in CMD application.
- Search Duplicate service
Same logic as customer Facility create scenario.
- Field level validations
Same logic as customer Facility create scenario.
- Business Validation rules
Same logic as customer Facility create scenario.
- Data Enrichment/Standardization process
Same logic as customer Facility create scenario.
- Customer Facility Data Changes
User can edit the different customer Facility fields as per the business need and below are the list of different customer Facility fields.
| S.NO | Customer Facility Data Section | Description |
|---|---|---|
| 1 | Customer Facility Name | Customer Facility Name can be changed |
| 2 | Customer Address fields | Any address field can be changed |
| 3 | Customer Facility status | Customer Facility status can be changed |
- Customer Facility Status change
In CMD the customer Facility can be in 2 different status which is Active and Inactive. When the customer Facility is created with all required details then it will be in Active state.
When customer Facility is in Active state, User is allowed to update the customer Facility data.
When customer is Inactive - User is not allowed to update any customer Facility data from either CMD Portal or IngestAPI.
- Approval process use cases
As of now there is no Workflow process involved in Customer Facility Journey. Once it is introduced then will update this info.
- Relationship Update
User can edit customer Facility data to add/remove/edit the relationships data.
| Entity 1 | Entity 2 | Relationship Type |
|---|---|---|
| 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. |
- Data persistence in Postgres Database
Same logic as customer Facility create scenario.
10. Customer Publish process
Same logic as customer Facility create scenario.
Customer Facility search functionality in CMD Application
CMD portal provide feature to search the customer Facility based on various parameters or filter criteria.
- Search By Facility Name and Address
User can search the customer Facility with (Facility name and address) or only by address also.
- Search by References
User can also search with any unique code or with any reference value.
| By Code | Facility Code (Fact/CMD Code) |
|---|---|
| Facility Alternate code ( SCV Code) |
Overall Customer Facility lifecycle in CMD
External Services used
1. Azure Maps
Roles Required for Customer Facility Functionality
Below are the roles required to create/edit the customer Facility details in CMD Portal. The role name and role functionality is explained in below table.
| Role Name | Role Functionality |
|---|---|
| CMD_UPDATER | User can create/Update Customer Facility but cannot Inactivate the Customer Facility. |
| CMDCUSTFACILITYMANAGER | User can perform all actions on Customer Facility including Customer Facility Inactivation. |
| ADS Roles | User can perform all actions on Customer Facility including Customer Facility Inactivation. |