What Is a DEX File? A Vending Operator's Guide

A DEX file is the audit record a vending machine produces about itself: how many vends it has made, how much money it has taken, what each selection sold and at what price, and which errors it has logged. The format is DEX/UCS, carrying data written to the EVA-DTS standard, and once you can read one you no longer have to count a machine by hand to know what it did since the last visit.

Where the name comes from

DEX stands for Direct Exchange, and UCS for Uniform Communication Standard. The pair was borrowed from the grocery industry in the early 1990s, when the National Automatic Merchandising Association needed a way for route drivers to pull a machine's figures without opening a mechanical counter. The data inside the file follows EVA-DTS, the European Vending Association Data Transfer Standard, which is why you will see both names used for what is, in practice, the same thing. People say "DEX file", "DEX read", "DEX audit" and "EVA-DTS file" interchangeably.

Almost every snack, soda and food machine built in the last twenty-five years can produce one. Older machines expose it through a DEX port on the controller board; newer machines and most card readers and telemetry devices produce the same file and send it out over the cellular network.

What is in a DEX file

Open one in a text editor and you will see a plain text file, one record per line, each record a code followed by fields separated by asterisks. The envelope starts with DXS and ends with DXE, and the real content sits between ST and SE segments. A short one looks like this:

DXS*1234567890*VA*V0/6*1
ST*001*0001
ID1*VMC12345678*MODEL-X*1234
ID4*2*USD
VA1*1842750*31204*49800*842
CA2*1250300*21855*31200*521
PA1*10*125
PA2*412*51500*8*1000
PA1*12*150
PA2*96*14400*2*300
EA1*EGS*20261014*0812
G85*A1F0
SE*12*0001
DXE*1*1

The record types that matter to an operator:

Interval and cumulative counters

Most of the counting records carry two sets of numbers: a figure since the machine was initialised, and a figure since the last reset. A read usually resets the interval counters, so the "since last reset" fields give you exactly what happened between two visits, and the "since init" fields let you catch a missed read. If your software only looks at cumulative counters, it should take the difference between consecutive files and treat a negative difference as a board reset or a swapped controller, never as negative sales.

How a DEX file gets from the machine to you

Three paths are common, and most routes use more than one.

1. At the machine. The oldest way is a handheld plugged into the DEX port during the visit. A more common modern equivalent is a telemetry device or card reader that stores the read and hands it to a phone over Bluetooth or Wi-Fi, or lets you export it as a file. Either way you end up with a .dex or .txt file per machine per visit.
2. Over the air. Card readers from Nayax, Cantaloupe, PayRange and others pull a DEX read from the controller on a schedule and upload it. Your operator portal then shows a stock level per coil, and some vendors expose that through an API so other software can fetch it.
3. Through an API of your own. If you run a telemetry box or a reader with a developer feed, the cleanest arrangement is a device that posts the raw file to an endpoint the moment it is pulled, so nobody has to carry a file anywhere.

What to do with it

The value of a DEX file is not the file; it is the three questions it answers without a count.

• What did each coil sell? Subtract the PA2 vends since the last visit from the last fill level and you have the current stock of every selection, before anyone opens the door. That is the basis of a pick list built in the warehouse rather than at the machine.
• How much cash should be in the box? CA3 minus CA4, or the cash-to-box field where the machine reports it, is what the driver should pull. Compare it with what is actually counted and a shrink problem shows up on the first visit instead of the quarterly review.
• Why did the machine stop? The EA events are timestamped. A machine whose sales fell to zero three days before the visit, with a bill validator jam logged at the same hour, is a repair, not a dead location.

The parts that go wrong

DEX is a standard with dialects. Expect the following, and prefer software that treats them as warnings rather than failures:

• Some controllers omit ID4, so the reader has to assume a currency and decimal count. Others send it with a decimal count of zero in a currency that clearly has cents.
• Manufacturers add records of their own, or put extra fields on standard ones. A strict parser rejects the whole file; a tolerant one keeps the standard fields and flags the rest.
• A file pulled while the machine was mid-vend, or a cellular upload cut short, fails the G85 checksum. Discard it and pull again rather than guessing.
• Selection ids do not always match the number printed on the coil. Build the mapping once per machine and keep it.
• A controller swap resets every cumulative counter. Software that silently records a large negative vend count has not noticed.

More guides: all Adelyons guides