When commissioning the goods for dispatch, the delivery documents, consisting out of the CoC or Inspection Certificate and a delivery note, are often created digitally today. This means that the data for generating an e-CoC are actually available, but up to now only paper has been printed with them.
Since the IT systems in most companies are very heterogeneous at this point and the e-CoC standard is not yet established, there will be no ready-made “out-of-the-box” solution for the e-CoC for the time being. It will be an individual software solution, that each company will have to develop for their on needs .
In the following process description, we assume that an “e-CoC Generator” and an “e-CoC Interface” exists.
For the generation of the e-CoC, the transport, labelling of goods and the transfer of data from the supplier to the customer, different options are possible. Only one way is described here.
In the context of the commissioning and shipping process, the CoC or Inspection Certificate is generated by the manufacturer in the “e-CoC format” by an “e-CoC Generator”. Parallel to this, a label (see below) is created for the material identification, with a unique reference to the e-CoC. The UUID from the e-CoC (field: UUID) can be used for this purpose. This enables a globally unique, manufacturer-independent referencing of documents and material wttih the label. The UUID can also be printed directly on the part, if possible.
The goods and the data are sent separately from the manufacturer to the customer and do not arrive at the customer’s site synchronously. However, the referencing method described above makes a safe assignment possible. The e-CoC is transfered digitally. This can be done via encrypted email, a secure web portal or other IT-technical ways.
To process the e-CoC, an appropriate “e-CoC Interface” based on the DIN SPEC 9012 standard must be implemented on the recipient side as an interface to the local IT environment (e.g. DMS or ERP). This interface processes the e-CoC, extracts the required data and documents and stores them in the recipient system. This automates the process of document collection and processing as far as possible. Certain checks of the data against standards and therefore the conformity of the component could already be carried out. Manual processing is no longer necessary. This also considerably reduces the sources of error and makes the process stable.
When the goods arrive at the customer’s premises, the reference to the e-CoC can be established by the label containing the UUID. The necessary data links can be created in the ERP system and/or warehousing system. The goods do not have to be relabelled either, since the UUID can be used, which is a uniqe identificator in the receipent system as well.
Recommendation for labeling
As mentioned above, the receipt of data and goods will not be synchronous, simply because the transport speeds are different. The data may already be pre-processed and the CoC including metadata is already included in the DMS. When the physical goods arrive, the link between the data and the goods must be established.
The UUID of the inspection certificate or CoC can be used for this purpose, as it is unique, i.e. there are no number range conflicts between the data or goods from different manufacturers. If this UUID is on the label in any way, the connection between data and goods can be established by IT.
Since even one UUID results in a relatively long 1D barcode, the use of 2D barcodes is recommended. It is also recommended to store the data in the bar code in a structured manner. In the picture above, JSON syntax is also used for this purpose, as it is lightweight, self-explanatory and easy to process. The same logic can also be used for writable RFID labels.
Due to the uniqueness of the UUID, no further information needs to be written into the barcode, as long as this UUID is also stored in the receiver system. A receiver-specific re-labeling is then actually superfluous. However, you always need readers with a data connection, since the human-readable information has not been standardized.
The UUID could, for example, continue to be used as a batch number. It would not be necessary to set up a separate batch number.
Full Business Process
This BPNM diagram shows a option how the process of data preparing, transfering and reception can look like.
There are thre lanes:
Commissioning the goods an the collecting the data für the e-CoC
- e-CoC reception
reception and process the data
- goods reception
reception of goods and link to e-CoC data