As is DAMCO Systems (CMD Scope)
The below diagram shows the as is existing on-prem CMD & LnS system integration and the customer and contact data flow from CMD to DMDM system.
Concern Types maintained in DAMCO
Group Concern - Is a legal entity representing a conglomerate of companies (or divisions / independent business units) involved in more than one industry / Brand and normally spread across multiple locations.
Company Concern - Is an independent business unit representing a single brand / product line normally spread across multiple locations.
Regional Customer - is a group of customers across several countries within a Company Concern which represents the regional company’s structure. A Regional Customer can-not exist without being assigned to a Company Concern.
Creation of Group Concerns and Company concerns can only be done by the responsible Global Account Manager.
A standard user can also request linking a customer record to a Group Concern or Company concern but the relationship must be approved by the Global Account Manager.
Locations:
- In L&S MDM application, an address is referred to as a “location”, which is linked to a customer. A location can be linked to several customers.
- A customer must as a minimum have a main address entered, but alternate addresses can also be created at the organization level.
- Standalone Location feature is present in MDM which add IATA code to Location.
- IATA details (airport name, airport code and airport status) will be sent to downstream applications.
- There is a validation for unique IATA site code relationships.
- Duplicate IATA site code relationships will create import error in MORE downstream application.
- Missing validation error is there when same city and site code combination will be used in customer and standalone locations.
Below is the Required Data in MDM for MODS Interface
| Field | Requirement |
|---|---|
| MODS BE Code(BE – Business Entity) | Used in MODS as a unique code of the organisation. Maximum of 8 alphanumeric characters - A-Z 0-9 - with no space. Special characters - &*(),-/+ - are no longer allowed.a.Once a BE Code is created, it cannot be amended or removed.b.A BE Code can only be used once in one country. An inactive BE code cannot be used again on new/existing organisation. |
| Street Name | Maximum of 36 characters, which include A-Z 0-9 &*(),-/+. |
| MODS Site Code | This is the Site Code in MODS. It is unique per Country and per City Code.Maximum of 3 characters, which include A-Z 0-9 &*(),-/+ with no space. |
| MODS BE Function | Maximum of 5 alphanumeric characters - A-Z 0-9 - with no space. |
| Alt Zip City | For non-postal code countries, Alt Zip city must not be blank. |
Integration – Customer Lifecycle Management in DAMCO
Customers with few suspended reasons in CMD will remain Active in DAMCO (below diagram)
Customer with few suspended reasons in CMD will remain Inactive in DAMCO (below diagram)
Activities performed in DAMCO system which need to be moved to CMD
- Assign and publish all GEO data elements (MessageId, CorrelationId, SharedCodeIndicator, AltZipCity, PostalCodeLocation,CountryRKSTCode, CountryRKTSCode, CountryGeoId, CityRKSTCode, CityRKTSCode) in CMD data.
- Assign BE Function code. By default in DAMCO have HQ , user can change it to VDR/any value . In case multiple BE function are needed user can add multiple alternate locations with Customer and can link distinct BE Function.
- Assign MODSSiteCode. Every location has site code. This is 3 characters code which is generated automatically at L&S end when we have new location created or city details corresponding to location changes. This is an attribute linked to locations and not location itself. For instance MODS/MORE identifies a location with combination of CountryCode+CityCode+SiteCode(3 characters code).
- Assign LocationSCVNumber and LocationFACTCode
- Assign IATA code
- Assign MODSBECode, DunsNumber, Segmentation, Vertical etc.
- Alternate Location - Does CMD Portal has got Functionality to create Alternation location for Customer? What UI changes are required to Accommodate Alternate location creation Facilities in CMD needs to be checked.
- Need to sync segmentation data from DAMCO to CMD including REF data
- Create/update/assign and publish of DEPARTMENT - Not required
- Create/update/assign and publish of CONCERN - Same as what we have in CMD
- Create/update/assign and publish of FACILITY/LOCATION. LNS MDM does not use this word Facilities ,instead they call location or Alt location mapped with Customer, site codes are not clearly demarcated as facilities like ops fac or customer facilities ,although all are mapped with customer - Few changes are required in this area and we need check how this functionality needs to be implemented in CMD.
- There are Customer facilities created in CMD and sent to all downstream of CMD , now with decom of LNS , how will LNS downstreams will take these facilities or how do we make sure if an alt location/Facility created for LNS MDM downstream not to be sent to CMD Downstreams and Vice versa.
- Big challenge on how to merge/distinguish Facilities as they in LNS MDM , there are different facility type and they don’t have clear demarcation of which facility is Ops and which facilities is Customer but initial observation says 90 percent of facilities are linked with Customer only . How we need to resolve the challenge of Facilities. Do we need a new alt code to distint facilities created for LNS MDM and other Customer facilities consumers
- Publish of MASTER_DUP relationship message as separate message
- Publish of PERSON entity in DAMCO format
- Publish of RELATIONSHIP (all type of relationships, need to confirm) message in DAMCO format.
- Publish of STDLOCATION entity in DAMCO format
DAMCO Consumers:
MODS – Maersk Operational Documentation System. Core L&S Supply Chain Management application system handling operational activities.
MORE – MODS Realtime Extract. L&S applications’ data hub. Data Source : 90%+ of data is from MODS; others are from Kewill, Docman, Carrier Booking, Carriers, EDI, Shipper, MDM.
FACT – Financial SAP application for SCM
TMFF(KEWILL/BLUJAY) – Transport Management for Forwarders. An off-the-shelf Freight Forwarding operational application covering booking, eSI through INTTRA, customs filing through MnA, job costing and invoicing through FACT.
NSCP MDM – New Supply Chain Platform Master Data Management. MDM system that provides all master data needs for NSCP Subscribers.
In-Scope entities and entity functionality for L&S Decom project
| Entity | In Scope? | Data Migration? | Functionality Migration? | What data need to migrate? | What Functionality need to migrate |
|---|---|---|---|---|---|
| Customer | Y | Y | Y | 36K extended BE codes where BE code and Fact code is different between CMD and DMDM.Master and child BE code- Where one BE codes linked to another set of BE codes.Postal code and Alt zip code interfaced logic- In DMDM side, if postal code is blank city name is being mapped under altzipcode name.BE Function code functionality needs to be migrated to CMD | |
| Contact | Y | ? | N | ||
| Concern | Y | Y | N | ||
| Department | N | N | N | ||
| Person | ? | ? | ? | ||
| Loaction | Y | Y | Y | ||
| Master_Dup | ? | ? | ? | ||
| Relationships | ? | ? | ? | ||
| STDLOcation | Y | Y | Y | ||
| Country | Y | Y | Y | This is already integrated so the data between GEO - DAMCO is in sync. Nothing needs to be done here as part of the decom | |
| State | Y | Y | Y | ||
| City | Y | Y | Y | ||
| PostalCode | Y | Y | Y |
Open Questions:
- Customer Group Type Mapping between CMD and LNS, how to encode it for DAMCO from CMD.
- If CMD sends SCPI or SCPI Tax Exempted then in LNS it will be saved as Invoice
- for Non SCPI -> it will be saved as Standard
- Customer status mapping between CMD and LNS and also down the line if CMD sends multiple suspension reason then what we need to send to OESB? Need business inputs over here
- There is Parking lot concept for Master duplicate relationship in DAMCO, how to accommodate it in CMD?
- How to populate Customer Email for DAMCO publish?
- In customer message MessageId, CorrelationId, SharedCodeIndicator, AltZipCity, PostalCodeLocation,CountryRKSTCode, CountryRKTSCode, CountryGeoId, CityRKSTCode, CityRKTSCode, BEFunction, MODSSiteCode, LocationSCVNumber, LocationFACTCode, MODSBECode, DunsNumber, MasterSCVNumber, Sales (AccountManager, Segmentation,Vertical) how to get these fields?
- What is Department and from where the department data will be feed in DMDM? How Department is associated with other entities like Customer, Contact, Concern ect?
- Answer: Its separate entity created in DAMCO only, this is not required to consider for decom scope.
- How to demarcate Ops and Customer Facilities available in DAMCO?
- DAMCO maintain regional and group concerns but CMD maintain only Company concerns. What should we do with DAMCO regional and group concerns?
- For Common customers between CMD and LNS for which CMD and SCV codes are different but they are connected via BE code. For all such customers, do we need to migrate all code from DAMCO to CMD?
Here in below example we can see CMD codes and LNS codes are different for the same customer and post LNS decommission, how we are going to handle updates on these codes at LNS downstream systems and which codes we are going to use forward?
Example:
| BECODE | DAMCOSCVCODE | DAMCOFACTCODE | CMDSCVCODE | CMDFACTCODE | MASTERBECODE |
|---|---|---|---|---|---|
| LAUFERGR | 33100861403 | US00861403 | 33100557832 | US00557832 | LAUFERGR |
6. During CMD LNS Integration. If there are master and its duplicates present in LNS system and we only considered the master customer as valid customer in CMD and if it is not present at CMD then we load or else we extended BE code to existing customer.
Currently when any update happens on that Master customer at CMD, then at LNS the same update use to happen on Master customer and also on all its duplicate customers.
So now post LNS decommission how we are going to handle this ??
Example:
7. Any approval process for alternate location creates and edits?
8. How concern data is maintained in DMDM? DMDM is not getting concern data from CMD?
Answer: Its created in DAMCO also as in CMD but how this concern is consolidated in CMD is not known.
Additional Questions:
- What is Location and from where the Location data will be feed in DMDM? How Location is associated with other entities like Customer, Contact, Concern etc?
- Answer: Location/facility created in DAMCO also as in CMD but how this location is consolidated in CMD is not known.
- What is MASTER_DUP message? and how this data gets into DMDM and how it gets published?
- Answer: Its created from Customer publish message from CMD.
- What is Person and from where the person data will be feed in DMDM? How Person is associated with other entities like Customer, Contact, Concern ect?
- Answer: Its contact message from CMD.
- What is Relationship and from where the Relationship data will be feed in DMDM? How Relationship is associated with other entities like Customer, Contact, Concern ect?
- Answer: Its relationship information published from CMD.
- What is STDLocation and from where the STDLocation data will be feed in DMDM? How STDLocation is associated with other entities like Customer, Contact, Concern ect?
- Answer: Its stand alone location can be created in DAMCO and is not associated with any customer. L&S(Damco) can create standalone facility and if same is linked with customer then called as 'Alternate locations'
- Is customer and contact data in synch with CMD data? if there are additional customer/contact data in DAMCO, do we need to migrate them to CMD?
- Concerns are getting creating in CMD as well as in DAMCO, how the concern mapping in CMD is different from concern mapping in DAMCO?
- Why cant DAMCO consumer can integrate with CMD via EMP channel? Below are the challenges if not integrated with EMP
- Additional fields/functionality needs to be added in CMD, which will lead to data model change in CMD
- Data model change will impact respective ingest services, publish services, UI portal, message translation etc. which is an additional effort
- Once the DAMCO consumers start consuming data from EMP, CMD need to remove the functionality added specific to MQ integration
- Any limitation on consuming the CMD data at DAMCO end (number of messages per second) ?
- User is allowed to update EORI for some country, I think its for US.. Need to check with any LNS person about it and need to know does it have any extra efforts at CMD end or not.?
Open action items from last workshop: