BVD Integration
In CMD context the BVD source is integrated with CMD application in 2 ways. The purpose of integrating BVD source with CMD is to have the option to search for a customer in BvD and select the BvD details, which should automatically populate in the customer data fields in UI or passively enrich few customer details.
Active BVD Integration
Active BVD Integration means, getting the customer details when user is creating from CMD Portal.
When user is creating customer from CMD Portal, the user should be able to proceed with the customer creation only after performing a search. Even if the search result gives existing customers, the user must be given the option to create a customer. When user try to create after searching, user must be given option to search the customer in BVD source and user cant skip this option of searching customer in BVD source. If BVD source does not have any customer which user is trying to create, then system will allow to create customer with user entered details.
The country entered by user while searching customer, should get auto populated in BVD search filed and trading name, city, Tax number should be entered by user to search customer.
User can search customer in BVD source based on the combination of Trading Name+Country OR TaxNumber+Country. In these combinations both fields are mandatory and City also can be enetered but which is an optional filed. If user is not entered any mandatory filed then user will get error like below
“Please enter Trading Name + Country or Tax reference + Country combination”
The BVD search result will be limited to 100 records and will be displayed in pages with pagination of 10 records per page.
User can also filter the BVD search result based on Address, postal code and Tax reference fields.
If user select any one customer from BVD search result then, all below fields in CMD portal will be auto populated with values from BVD source.
- Trading Name
- Legal Name
- BvD ID
- Country
- Phone
- URL(Website)
- Customer Address
- Street Number
- Street Name
- City
- Region
- PO BOX
- Country
- Postal Code
- Tax Details
- Tax Type
- Tax Number
- Reference Details
- Reference Type
- Reference Number
If user try to change Country and City fields which are auto populated by BVD then system will retrigger the BVD search as user changed key fields.
If user does not modify any address fields provided by BVD source, then Address verification service will be called but it will not go for approval process irrespective of match score by address verification service as we are trusting BVD address information.
If user modify any address field which is provided by BVD, then also Address Verifcation service will be called and if the address threshold value is less than <> then trigger the Address Verification workflow else no workflow.
If BVD customer status is dissolved and user want to create it, then it will go for approval process as its status is dissolved.
Once the customer from BVD source is created, user should be able to see the BVD id in CMD portal as hyperlink when clicked on it it will take to Orbis portal.
If a customer record already enriched from Active BVD integration approach, then that same customer can not be enriched again for same fields. Other fields will be enriched as part of passive enrichment which described in next section.
If user try to reactive the inactive customer, the creation process must go through the BVD search and then create process as described above.
Solution Implementation:
Passive BVD Integration
Passive BVD Integration means, getting few more customer details after customer created in CMD application. During Active integration process all details can not be fetched so with passive process the remaining fields or all fields of a customer will be enriched if not enriched during the active integration process.
To enrich the customers data passively, the customer codes created by portal or IngestAPI will be pushed to BVD Topic. From BVD topic, a consumer will pick message and will call BVD service to enrich below fields of customer as part of passive process.
- BVD Sector
- GUO BVD Id
- HQ BVD Id
- GUO BVD Name
- GUO BVD Status
- HQ BVD Name
- HQ BVD Status
- Market Cap
- Operating Revenue Turn over
- Date of Account
- Profit Margin Percentage
- Credit Rating
- Recommended credit limit
- Legal Name
- Core SIC Code
- Core SIC Description
- Primary SIC Codes
- Primary SIC Description
- Secondary SIC Codes
- Secondary SIC Description
Enriching Sector(verticals) and SIC information from BVD source:
As part of BVD active integration, the customer details, basic data, address data, tax information will be enriched as part of new customer create process.
Once the customer is enriched actively and persisted the data in MDM, passive BVD process picks the records created and will enrich further information like, BVD sector, Standard Industry codes. Below is the high level process for the same.
- BVD passive enrichment process will be triggered by picking the message from BVD EMP Topic
- The BVD passive process service (BvdEnrichmentService) will call cloud based BVD wrapper retrieve API by passing the BVD ID for each newly created customer.
- Along with enriching other information like financial details, it will fetch below details
- BvD sector (BVD field : BVD_SECTOR_CORE_LABEL)
- SIC code (3Char) and description : (BVD field: USSIC_CORE_CODE ,USSIC_CORE_LABEL)
- SIC Primary code(s) (4 Char) and description : (BVD field : USSIC_PRIMARY_CODE ,USSIC_PRIMARY_LABEL)
- SIC Secondary code(s) (4 Char) and description : (BVD field : USSIC_SECONDARY_CODE,USSIC_SECONDARY_LABEL)
- BvdEnrichmentService service captures the BVD retrieve API response and connect MDM database to persist the sector and SIC information.
- BvdEnrichmentService uses PUT SIF call to put the data into C_PTR_SIC_INFO BO table. Before executing SIF call, we need to get PTR_ROWID column value from C_PTR_PARTY_RL table based on BVD ID or customer code. We need to pass PRTL as systemName in putRequest.
- Co-ordinate with SMDS replica IBM team to push sector and SIC information to SMDS replica through OGG.
Mastro team get Sector and SIC information through SMDS replica. Once Mastro get the information, they manually assign the right sector and SIC information to customer.
Once the sector and SIC information is assigned, they share data with CMD team. CMD team use BBU functionality to update sector and SIC information under segmentation section of customer.
Below diagram functional flow of enriching SIC information:
TBD
When user change the industry information from CMD portal or BBU, the industry information should be brand agnostic. Below are the brands available today in PROD
- MAERSK LINE
- SAFMARINE
- SEALAND MAERSK AMR
- SEALAND MAERSK ASI
- SEALAND MAERSK EUR
When user try to update an existing customer with segment information (brand, segment type and segment value) either through BBU or Portal UI, then the segment type and segment value needs to be replicated for other brands(mentioned above) as well. If user try to select another brand, user should not be allowed as it is updated for other brands too.
Segment type data is available in C_PTR_CLSSN_TYP and segment value is available in C_PTR_REL_CLSSN table. The relationship between customer and segment type and value will be stored in C_PTR_SEG table when user update segment value via BBU or UI.
This requires change at CMD Portal UI level and upsertCustomer level.
- At UI level, once user selects a particular combination, then user should not be allowed to select other brand. After updation, if user reopens the customer, user should be able to see all brands with selected/updated segment type and segment value combination.
- At upsertCustomer level, code needs to be changes to update the segment type and segment value for other brands by calling assignCustomerSegments operation under customer management service.
Below is the C_PTR_SIC_INFO table structure and sample data in the table.
| Column Name | Type |
|---|---|
| ROWID | BIGSERIAL |
| CUSTOMER_CMD_CODE | VARCHAR(100) |
| BVD_SECTOR | VARCHAR2(200) |
| CORE_SIC_CODE | VARCHAR2(5) |
| CORE_SIC_DESC | VARCHAR2(200) |
| PRIM_SIC_CODE | VARCHAR2(5) |
| PRIM_SIC_DESC | VARCHAR2(200) |
| SEC_SIC_CODE | VARCHAR2(5) |
| SEC_SIC_DESC | VARCHAR2(200) |
| CREATE_TIME | DATE |
| CREATE_USER | VARCHAR(50) |
| UPDATE_TIME | DATE |
| UPDATE_USER | VARCHAR(50) |
| IS_DELETED | CHAR(1) |
| IS_PENDING | CHAR(1) |
| SOURCE_OF_LAST_UPDATE | VARCHAR(50) |
Sample data in C_PTR_SIC_INFO table
| ROWID | CUSTOMER_CMD_CODE | BVD_SECTOR | CORE_SIC_CODE | CORE_SIC_DESC | PRIM_SIC_CODE | PRIM_SIC_DESC | SEC_SIC_CODE | SEC_SIC_DESC |
|---|---|---|---|---|---|---|---|---|
| 1 | IN123456 | Chemicals, Petroleum, Rubber & Plastic | 299 | Miscellaneous products of petroleum and coal | 2999 | Products of petroleum and coal, not elsewhere specified | 2085 | Distilled and blended liquors |
| 2 | IN123456 | 2991 | ABC | 5085 | Industrial supplies wholesale dealing in | |||
| 3 | IN123456 | 5093 | Scrap and waste materials wholesale dealing in | |||||
| 4 | IN123456 | 5099 | Durable goods, not elsewhere classified wholesale dealing in |