Anatomía de un segmento DEX: identificador de bloque, separador asterisco y valores

DEX y EVA-DTS: cómo se lee la auditoría de una máquina expendedora

Acepta pagos con tarjeta, contactless y wallets digitales en tus máquinas expendedoras y micromarkets. Sin efectivo, sin complicaciones.

Esta es la versión técnica. Si lo que quieres es entender para qué sirve el DEX y qué te aporta operando máquinas, empieza por esta otra guía.

Aquí vemos qué hay dentro del archivo y cómo se parsea.

DEX y EVA-DTS no son exactamente lo mismo

Se usan como sinónimos y conviene precisar, porque al integrar sí importa.

DEX es el formato de recolección de datos de auditoría y eventos de máquinas expendedoras. Surgió a finales de los ochenta impulsado por los embotelladores, y NAMA lo incorporó a su norma VDI 1.0, anunciada en 2009.

EVA-DTS es el estándar de la European Vending Association para transferir datos de auditoría y configuración entre dos dispositivos. Se apoya en el estándar de comunicación DEX/UCS.

Ojo con un detalle que confunde a quien llega desde el lado retail: DEX nombra dos cosas distintas. Una es esta, la de vending. La otra es un EDI de entrega directa en tienda, donde el distribuidor manda facturas y notas de crédito al minorista en la puerta trasera (DEX/UCS), con su hermano NEX/UCS para la comunicación entre oficinas. Si buscas documentación a ciegas, vas a acabar leyendo del segundo.

Los dos protocolos de transporte

El estándar contempla dos protocolos de transporte: DDCMP y DEX/UCS.

Un matiz útil al integrar: se pueden usar los elementos de datos de EVA-DTS aunque el protocolo de transporte sea DDCMP. Es decir, el formato del contenido y el mecanismo de transporte son capas separadas y no siempre van del brazo.

DEX/UCS se apoya en señalización RS-232C de 0 a 5 VDC, según la define EVA-DTS.

Estructura del archivo

Esta es la parte que de verdad necesitas para parsear.

Un reporte de auditoría es un archivo de segmentos de datos en ASCII, cada uno terminado con CRLF.

Cada segmento se compone de elementos de datos individuales separados por asterisco.

Cada segmento arranca con un identificador de bloque: dos caracteres y uno o dos números. Por ejemplo VA1, CA3, CA10.

Un segmento de venta se ve así: VA1*4550*2450. Y uno de venta gratuita, en forma de CA3, lleva varios valores separados por asteriscos.

Tómalo como ilustración del formato, no como referencia de campos. Qué significa exactamente cada posición dentro de cada bloque está en el diccionario de datos de la especificación, y no se puede deducir del ejemplo.

Tipado de los elementos

Cada elemento de datos está tipado. El diccionario de datos identifica el tipo con un código de dos caracteres, por ejemplo AN para alfanumérico.

Esto importa al parsear: no todos los campos separados por asterisco son numéricos, y asumir que sí es una fuente clásica de errores con los identificadores de producto.

Dónde conseguir la especificación

Aquí va la advertencia práctica: no intentes reconstruir el diccionario de campos a partir de ejemplos sueltos de internet. Vas a acertar en los bloques comunes y a equivocarte justo en los que importan.

La fuente es el documento de EVA-DTS de la European Vending Association. Dos cosas a tener en cuenta: la versión 6.1.1 es de diciembre de 2012 y la 6.1.2 está fechada en marzo de 2016. Ninguna de esas dos es necesariamente la vigente, así que verifica la versión actual con la EVA antes de fijar tus definiciones de campo.

Existen librerías abiertas de parseo que sirven para arrancar y para contrastar interpretaciones. Trátalas como punto de partida, no como especificación.

Lo que DEX no te va a dar

No es un canal de pago. Si lo que buscas es cobrar, el camino es MDB y es otro conector, otro bus y otra lógica. Está detallado en cómo funciona el MDB.

No es tiempo real por diseño. El archivo es una instantánea del momento de la lectura. La frecuencia la pone el transporte, no el formato.

No está garantizada la uniformidad entre fabricantes. Los bloques comunes suelen estar, pero la riqueza del dato varía por modelo. Cualquier integración seria necesita probar contra los equipos reales del parque, no contra un ejemplo.

Integrarlo sin construirlo todo

Montar un lector DEX propio, su transporte y su parser es un proyecto en sí mismo, y rara vez es el proyecto que querías hacer.

Si lo que necesitas es que tu sistema hable con la máquina sin que tú implementes las capas de abajo, eso es lo que resuelve TERPAPay: la terminal se encarga del lado de la máquina y tu sistema trabaja contra una interfaz manejable.

Para ubicar DEX frente al resto de protocolos, está el comparativo completo.