Continuando entonces con esta serie de artículos sobre la experiencia de la implantación del modelo de datos OMA en la Aduana de Uruguay, en este capitulo comentare los primeros avances cuando ya teníamos acceso al modelo y teniendo dos implementaciones de referencia.

En si, lo que se publicaba en su momento como el modelo de datos de la OMA, no era más que una planilla excel con una cantidad impresionante de definiciones de clases y atributos.

Por ejemplo, uno podía encontrar definiciones que les resultaban muy conocidas como ser el país de origen

Con lo que se obtiene un ID del elemento , en este caso el código 063. Una descripción, que está únicamente en inglés. Un tipo de datos, Alfanumérico de largo 2 y una referencia a un ISO, en este caso la ISO 3166.

La primera interpretación que uno hace del objetivo es el buscar un mapeo elemento a elemento partiendo como base el mensaje de la declaración local, buscando para cada elemento el correspondiente en el modelo OMA. O sea, donde para Uruguay tenía

se mapeaba al elemento 063 Country of origin, coded.

Esto en si no es el objetivo de una implementación del modelo OMA, pero es una excelente primera fase de descubrimiento. Este trabajo, el ir campo a campo de una estructura de datos que representa el modelo de datos local, en nuestro caso el mensaje de declaración de un DUA (Declaración Única Aduanera) nos permitió ir investigando los elementos del modelo, habituarnos a la terminología y de paso, encontrando las primeras inconsistencias.

Por ejemplo, ya en este mapeo de PAIS_ORIGE con el elemento 063 del modelo OMA despierta una incompatibilidad. En un caso se usa un numérico de 3 para representar al país de origen y en el modelo de la OMA se usa un alfanumérico de 2. En este caso la incompatibilidad es bastante simple de subsanar, el caso de PAIS_ORIGE lo que representa ese numérico de 3 es el código ISO 3166-1 que tiene tanto una codificación en 3 números o en 2 caracteres. Por lo que basta hacer un mapeo código a código y donde en un caso Uruguay es representado por el número “858”, en el otro es representado por el código “UY”

En este caso fue sencillo! Pero no todas las incompatibilidades son así de fáciles de subsanar. Sin ir más lejos, en Uruguay en ciertas operaciones se declara como país de origen un código para representar alguna de las zonas francas existentes, por ejemplo el PAIS_ORIGE “994” representa a la Zona Franca Florida.

En este caso, el uso de un código de país no estándar para representar el origen en una zona franca conlleva una incompatibilidad un poco más difícil de levantar.

Ese fue nuestro primer plan. Tomar la declaración del DUA de Uruguay e ir elemento a elemento buscando lo más parecido que existiera en el modelo OMA. Este era un buen plan para comenzar, pero tenía un problema. El modelo OMA no solo es una lista de definiciones sueltas, son en si una agrupación en clases jerárquicas y la semántica e interpretación de los elementos no solo se da por la descripción del elemento, pero también por ubicación de la clase y la jerárquica del modelo

Por ejemplo. En el modelo OMA encontramos un elemento

que fácilmente se puede mapear a cualquier dirección que tengamos en el DUA. Pero direcciones en el DUA podemos encontrar mas de una, la dirección del deposito , la dirección del proveedor, la del importador entre otras. Todas estas “direcciones” se mapean al elemento ‘239 Street and number/P.O. Box’, por lo que no alcanza con hacer el mapeo elemento a elemento, también es necesario incluir a qué clase del modelo. Las clases del modelo OMA son estructuras de datos que agrupan varios elementos con una misma entidad, por ejemplo, podemos encontrar la clase “Exporter” que representa a la entidad exportador

Aquí podemos ver que el exportador tiene entre el elemento ‘239 Street and number/P.O. Box’, pero ahora al estar en la clase “Exporter” no solo es una dirección. Es la dirección del exportador.

Pero el tema no termina aquí. La clase “Exporter” la podemos encontrar en el modelo en más de un lugar. La podemos encontrar en el cabezal de la declaración (Declaration)

pero también la podemos encontrar dentro de la clase GoodsShipment

¿Cual de las dos seria la correcta?. Así, en el modelo OMA, cada elemento lo podemos encontrar en más de una clase y cada clase en más de un lugar de la jerarquía del modelo.

Empieza a ser más confuso, ¿no? Ya el plan no es ir elemento a elemento, ahora se agregan otras dimensiones al mapeo. Ya no basta encontrar y entender un elemento, hay que entender que es la clase GoodsShipment o la clase Declaration para poder hacer un mapeo correcto.

Fue en este estado que decidimos ir por otra ruta.

La Ruta Panorámica

En paralelo al trabajo del mapeo del DUA de Uruguay habíamos comenzado a trabajar en el grupo de trabajo MODDA del Mercosur. Este grupo técnico del Mercosur buscaba hacer una evolución del sistema de datos INDIRA. El INDIRA es el intercambio de declaraciones aduaneras del MERCOSUR. Así cuando se hace una exportación de Argentina a Brasil, Brasil tiene vía el INDIRA la declaración de exportación hecha en Argentina y así poder cotejar los datos declarados en la importación en Brasil contra los datos declarados en la exportación de Argentina.

Esta es una excelente herramienta de análisis y evaluación de riesgo en el MERCOSUR y da muy buenos resultados. Sin embargo, dista de ser perfecto. La poca armonización de los datos y procesos aduaneros que hay en los países del bloque conlleva a que sea muy difícil procesar automáticamente los intercambios del INDIRA. Así como una expo desde un país se declara en cantidad de cajas, en la importación se declara como cantidad de palets. Haciendo que el tipo de bulto y cantidad difiere, aun cuando tanto la declaración de expo como la de impo estén perfectamente declaradas según las normas de cada país.

Este trabajo en el MODDA se decantó rápidamente a una nueva implementación del modelo OMA, solo que ahora, con una visión regional. Partiendo de la base del intercambio del INDIRA original, se busco el mapeo al modelo OMA para así estandarizar a nivel del Mercosur tomando el modelo OMA como modelo a seguir en el bloque.

Esta nueva ruta, no solo me llevo a conocer las capitales de Brasil y Paraguay que nunca había tenido la oportunidad de ir, sino también regresar a Buenos Aires que hacía tiempo evitaba! Me dirán provinciano, pero debo confesar que Buenos Aires simplemente me parece una ciudad demasiado grande!

Esta experiencia nos permitió trabajar en el mapeo del DUA con una visión mucho más regional y además Brasil ya estaba trabajando en su propia implementación, lo que aportaba entonces otro modelo de referencia para el trabajo.

Por lo que el trabajo de la implementación del DUA en Uruguay se colgó del trabajo del proyecto MODDA y el resultado fue que el mapeo del DUA no solo cumpliría el estándar del modelo OMA sino que además, sería estándar en la propia definición del modelo MODDA MERCOSUR.