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.
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.
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.
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>
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>
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.
We recommend working with complete datasets. By working with complete datasets, the published data remains most similar to your source data. If you have such a large range with a large number of attachments and regular changes, we recommend mutation files and periodically publishing a complete file.
With the introduction of ETIM version 8 it is possible to communicate country-specific features. This functionality is supported from DICO SALES005.1.
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.
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:
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):
Type of dataset: complete (9):
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.
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.
DICO (SALES005) supports up to 100 prices per item. Future prices can be added to the catalogue message where the start date of the price
You cannot remove previously specified future prices from the data pool. If you want to correct a future price, you can submit a new future price with the same effective date as that of the “incorrect” price. The old future price is then overwritten.
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.
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’.
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).
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.
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.
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).
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.
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).
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.
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.
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).
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.