Servicio de Intercambio Electrónico de Datos (Archivos EDI)

Proceso de intercambio de archivos EDI 810, EDI 858 y EDI 997

¿De qué se trataba este servicio?

Un cliente (trasnacional por cierto y prioritario para la Agencia Aduanal), importaba frecuentemente sus productos y accesorios para su distribución y comercialización en el país. Para ello, requería que su área de importaciones tuviera en tiempo real la información pertinente sobre el despacho de sus productos (es decir, su salida de las aduanas), y que esta información, estuviera en tiempo real cargada en su sistema informático (para dar continuidad a sus procesos internos). 

Entonces, el cliente o importador, viene ya trabajando con sus diferentes Agentes Aduanales el siguiente flujo de intercambio de información por cada operación/embarque:

*Esquema del proceso EDI

1. El cliente, en su servidor FTP, coloca para cada operación o embarque un archivo EDI 810 (que contiene los datos de la factura, y productos que ampara), así mismo, coloca una factura y una guía (BL) para que el personal humano entienda que está amparando dicho EDI 810 (ello, dado que si abrimos un archivo EDI, no son muy amigables para el ojo humano).

2. El Agente Aduanal recoge esos archivos (en especial el EDI 810), lo procesa (haciendo su proceso de despacho o desaduanización de mercancías), y genera como salidas de dicho proceso: un pedimento y un expediente aduanal (necesarios para todo cliente, sí), pero además, para este cliente le debe generar un archivo EDI 858 (Un archivo con datos del embarque en detalle, su clasificación arancelaria y demás datos relevantes al despacho). Este archivo finalemte. se lo debe enviar de regreso a su FTP del cliente.

3. El cliente periódicamente valida los archivos EDI 858 recibidos (validaciones de estructura), y contesta por cada uno con un archivo EDI 997 diciendo: "Sí, está correcto tu archivo Agente Aduanal" ó "No, está incorrecto en estas líneas o etiquetas". 

¿Y cuál era la problemática con este proceso?

No había un problema en este proceso, sino muchos problemas, entre los más relevantes esttaba:

- El personal de la agencia involucrado con la operación del cliente, (incluído el personal de la administración anterior de Sistemas), no entendía el proceso antes descrito. (Simplemente era "algo mágico que el sistema debía hacer de forma automática"); entendido, pero, ¿y cada que el cliente preguntaba sobre alguna inconsistencia en los archivos? o sobre un faltante? o pedía una aclaración?

- El cliente enviaba con cierta frecuencia archivos EDI 810 con errores, pero al no entender el proceso en la Agencia, nadie los detectaba. Era el mismo cliente al recibir los archivos EDI 858 que se quejaba por la información incorrecta que contenían.

- Con frecuencia los archivos EDI 858 se generaban con errores, o simplemente no se generaban.

- El desarrollador (proveedor externo de software), estaba desgastado, nadie le explicaba en realidad qué necesitaba la agencia o el cliente (de forma lógica), y el personal operativo (de seguimiento al despecho), le reportaba cosas diferentes a lo que el cliente necesitaba (por desconocimiento supongo).

¿Y cómo atacamos estos problemas?

Hubo de entrada que sentarse a estudiar el proceso, la estructura y contenido de estos archivos y las tareas que los soportaban; luego hubo que dibujarlo, entenderlo, o sea, analizarlo.

A la par hubo que "re-hacer" relaciones con el desarrollador del software, empezar a entenderlo, antes que querer exigirle cualquier cosa.

Teniendo algo de entendimiento, y una mejor relación con los desarrolladores, explicamos y capacitamos en el proceso al personal operativo involucrado, y comenzamos a solicitarles auditaran sus salidas de sus procesos antes de que el cliente las reportara.

Empezamos a trabajar en conjunto con el desarrollador en herramientas (reportes, pantallas, notificaciones automáticas), que nos dieran más visibilidad para autoaditarnos en los diferentes puntosclaves del proceso y poder entonces detectar desviaciones antes que el cliente.

Empezamos a tener reuniones con el cliente, y el desarrollador y usuarios operativos clave, para dar seguimiento a las escalaciones que había tenido el cliente e irle explicando nuestros avances en cuanto herramientas de autocontrol.

Al paso de los meses, estas reuniones se volvieron cada vez mas operativas (mas relacionadas con el tráfico y despacho en sí), y el personal de sistemas y de desarrollo, fuimos quedando fuera. (Salvo cuando reuqerían alguna nueva herramienta o modificaciones particulares a estas o para puntos muy en específico).Entonces, TI en ese sentido, nos avocamos a mantener la infraestructura y tareas automáticas funcionando y el proceso se estabilizó.