Self Integrated Printing: Introduction

With a Selfprinting setup, you develop the label yourself as well as the EDI. You are free to choose how you develop these, but you do need to make sure they're valid with the DPD specifications. This setup gives you the most freedom as you can generate labels and EDI as you see fit, but you do have the responsibility of making sure they comply with the DPD specs.

Labels must have a valid, readable barcode with a correct and up to date routing. The routing is update each first Monday of September, January and May. You will be notified by email the week before.

EDI must be valid according to the specifications and must be complete and sent to us in time. This means we need to receive the EDI on the day the physical parcels are given to DPD.


1. Label specifications

Please refer to the documentation about the routing and the labels provided to you by DPD, as the section in the link below is an example based on it.


A DPD label must always contain the routing zone and the barcode as indicated in the label documentation. A typical routing+barcode zone would look like this:


Please note these values are just an example and yours may be different. The colored rectangles are naturally also not needed, since they're used here to illustrate the example.

  • The RED rectangle is the parcel number (14 characters) + the check digit (1 character). Calculating the check digit is explained in the label documentation. So in this case, the parcel number is 05305110109168 with check digit 8
    Important to know: DPD will provide you with a range of parcel numbers. This range will contain a starting number and an ending number. For each parcel you make, you use the next available number in your range. Once you reach the last number, it's important to reset your range back to the beginning number.
  • The BLUE rectangle is the O-Sort which can be determined in the routing database, which is explained in the routing documentation. In this case V530
  • The GREEN rectangle is the D-Sort which can be determined in the routing database, which is also explained in the routing documentation. In this case C149
  • The YELLOW rectangle is the actual content of the barcode, which is explained next.

The DPD Barcode is constructed as follows, based on this example:

  • Although it's not mentioned in the aforementioned yellow rectangle, the barcode itself must always begin with a %-sign
  • The first seven digits are the destination zipcode. However, if the zipcode has less than seven characters, you have to add zeroes in front of it to reach 7 characters. This example, 0002800 is zipcode 2800 with three added zeroes in front.
  • The next fourteen digits are the parcel number. 05305110109168 for this example.
  • The next three digits are the numeric service code. 136 in this example, which is the service code for DPD Small Parcel B2B.
  • The next three digits are the destination ISO numeric country code. 056 in this case, which is the code for Belgium.
  • The final digit is again a check digit, which is also explained in the label documentation. Please note that this check digit is not necessarily the same as the one mentioned in the red rectangle above.

If you'd scan the barcode with a handscanner, this result would come up: %000280005305110109168136056O


2. EDI File description

The contents of the MPSEXPDATA file is divided into a header, several application records and an end.The header consists of 10 lines, one file definition header and 9 data record definition headers. For the application records the HEADER record must always be first followed by the corresponding detail records. Data records that are not provided
in the format described above cannot be processed. The tokens of optional fields must always be contained
in the definition line. The data line fields may remain empty (;;) unless they're mandatory fields.

There is no limit as to how many shipments you include in a single file. You can send us multiple files with one shipment each, one single file containing all your shipments of the day or any frequency in between.

2.A. MPSEXPDATA general structure summary

You will find the full description of the MPSEXPDATA file in the menu on the right.

  • The #FILE line is unique for each MPSEXPDATA file. It contains your DelisID, the date (format YYYYMMDD) and time (format HHMMSS) and an ID of your file.
  • The #DEF files are definition files and also need to be mentioned only once per file. They're mandatory, but are pretty much the same every time. These contain the order and names of each field of each line type. 
  • The HEADER line contains the main info of your shipment. This contains the sender details, the receiver details, the total weight, references, the service code, etc. Basic details of the shipments. You can only have one HEADER line per shipment, obviously.
  • The PARCEL line contains the details of the parcel(s) of the shipment. You can have a single PARCEL line, which we call a mono-colli shipment, or you can have several PARCEL lines, one for each individual parcel within your shipment, which we call a mutli-colli shipment.
  • HEADER and PARCEL are the only two lines that are, without exception, always mandatory for each shipment. We will discuss these lines separately in the menu to the right. The other lines are for different service codes which are also discussed in the menu to the right. These include MSG, PERS, etc.
  • The SWAP line is a service that was discontinued so this can be ignored
  • The COD line is the same as SWAP: no longer in use
  • The DELIVERY line is also the same as SWAP and COD: it's not used.
  • The SHIPINFO line is yet another field we no longer use.
  • The MPSEXPDATA file must always end with an #END line. This line is, just like the #DEF and #FILE lines, also unique per file. The #END line contains the same ID you gave in the #FILE line.


2.B. MPSEXPDATA simplified construction

Lets assume your DelisID is xxxxx, that your depot is #####, that we create this file on the 13th of August 2018 and that we give it the unique ID 3.

#DEF lines




2.C. MPSEXPDATA file naming convention

The name of the EDI file needs to follow this logic:

MPSEXPDATA_<Delis ID>_CUST_<your depot code>_D<date>T<time>

Date format is YYYYMMDD, time format is HHMMSS. The date here must be the date on which you'll send this EDI file to DPD. This needs to be accurate. The time's accuracy is not as important: this is just a stamp we add to prevent the customer from accidentally overwriting files with the same name. You do need to make sure it has the correct format though and has a time value that is valid (for example 358500 would not be good, since 35h85 is impossible)

An example: lets say your DelisID is xxxxx, your depot code ##### and that you made this file on the 13th of August 2019, it could look like this:



2.D. DPD Parcel number counting

DPD IT will provide you with a range of parcel numbers. Each label (and thus, each parcel) needs to have it's own parcel number. Begin with the first number of your range and count up every time you make a label. Once you reach your final number, it's important that you don't keep counting but that you reset your counter back to the first number of your range.

If you notice however that such a reset occurs in a period shorter than 12 months, the instructions are the same, but you would also have to contact DPD IT as soon as possible, since we will have to give you a larger range. Your range should be large enough to last at least 12 months.


2.E Transferring EDI files to DPD

EDI files must be uploaded to the DPD SFTP:
Your username will be the same as your DelisID, which will be given to you by DPD IT. The password will also be given to you by DPD after validation of the files. Make sure you upload the file using UTF-8 encryption to ensure proper processing of unusual characters such as ç, ê, â, etc.

It's important that you transfer the EDI on the same day that the physical scan happens at DPD. We have to receive the EDI the same day that the parcels arrive in our DPD network.


Please take into account the following:
Many SFTP clients, such as WinSCP amongst others, have a function called Transfer Resume. This is a function that will give your file a different name or an extra extension (like .filepart or .tmp) while it's uploading and only changes it to the proper name once the upload is complete.
Please make sure this option is deactivated when uploading EDI for DPD. Our SFTP server's script is unable to handle such temporary file names.


Further chapters can be found below.

Ingediend door Dirk-Jan Dirix op di, 30/07/2019 - 14:58