DICO

DICO

The DICO Standaard (formerly SALES Standaard) is the Dutch messaging standard for communication between chain parties in the construction and installation industries. Using the software-independent messaging standard, businesses can exchange messages between their computer systems safely, efficiently and without errors. DICO is the most recent national exchange format that 2BA can both import and export. This documentation is supplementary to the original format description of Ketenstandaard.

DICO is the new name for SALES005, the successor to INSBOU004 and has a similar construction. This standard has a product data message that includes ETIM classification, attachments and certificates and an item message with trade data such as details of price, order and logistics. In addition, the item relationship message offers the option of facilitating product relationships and references.

Mapping

2BA ensures that the data pool complies with the Dutch standards of Ketenstandaard with XML files INSBOU and DICO. The supporting exchange formats are allocated to the internal fields of the data model. Some internal fields may vary in length or type as described in the guideline of the exchange formats.

Ketenstandaard Bouw en Techniek (Chain Standard Construction and Engineering)

For the full documentation of the DICO standard, we refer you to the Ketenstandaard Bouw en Techniek foundation. They issue XSD diagrams, the list of functional features and support for all DICO messages. You need to be a member of Ketenstandaard or your organisation needs to have a 2BA-ETIM combination contract with 2BA.

DICO messages should be validated according to the original XSD. Ketenstandaard Bouw en Techniek offers a validation tool (Ketenstandaard account required) on their website.

Item message header

Example header of the DICO item message:

<PriceCatalogue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.ketenstandaard.nl/artikelbericht/SALES/005" xmlns:exs="http://www.ketenstandaard.nl/SALES/Extensies" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.ketenstandaard.nl/artikelbericht/SALES/005 Artikelbericht_SALES005.xsd">
    <PriceCatalogueNumber>cataogusnummer10</PriceCatalogueNumber>
    <MessageDate>2019-11-11</MessageDate>
    <PriceChangeIndicator>false</PriceChangeIndicator>
    <Currency>EUR</Currency>
    <MutationCode>4</MutationCode>
     <Datapool>
            <GLN>8714252005929</GLN>
    </Datapool>
    <Manufacturer>
        <GLN>8714252005929</GLN>
    </Manufacturer>
    <Grouping>
        <Supplier>
            <GLN>8714252005929</GLN>
        </Supplier>

Important notes:

  1. Buyer not required.

  2. Data Pool GLN from 2BA or InstallData.

  3. Manufacturer not required.

  4. Grouping, required. This element can be repeated if item records of varying GLNs have to be delivered.

  5. The NAW information is not necessary here.

  6. Attachments and certificates at header level will not be imported.

Header product message

Example header of the DICO product message:

<ProductData xmlns:xs="http://www.w3.org/2001/XMLSchema"
             xmlns="http://www.ketenstandaard.nl/productgegevens/SALES/005"
             xmlns:exs="http://www.ketenstandaard.nl/SALES/Extensies"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.ketenstandaard.nl/productgegevens/SALES/005 Productgegevens_SALES005.xsd"><
    <MessageNumber>P45789</MessageNumber>
    <MutationCode>9</MutationCode>
    <MessageDate>2019-01-05</MessageDate>
    <ETIMVersion>
         <VersionNumber>DYNAMIC</VersionNumber>
         <IssueDate>2018-10-11</IssueDate>
    </ETIMVersion>
    <Supplier>
       <GLN>8714252005929</GLN>
    </Supplier>
    <Datapool>
        <GLN>8714252005929</GLN>
    </Datapool>
    <Manufacturer>
        <GLN>8714252005929</GLN>
    </Manufacturer>

Important notes:

  1. Buyer not required.

  2. Supplier GLN for the supplied batch.

  3. Data Pool GLN from 2BA or InstallData.

  4. Manufacturer not necessary, the GLN at record level will be used.

  5. The address information is not necessary here.

  6. Attachments and certificates at header level will not be imported.

Type of dataset

2BA supports DICO complete or update and mutation files. A complete dataset should contain all active products. The fact is that a new, complete file overwrites all records in the database! Use MutationCode to define the dataset as a complete or mutation file.

Existing product records not present in the complete file will be given status code 130 – ‘lapsed product’. Existing trade data not present in the complete file will be deleted.

  1. Mutation code9: complete file.

  2. Mutation code4: mutation file.

We recommend working with complete datasets. By working with complete datasets, the published data stays most similar to your source data.

ETIM Classification

Country specific features

With the introduction of ETIM version 8 it is possible to communicate country-specific features. This functionality is supported from DICO SALES005.1.

ETIM version listing

