Business rules

From CDL
Jump to: navigation, search
Managed element
Last edit 11 October 2018 06:21:57
Support contact 
A member of the CDL Team who is responsible for a specific element of the CDL infrastructure.
Simon Schlosser

In the Corporate Data League, business rules ensure data quality and specify how to process collaborative reviews. Currently, 292 data quality rules are checked to ensure a high level of data quality and 17 review rules ensure efficient processing of collaborative reviews. Each business rule is documented in a form that is understandable by business users referencing the defined data model concepts in the rule definitions.

The standardization approach of the data quality standard across all CDL Members is a collaborative endeavor and managed by the CDL Team. Rules need to be analyzed and adapted on a permanent basis. Existing rules may become inapplicable, or it may be necessary to introduce new rules. Some business rules specify which data values are valid for specific attributes. For this purpose, reference data is collected and documented on these pages (e.g. countries). Integrating new reference data usually goes along with the adaptation of an existing business rule or the creation of new ones.

Business rule use cases

There are different use cases that are supported by the CDL data validation. The list will be continuously extended:

Data quality rules

The list below gives an overview on all data quality rules that are currently documented and implemented.

Business ruleDefinition
Business partner name missingIt is necessary that each business partner has at least one name. With respect to the CDL data model it is at least required that a name of type LOCAL or INTERNATIONAL is present.
Care of information misplacedCare of (typicall indicated by "c/o") information must not be maintained in the business partner's name, locality or thoroughfare but is to be managed as care of attribute. If there is care of information found as an attribute value other than "care of" the rule is violated.
Contact information misplacedContact information is not allowed in the registered name, trade name or international name. This rule checks whether contact information is misplaced by identifying e.g. common keywords such as "attn:" or "z.Hd." and additionally parsing the company name for natural person names that are not meant to be part of the legal name (e.g. when natural person names are placed after the legal form)
EIN format invalid (United States)This rule checks the format of Employer identification number (United States) as described in the additional information tab
Identifier format invalid (European value added tax identifier (Austria))The European value added tax identifier in Austria consists of the prefix "AT" followed by the character "U" and 8 numerical digits. This rule checks the presence of "U" followed by exact 8 digits without considering possible whitespaces, hyphens or dots that might be comprised in the identifier value. If there are less/more or wrong placed digits or the "U" is missing then the rule is violated.
Identifier format invalid (European value added tax identifier (Belgium))The European value added tax identifier in Belgium consists of exact 10 numerical digits prefixed by "BE". The first digit following the prefix is always 0 or 1. This rule checks the existence of exact 10 digits without considering possible whitespaces, hyphens or dots that might be comprised in the identifier value. If there are less/more, non-numeric digits or when the first digit does not equal 0 or 1 the rule is violated.
Identifier format invalid (European value added tax identifier (Bulgaria))The European value added tax identifier in Bulgaria consists of 9 or 10 numerical digits prefixed by "BG". This rule checks the existence of 9 or 10 digits without considering possible whitespaces, hyphens or dots that might be comprised in the identifier value. If there are less/more or non-numeric digits the rule is violated.
Identifier format invalid (European value added tax identifier (Cyprus))The European value added tax identifier in Cyprus consists of 9 characters (8 numerical digits + 1 letter) prefixed by "CY". This rule checks the existence of 8 numerical digits followed by a character without considering possible whitespaces, hyphens or dots that might be comprised in the identifier value. If there are less/more or wrong placed digits or the last cipher is not a letter but a numerical digit then the rule is violated.
Identifier format invalid (European value added tax identifier (Czech Republic))This rule checks the format of European value added tax identifier (Czech Republic) consists of 8-10 digits prefixed by "CZ". This rule checks the existence of 8 numerical digits without considering possible whitespaces, hyphens or dots that might be comprised in the identifier value. If there are less/more or wrong placed digits then the rule is violated.
Identifier format invalid (European value added tax identifier (Denmark))The European value added tax identifier in Denmark consists of exact 8 numerical digits prefixed by "DK". This rule checks the existence of exact 8 digits without considering possible whitespaces, hyphens or dots that might be comprised in the identifier value. If there are less/more or non-numeric digits the rule is violated.
... further results
Business ruleDefinition
Company is greylistedThe rule checks whether a given business partner is known to be inactive by means of being "out of business", "in liquidation" or in a similar status. For this purpose the rule searches for information in the CDL business partner repository and in addition in several connected data sources. These are:
  • UK: Companies House
  • CH: Swiss business register
  • FR: French business register (SIREN)
  • ... further will follow
