Business Validation using Harmony WS

This document provides instructions on utilizing the Harmony Restful WebServices for the Validation of business samples using Business Validation PDPs in different locales.

API:

http://localhost:8080/HarmonyWS/rest/parseCustomerData

Role used in Webservice Request

Sample Request and Response for Australia

Response 1 to 3 illustrates single company entity. Irrespective of whether the input is a main entity name, trading name, business names or other entity name the response will always depict the rule name as MainName in business_ver_code.

Request 1: Input main entity name.
Response 1: Exact match to the input
Request 2: Input misspelt business name.
Response 2: Response shows validated business information. business_display_name holds the corrected business_name.
Request 3: Input Trading Name
Response 3: Response shows validated business information. business_display_name holds the trading name.

Response 4 to 9 illustrates complex business structures with multiple entities.

These samples depict the order of priority for rules as listed in matching rules list.

Request 4: Validate a Complex business with multiple entities, person name trading as another business name.
Response 4: Match found using MainName
Request 5: Validate a Complex business with main entity trading as a business in trust for beneficiary. Sample for an ambiguous match.

Sample for an ambiguous match

Response 5: Response shows an ambiguous match using BeneficiaryName. No further rules are validated due to ambiguity.

These samples depict the order of priority for rules as listed in matching rules list.

Request 6: Complex business entity, match found on BeneficiaryName.
Response 6: Exact Match found on BeneficiaryName.
Request 7: Complex business entity, match found on MainName
Response 7: Exact match found on MainName
Request 8: Complex business entity, match found on TradingName
Response 8: Exact Match found on TradingName
Request 9: Validate business using OriginalInput
Response:9 Partial match was found with a very weak match

Response 10 illustrates business validation utilizing multiple data models: ID and companyName. The ID can represent either a business number or a company number, while the companyName can denote a person's name or a complex company entity.

Request 10: Validate business input with both business number and company name.
Response 10: Exact match found on business number. No further rules are processed.
Request 11: Validate Family Partnership entity.
Response 11: Exact match using OriginalInput

Response 12 to 14 illustrates business validation when custom rules are set in business_validation_config.yml file.

Request 12: Validate business using custom rule for taxStatus. Configure business_validation_config.yml with taxStatus: "ACT" for au.
Response 12: Input business is validated against active business tax status only.
Request 13: Validate business using custom rule for nameTypes. Configure business_validation_config.yml including an additional nameType "OTN" for au.

nameTypes:

- "MN"

- "LGL"

- "TRD"

- "BN"

- "OTN"

Response 13: Input business is validated against various nameTypes including other names.
Request 14: Validate business using custom scoreThreshold. Configure business_validation_config.yml with scoreThreshold: 0.2 for au. Same Input record as in Request 9.
Response 14: Score of the validated input falls below the threshold, hence it is categorized as a NoMatch on OriginalInput. Nevertheless, if there is a match found on the BeneficiaryName, it signifies an alternate outcome.

Response 15 illustrates how business names can surpass parsing failures through the utilization of configuration in $HARMONY_HOME/config/scrubbing/harmony_scrubbing_descriptor.xml.

default configuration is false.

Set the configuration to true, as below to surpass parse failure and proceed with business validation.

<h:passthrough-name-on-parse-failure>true</h:passthrough-name-on-parse-failure>.

Request 15: Validate an alphanumeric business name
Response 15: Validated business information using OriginalInput.

Sample Request and Response for New Zealand

Response 1 and 2 illustrates single company entity. Irrespective of whether the input is a main entity name, trading name, business names or other entity name the response will always depict the rule name as MainName in business_ver_code.

Request 1: Input exact main entity name.
Response 1: Exact match to the input
Request 2: Validate a misspelt Trading Name
Response 2: Response shows validated trading name information. business_display_name holds the corrected trading_name

Response 3 to 7 illustrates business validation utilizing multiple data models: ID and companyName. The ID can represent either a business number or a company number, while the companyName can denote a person's name or a company name with multiple entities. These samples depict the order of priority for rules as listed in matching rules list.

Request 3: Validate an input with multiple data models ID, Company name trading as another business name.
Response 3: Match is obtained on ID. No further rules are processed.
Request 4: Validate an input containing multiple data models, including an ID and a company name operating under another business name entrusted to a trust (Beneficiary). The ID yields no matches.
Response 4: Exact match obtained on BeneficiaryName.
Request 5: Validate an input containing multiple data models, including an ID and a company name operating under another business name entrusted to a trust (Beneficiary). The provided ID and trust name do not yield matches.
Response 5: Partial match obtained on MainName 0.071
Request 6: Validate an input containing multiple data models, including an ID and a company name operating under another business name entrusted to a trust (Beneficiary). The provided ID and trust name do not yield matches.
Response 6: Ambiguous match obtained on MainName
Request 7: Validate an input containing multiple data models, including an ID and a company name operating under another business name entrusted to a trust (Beneficiary). The provided ID, trust name and main name do not yield matches.
Response 7: Exact match obtained on TradingName

Response 9 illustrates how business names can surpass parsing failures through the utilization of configuration in $HARMONY_HOME/config/scrubbing/harmony_scrubbing_descriptor.xml.

default configuration is false.

Set the configuration to true, as below to surpass parse failure and proceed with business validation.

<h:passthrough-name-on-parse-failure>true</h:passthrough-name-on-parse-failure>

Request 9: Validate an alphanumeric business name.
Response 9: Validated business information using OriginalInput.

Response 10 illustrates business names that are failed to parse.

Request 10: Business names that are failed to parse.
Response 10: Business Validation will not be processed for failed to parse names.

Last updated