According to the SALES005 product message documentation, a value of up to 35 characters can be specified for the ETIM version. The data model supports up to 10 characters for the ETIM version. See the mapping of the ETIM version versus data model here.

Reason no value

According to the ETIM guideline, if a value cannot be allocated, the data supplier has the option of using a minus sign. 2BA does not recognise values with a minus sign. Instead, use one of the following reasons:

  1. NA; Not applicable (this feature is not applicable in the context of a product in this class).

  2. MV; Missing value (an alphanumerical feature is relevant, but there is no correct value in this ETIM version).

  3. UN; Unknown (the data supplier can specify no value at present; but it is possible in principle).

Status code

There is also a mutation code at line level in the model. This value cannot be delivered with the DICO standard. There is however a mutation code at file level (for both the item and the product message). A status code has also been defined at line level. The combination of the two codes is interpreted as follows:

Type of dataset: mutation (4):

  1. Read all product records with mutation code: 3 (modify).

  2. Item records with status code 125, 94E to mutation code: 3 (modify).

  3. tem records with status code 130 to mutation code: 2 (delete).

Type of dataset: complete (9):

  1. Read all items with mutation code (model): 1 (add/new).

  2. Read all products with mutation code (model) 1: (add/new).

Logistics Information

The item message refers you to the EANCOM 7065 list for packaging codes. This list is not included in the XSD diagram. Since the list contains many double forms, irrelevant to the sector, it was decided to use a selection from the list.

If a code is missing and there is no alternative available, you can request 2BA to add this code. Such a request will also be submitted to ETIM International for the exchange format BMEcat 2005 ETIM Guidelines.

Mapping packaging codes versus data model

Important notes:

  1. If the number of packaging parts is greater than one, the packaging dimensions submitted will apply for all packaging parts.

Price details:

For each item it can be defined how the item can be ordered, on which unit the price is based, which discount group the item falls into and how the item can be used.

Important note:
  • The DICO exchange format supports communicating price information with an effective date in the future. In addition to a gross price, a discount group and price unit that will apply in the future can also be specified; The data pool does not yet support this (expected Q4 2024).

Descriptions, brand, model and variation

With a good description it becomes clear which product is mentioned. Data downloaders use these within the (web) catalog, on transaction messages and within the calculations. In addition, the trade item or product can also be found based on the description. The standard has two descriptions: short and long, in addition there is room for an extensive marketing text.

Important notes:

  1. When the description is longer than 70 characters, it is recommended to
    to be explained by means of the ‘long description’ (256 characters)

  2. Product level translations are only imported if the short description, serie and type are present in the same language code within the dataset.

  3. The brand is copied from the brand description specified with the relevant GLN

Dangerous substances and certificates