Fundamental address parts missingIt is necessary that an address, PO Box- or street address, comprises at least a post code or locality.
Identifier format invalid (Business number (Canada))The Canadian business number consists of exactly 9 numerical digits. The rule checks whether there are exactly 9 numerical digits available not considering possible whitespaces or other delimiters between the digits.
Identifier format invalid (CNPJ number (Brazil))The CNPJ consists of a 14-digit number formatted as 00.000.000/0001-00 — The first eight digits identify the company, the four digits after the slash identify the branch or subsidiary ("0001" defaults to the headquarters), and the last two are check digits. This rule checks the existence of exactly 14 digits without considering the concrete formatting using ".","/" or "-".
Identifier format invalid (CUIT number (Argentina))The CUIT number in Argentina consists of 11 numerical digits.
Identifier format invalid (Corporate number (Japan))The Corporate number in Japan consists of exactly 13 numerical digits. The first digit is the check digit and cannot be 0.
Identifier format invalid (European value added tax identifier (Croatia))The European value added tax identifier in Croatia consists of the prefix "HR" followed by 11 numerical digits. This rule checks the presence of exact 11 numerical digits without considering possible whitespaces, hyphens or dots that might be comprised in the identifier value. If there are less/more or e.g. alphabetic values then the rule is violated.
Code Structure of Legal Entity IdentifierThe technical specification for LEI is ISO 17442. An LEI consists of a 20-character alphanumeric string, with the first 4 characters identifying the Local Operating Unit (LOU) that issued the LEI. Characters 5 and 6 are reserved as '00'. Characters 7-18 are the unique alphanumeric string assigned to the organisation by the LOU. The final 2 characters are checksum digits.
Identifier format invalid (PAN code (India))The Permanent Account Number (PAN) in India are composed like this: First five characters are letters, next 4 ciphers are numerical digits and the last cipher is a letter. This rule checks the conformance with this reference scheme without considering possible whitespaces, hyphens or dots that might be comprised in the identifier value.
Identifier format invalid (RFC number (Mexico))The Mexican tax identification number consists of 3 letters followed by a delimiting hyphen("-") + a 6-digit number + "-" followed by a 3-character string. The rule does check whether exactly 3 letters are followed by 6 numerical digits and 3 characters without considering the delimiting hyphen nor whitespaces or other delimiters such as dots.
... further results

Query example

Data quality rules, listed by country and attributes (Excel):

Loading...

Review rules

The list below gives an overview on all review rules which are currently documented and implemented.

Business ruleDefinitionStatus
Auto reject removal of given legal formAuto reject a review if the only difference is a missing Business partner legal form in the update while current data comprises a Business partner legal form.RELEASED
Auto reject update with error defect in addressAuto reject a review if the address violates at least one data quality rule.RELEASED
Auto reject update with error defect in business partnerAuto reject a review if the business partner violates at least one data quality rule.RELEASED
Business ruleDefinitionStatus
Auto reject additional legal addressAdding a legal address is rejected, if a legal address does already exist.DRAFT
Auto reject address country updateDo not allow edits of Country.DRAFT

No inactive auto reject review rules

Business ruleDefinitionStatus
Review address locality updateTrigger manual review for Locality value updates.RELEASED
Review address post code updateTrigger manual review for Post code updates, except the updated value is more precisely than current data.RELEASED
Review address thoroughfare number updateTrigger manual review for Thoroughfare number updates, except the updated value is more precisely than current data.RELEASED
Review address thoroughfare updateTrigger manual review for Thoroughfare value updates.RELEASED
Review business partner identifier updateTrigger manual review if a Identifier is changed.RELEASED
Review business partner legal form updateTrigger manual review if Business partner legal form is changed.RELEASED
Review major business partner name updateTrigger manual review if Name value is changed in a significant way. In this context, "significant" means that the new names differ in more than 2 categories, e.g. uppper/lower case and additional/less punctuation (e.g. -, ., ,, or ;).RELEASED

No draft manual review rules

No inactive manual review rules

No released review processing rules

Business ruleDefinitionStatus
Mandatory review of address removalsRemoval of addresses is always reviewed.DRAFT
Merge of business partner updatesIf there is already a review pending for the provided business partner, the new update is merged into the pending one. Values from the newer update are preferred.DRAFT
Reviews of non-legal addressesA new address is only reviewed, if it is a legal address. Adding any other address does not trigger a review and is accepted as is.DRAFT

No inactive review processing rules

Standardization rules

The list below gives an overview on all business rules to standardize business partners and addresses that are currently documented and implemented.

Contribute!

We are continuously defining and implementing additional rules. Please get in touch with us if you observe that a business rule is missing! Also if you are interested in the business rules management architecture and its implementation we would be happy to provide you with additional information or a showcase.

Technical Implementation

The technical implementation of the business rules uses the semantics defined in this wiki. The knowledge documented in this wiki is stored as RDF triples in a triple store (Jena TBC). The RDF triples are made accessible by a SPARQL endpoint (Jena Fuseki). Business rules are translated into a semantic representation as RDF triples and added to the ontology provided by the endpoint. For representing and executing the rules SPIN is used. SPIN is a collection of RDF vocabularies which enable the use of SPARQL to define constraints and inference rules on Semantic Web models. For checking a business partner or an address for business rule violations, the data record is translated into a semantic representation which is an instantiation of the data model. The business rules do then check whether the instance does confirm to the world defined in this wiki or not.

Theory

From a theoretical point of view the data model concepts and the relations between them define the Corporate Data League domain (in other words the world as it is understood by the CDL). Within this world everything would be possible when there are no rules. Business rules constrain this world by reducing the space of possible instantiations of the modeled domain. An example for this is a business rule that constrains the possible values a country. It says that an allowed value for a country are only those countries that are defined in the ISO 3166-1 standard. These countries are documented as reference data in this portal. Without this rule a country could have any other value such as "Romulus". To take up again the wording from above: The documented countries are knowledge about the CDL world (domain), and this knowledge is used to constrain the possible space of options for the name of a country.