The certificate structure as included in the DICO standard is fully supported by the data pool. Certificates supplied as attachments are imported, these are related to the associated indicator(s) such as ROHS, CE Certificate and ‘contains battery’.

  • Mapping Productcertificaten versus datamodel

    • Important notes:

    1. Within the default product message the REACH indicator is missing. This has been added as Data UDE as of January 2024.

    2. From the product message (certificates section), the indicator REACH=true may also be imported based on the existing REACH certificate.

    3. Please note. If the REACH certificate is missing as an attachment, the value for REACH as described in the ETIM Guideline will be exported as ‘no data’ for a BMEcat 2005 export.

    4. The revision date for SDS and REACH is imported from the product message.

    5. The certificate number for DIN, ISO, ECCN and UN number is imported from the product message.

    6. No certificate information is imported from the article message.

    Attachments

    The attachment structure has been significantly expanded compared to INSBOU004 allowing physical attachments to be sent too. And it offers the option of submitting a title and description for the attachment, in other words submitting further information about the attachment. At present, attachments are only accepted from within the product message.

    By default, the import routine will download an attachment and add it to the product data. If the original source indicator is specified as ‘true’, the import routine will not download the attachment but will keep the attachment as a reference (as specified) to the source (URL). This is for example desirable when an attachment such as a certificate or manual is dynamically updated but the URL remains the same. This is not possible for the low-resolution image (PPI).

    File Hash and OriginalFileSource

    The import routine automatically creates an MD5 Hash from each downloaded attachment/file. An MD5 Hash makes it possible to determine whether it is a new file or a duplicate. The MD5 Hash is sent per attachment with a dataset export using the attachment attribute AttachmentHash. In addition, the original file name published by the data supplier is also included in the OrginalFileSource attribute.

    Language code of the attachment content

    Within the DICO standard, the ContentLanguage attribute offers the possibility to communicate the content language of the attachment. This may apply, for example, if a data-technical manual has a Dutch title and description, but the manual itself is written in English.

    Deeplinks

    A deeplink to a product or article page could be specified in a separate field in the exchange format INSBOU004. Within the DICO standard, a deeplink must be specified as an attachment type (LPP). Only the first specified deeplink is imported as a product or trade item deeplink. If you enter multiple deeplinks, they will be imported as attachment type ‘other’ (OTA).

    Considerations:

    1. When files are physically supplied within the dataset, the file name must be specified within the element.

    2. If the low-resolution image is missing from a product and a high-resolution image (PHI) has been supplied, the import system will automatically generate a low-resolution image (PPI). If this fails, this will be reported in the processing report. If the high resolution image is specified as a reference on the internet (OriginalSourceIndicator=true) then the system cannot generate a low resolution image.

    3. Within the data pool, the element ‘presentation sequence’ is a numerical field. Alphanumeric values are not imported.

    Product references and relationships

    The item relationship message makes it possible to indicate relationships between products or items. The mapping of the type of relationship to the data model is available here.

    Important note:

    • The DICO standard assumes an implicit unit for a specified quantity; since it is a trade item (or product) to trade item (or product) relation, pieces (PCE) are assumed.

    • A part or accessory of a product can be specified with relation type ‘ONV.’

    Important notes::

    1. Within the default product message the REACH indicator is missing. This has been added as Data UDE as of January 2024.

    2. The indication REACH=true is imported from the product message (certificates section) based on the specified REACH certificate.

    3. Please note. If the REACH certificate is missing as an attachment, the value for REACH as described in the ETIM Guideline will be exported as ‘no data’ for a BMEcat 2005 export.

    4. If REACH does not apply to products (REACH=false), this can be specified via an import manipulate operation.

    5. The revision date for SDS and REACH is imported from the product message.

    6. The certificate number for DIN, ISO, ECCN and UN number is imported from the product message.

    7. No certificate information is imported from the article message.

    Attachments

    The attachment structure has been significantly expanded compared to INSBOU004 allowing physical attachments to be sent too. And it offers the option of submitting a title and description for the attachment, in other words submitting further information about the attachment. At present, attachments are only accepted from within the product message.

    By default, the import routine will download an attachment and add it to the product data. If the original source indicator is specified as ‘true’, the import routine will not download the attachment but will keep the attachment as a reference (as specified) to the source (URL). This is for example desirable when an attachment such as a certificate or manual is dynamically updated but the URL remains the same. This is not possible for the low-resolution image (PPI).

    File Hash and OriginalFileSource

    The import routine automatically creates an MD5 Hash from each downloaded attachment/file. An MD5 Hash makes it possible to determine whether it is a new file or a duplicate. The MD5 Hash is sent per attachment with a dataset export using the attachment attribute AttachmentHash. In addition, the original file name published by the data supplier is also included in the OrginalFileSource attribute.

    Language code of the attachment content

    Within the DICO standard, the ContentLanguage attribute offers the possibility to communicate the content language of the attachment. This may apply, for example, if a data-technical manual has a Dutch title and description, but the manual itself is written in English.

    Deeplinks

    A deeplink to a product or article page could be specified in a separate field in the exchange format INSBOU004. Within the DICO standard, a deeplink must be specified as an attachment type (LPP). Only the first specified deeplink is imported as a product or trade item deeplink. If you enter multiple deeplinks, they will be imported as attachment type ‘other’ (OTA).

    Considerations:

    1. When files are physically supplied within the dataset, the file name must be specified within the element.

    2. If the low-resolution image is missing from a product and a high-resolution image (PHI) has been supplied, the import system will automatically generate a low-resolution image (PPI). If this fails, this will be reported in the processing report. If the high resolution image is specified as a reference on the internet (OriginalSourceIndicator=true) then the system cannot generate a low resolution image.

    3. Within the data pool, the element ‘presentation sequence’ is a numerical field. Alphanumeric values are not imported.

    Product references and relationships

    The item relationship message makes it possible to indicate relationships between products or items. The mapping of the type of relationship to the data model is available here.

    Important note:

    • The DICO standard assumes an implicit unit for a specified quantity; since it is a trade item (or product) to trade item (or product) relation, pieces (PCE) are assumed.

    • A part or accessory of a product can be specified with relation type ‘ONV.’

    Wat biedt 2BA voor u als Installateur Wat biedt 2BA voor u als Groothandel Wat biedt 2BA voor u als Fabrikant Wat biedt 2BA voor u als Software Partner
    This site is registered on wpml.org as a development site.