Select Page
Modelo OMA en el LUCIA. Capítulo 5. Principales clases. Principales niveles

Modelo OMA en el LUCIA. Capítulo 5. Principales clases. Principales niveles

Finalmente, luego de cuatro capítulos llegamos a entrarle al modelo. En este penultimo capítulo revisaremos las principales clases existentes y que son la columna vertebral del modelo. No es que sean las clases más importantes, eso es algo muy difícil de definir, pero al menos serán las clases que de seguro le ayudarán a tener un eje de desarrollo.

Como propuse en el capítulo 3 de esta serie de artículos, si está comenzando en el modelo OMA le sugiero que se concentre en el BIP Declaration y eso haremos aquí. El BIP Declaration es la subselección del modelo completo en donde se ha hecho un primer filtro de los elementos del modelo que son necesarios en cualquier declaración del privado a la aduana.

Aquí deberíamos encontrar elementos para representar cualquier tipo de importación, exportación, manifiestos de ingreso, cargas, transitos o lo que sea que el flujo de la información sea del sector privado a la aduana.

En mi experiencia normalmente este tipo de declaraciones tienen 2 niveles. Un cabezal y un detalle de líneas donde se detallan las mercaderías involucradas. En algunos casos las declaraciones de importación tiene solo cabezal o sea, solo permitiendo un tipo de mercadería por declaración, en algunas otras ocasiones hay un subnivel en las líneas donde se detalla más concretamente item a item las mercaderias. En resumen uno puede hacerse la idea de que nuestras declaraciones tienen entre 1 y 3 niveles, con 2 niveles como lo más representativo.

En el modelo OMA y en particular en el BIP Declaration hay dos columnas , una para los DIP con foco en importaciones y exportaciones y otra para los DIP enfocados en cargas. Como ya mencione anteriormente, en natural que en el proceso de construcción de un MyIP se puedan mezclar estos DIPs por lo que no sería raro que finalmente tenga las dos líneas de desarrollo en su MyIP.

Veamos las clases que están involucradas

42A Declaration

[imagen]

Es en definitiva la raíz de cualquier declaración, en términos informáticos sería el root. Cualquier modelo basado en el BIP Declaration, su primer nivel es siempre la clase 42A Declaration.

67A GoodsShipment

[imagen]

Representa los movimientos de mercadería que son un mismo envio, aunque no necesariamente enviados todos juntos. Esta clase es ‘hija’ de Declaration y representa entonces los datos del o de los envíos.

68A GovernmentAgencyGoodsItem

[imagen]

Government Agency Goods Item. También conocido entre los amigos como ‘GAGI’ para simplificar un poco.

Es en definitiva las líneas de la declaración, detallando en ellas las mercaderías declaradas. Es ‘hija’ de GoodsShipment

28A Consignment

[imagen]

Clase específica para reflejar todo lo relacionado con el consignador y un consignatario. Esta clase es ‘hija’ de Declaration

29A ConsignmentItem

[imagen]

Nuevamente es un detalle de items, pero ahora como clase ‘hija’ de Consignment.

23A Commodity

[imagen]

Son los detalles propios de una mercadería. En este caso, la clase Commodity la podemos encontrar tanto como ‘hija’ de GovernmentAgencyGoodsItem (GAGI) como de ConsignmentItem.

En el capitulo 2 de esta serie habia mencionado que la semántica de una clase o elemento no se daba solo por la definición hecha para esta sino que además depende de en donde se encontrara en el árbol jerárquico del modelo. Esta clase Commodity es un buen ejemplo, la podemos encontrar tanto en la rama de GAGI como en la rama de ConsignmentItem y es en definitiva, la misma clase.

Gráficamente lo podemos ver más claramente aquí en esta captura de pantalla de la herramienta GEFEG
[imagen]

Aquí entonces podemos ver las dos columnas más comúnmente encontradas. Por un lado tenemos la rama Declaration > Consignment > ConsignmentItem > Commodity y por otro lado tenemos la rama Declaration > GoodsShipment > GAGI > Commodity. La primera pensada para los DIP con foco en cargas , la segunda para los DIP con foco en importaciones y exportaciones.

Con estos niveles Ud ya tiene para al menos no perderse. Si lo que se busca es modelar algo respecto a las mercaderías, pues lo más probable que lo que precise se encuentre en la clase Commodity y si es información del proceso, entonces seguramente lo encuentre en Declaration. No es que con estas clases ya tiene para todo lo que se le ocurra, pero muy probablemente las va a precisar, por lo que comenzar con alguna de estas dos columnas es lo más recomendable.

Se lo que está pensando ahora. ¿Preciso cuatro niveles en mi jerarquía? Considerando que lo más probable que ud comience desde un modelo nacional que tiene dos niveles, Cabezal y líneas. Pasar a cuatro niveles parece un cambio insalvable.

Sin embargo no es tan grave como parece. Aunque el modelo propone estos 4 niveles jerárquicos como base para una declaración, no especifica nada respecto a las cardinalidades de las relaciones entre estos niveles. Me explico, la relación Declaration > GoodsShipment es una relación jerárquica donde GoodsShipment es hija de Declaration pero queda a nivel de la implementación definir la cardinalidad. La cardinalidad de una relación entre dos clases es un número mínimo y número máximo de ocurrencias en esa relación. Es decir, uno puede especificar que el mínimo de GoodsShipment por cada Declaration es 0, con lo que se está especificando que podrian haber Declaration sin ningún GoodsShipment. Pero también se puede especificar un mínimo de 1, con lo que obligatoriamente, por cada Declaration habrá al menos un GoodsShipment.

Por el lado del máximo sucede lo mismo, si el máximo es 9999 o cualquier otro número, entonces no podran haber en sus declaraciones mas de 9999 GoodsShipment por cada Declaration. Y finalmente, el truco está en que si se especifica que el mínimo es 1 y el máximo también es 1, lo que se está indicando es que por cada Declaration habrá siempre un y solo un GoodsShipment .

Esto tiene un efecto, si la relación de Declaration y GoodsShipment es minimo 1 y máximo 1, en la practica lo que sucede es que el nivel de GoodsShipment se une al nivel de Declaration y por lo tanto ya no son 4 niveles sino solamente 3.

Esta misma lógica aplica a todas las relaciones de clases y en particular también para las relaciones de GoodsShipment con GAGI y de GAGI con Commodity. Marcando estas relaciones con una cardinalidad de mínimo 1 y máximo 1 lo que se logra es quitar niveles.

En consecuencia, por las que el modelo propone estos 4 niveles, en la práctica al momento de la implementación estas pueden ser reducidas hasta incluso un único nivel, acercando entonces tu intención de MyIP a la realidad de la que parte.

Modelo OMA en el LUCIA. Capítulo 3. BIP, DIP y MyIP

Modelo OMA en el LUCIA. Capítulo 3. BIP, DIP y MyIP

En el capítulo anterior había llegado hasta plantear el problema de que no alcanza con hacer un mapeo elemento a elemento sino que además hay que considerar las clases y la jerarquía del modelo. Para comprender mejor este punto hablare de algunas definiciones y presentare el concepto de BIP, DIP y los MyIP y con ello nos metemos de lleno en los aspectos técnicos del modelo. Por fin!

BIP

Por sus siglas en inglés, Base Information Package. O según mi propia traducción al español, Modelo Base. Cada modelo base, BIP, es una primera subselección de modelo OMA orientado en la operativa que intenta representar. Entonces, a nivel más abstracto posible el modelo OMA es una enorme colección de elementos, clases y jerarquías que se han estandarizado y armonizado. Cada modelo base hace una primera clasificación de estos elementos en la función que se pretende usar.

Existen actualmente en el modelo 5 BIP. 2 de ellos son los más fáciles de captar. El BIP Declaration y el BIP Response y son los 2 BIP que yo le recomendaría estudiar primero si es que son sus primeras aproximaciones al modelo OMA.

BIP Declaration

[imagen]

El ‘Declaration’, incluye los elementos y clases necesarias para cualquier comunicación ‘Privado -> Aduana’. Allí deberíamos poder encontrar cómo representar cualquier cosa que se declare en la aduana. Ya sean importaciones, exportaciones, cargas de ingreso, cargas de egreso, datos del almacenamiento, modificaciones de declaraciones previas. O sea, cualquier declaración, cualquiera sea su tipo o naturaleza es en definitiva una declaración que se debería mapear el BIP Declaration. Haciendo de los BIP, el más importante o al menos el primero al que se le debería prestar atención en un proceso de aprendizaje.

BIP Response

El BIP Response es el opuesto. O sea, todo lo que la aduana le informa al privado. Ya sea en respuesta a una declaración con eventuales errores en la declaración, o la aceptación de una declaración o la notificación del resultado de una inspección o en definitiva, cualquier información que va de la Aduana hacia el privado.

Una nota, no es necesario que sea una respuesta a una declaración. El nombre de ‘Response’ induce a pensar que es la respuesta a una declaración y no es necesariamente así. En el BIP Response puede incluir notificaciones que se originan en la aduana sin ser en respuesta a nada en particular.

BIP Intergov

Luego tenemos 2 más específicos. Intergov y LPCO. El BIP Intergov es un poco extraño. De hecho me parece que hasta sobra. Es el más chico de todos los 5 BIP y teóricamente modela la información que se intercambia entre agencias del estado. Ya sea del mismo estado o de otros estados.

Así en el BIP Intergov vamos a encontrar los intercambios que se realizan en el grupo MODDA del Mercosur. Como vimos antes, este proyecto del Mercosur busca definir un modelo de datos para intercambiar los datos de las declaraciones aduaneras entre los países miembros del Mercosur. Pero hay cierta información que es interesante intercambiar, pero que no es parte de la declaración. Un ejemplo típico, el riesgo de una declaración o el resultado de una inspección. Esta información es muy útil para intercambiar, que Argentina le informe a Brasil que una declaración es riesgosa o no según sus propios criterios de evaluación, seria muy util para Brasil. Así también si una declaración fue verificada por valor también sería interesante intercambiar entre los países.

Pero esta información, el riesgo y los resultados de las inspecciones no son parte de la información que podrías encontrar en el BIP Declaration. Recordemos que el BIP Declaration es todo lo que el privado informa a la aduana y es claro que en este caso el riesgo no es algo que el privado declare. Es información que es propia de la Aduana.

Sin embargo, el BIP Intergov es tan pequeño y lo más importante que tiene es una propiedad específica del Intergov que es que como parte del Intergov se pueden incluir un Declaration o un Response. O sea, como parte de los datos que se intercambian entre dos países o dos agencias de un país, están en definitiva las declaraciones y las respuestas.

O sea, resumiendo. El Intergov lo único que es es un BIP que tiene uno o varios Declaration y ademas , algún que otro datos adicional que se precisa intercambiar.

Pero realmente son tan poquitos estos datos adicionales, que en mi opinión se merecería hacer una extensión de la definición de Declaration y agregarle no solo lo que el privado declara a la aduana sino además, información complementaria que aporta la propia aduana a esas declaraciones.

Para mi se simplifica un poco , se quitara un BIP que no se justifica y confunde más de lo que aclara.

¿No le quedó claro que es el Intergov?

Ese exactamente es mi punto. Confunde más de lo que aporta. Quedaría mucho mas simple si los datos del riesgo o de las inspecciones los pudieras encontrar en el BIP Declaration, junto al resto de los datos de la declaración y no tener un BIP específico para estos pocos datos.

BIP LPCO

El BIP que quiere, pero no puede.
[imagen]

Para arrancar, LPCO significa por sus siglas en inglés, ‘Licences, Permits, Certificates or Others’ que ahora que me doy cuenta también son las siglas en español!

El objetivo de este BIP es modelar todos esos certificados que emiten otras agencias del gobierno que son de interés al momento de cruzar una frontera. Certificados de Origen, de salubridad, sanitarios, fitosanitarios y otro tanto de permisos y papeles que andan en la vuelta.

Sin embargo, es de los BIP existentes el menos desarrollado, pues compite en el mundo con muchos otros modelos mucho más maduros que el modelo de la OMA.

Por ejemplo. Si ud es de un país de la ALADI, tal vez conozca el Certificado de Origen ALADI. Este certificado es emitido por cada país de origen certificando, obviamente, el origen de las mercancías y tiene un formato basado en un XML inventado por la propia ALADI. Lo correcto, al menos desde el punto de vista de la OMA, sería que este formato de intercambio de ALADI este basado en el modelo de la OMA. El problema es que el COD ALADI tiene más de 15 años y sería muy complicado cambiar el formato solo para alinearse al modelo OMA.

Las ventajas si lo hicieran sería que el COD ALADI podría ser más portable y compatible con otros certificados de origen de otras regiones. Pero el costo de cambiar el formato es enorme y dudo mucho que los países de la ALADI luego de tantos años con este formato acepten de buenas cambiar el formato al recién llegado modelo de datos de la OMA. Yo les recomendaría que si lo hagan, pero no creo que me hagan caso.

Otros certificados internacionales tienen otros modelos , por ejemplo también está el modelo CCTS. Impulsado por las Naciones Unidas y que responde a muchas industrias y también, tiene varias décadas de experiencia e implementaciones.

Por ello, el BIP LPCO es de los menos desarrollados y realmente nunca vi una discusión sobre el modelo LPCO. Tengo si notas de que ha sido usado en algunos proyectos como el eTIR. Pero a diferencia del CCTS que tiene cientos, el modelo LPCO tiene solo algunas implementaciones.

En definitiva, aunque vive y lucha. El BIP LPCO tiene poco uso pues compite con otros modelos mucho más maduros y extendidos en la industria.

BIP Metadata

[imagen]

Finalmente llegamos al BIP Metadata. Si ud está comenzando a estudiar el modelo OMA, Ignorelo. Pase de largo, ni se moleste a leer este punto.

El BIP metadata busca definir los datos propios del intercambio de información. De quién es el mensaje, hacia quien va, que contiene y otros datos relevantes al mensaje en sí y nada que ver con la posible declaración que transmite.

Uno se pregunta porque la OMA hace un modelo de datos que son referentes a la comunicación, ¿no? Es una buena pregunta y yo no tengo respuesta más que porque siempre lo tuvo y es heredado mas por compatibilidad que por otra cosa.

Hoy toda esta información es más propia de la implementación, por ejemplo si uno está implementando el modelo utilizando mensajes XML con servicios SOAP con un canal HTTPS, toda esta información seria básicamente , la URL que se está consumiendo, el método, el WSDL, la firma electrónica para el handshaking. Entre todos estos datos, uno tiene todo lo necesario para saber quién está consumiendo el servicio, que pretende declarar ,a quien, cuando y como está firmado.

Igualmente el BIP Metadata es muy simple y poco pretencioso, por lo que tampoco molesta. Si ya logro hacer un mapeo del BIP Declaration, el agregar el BIP Metadata solo le agregaría unos pocos elementos a su modelo. Por lo que aunque poco aporta, poco molesta.

Por supuesto, todo lo emitido en este capítulo (y en todos los capítulos) corre por mi cuenta y es mi opinión personal. Seguramente la enorme mayoría de los profesionales que trabajan en el modelo no compartan algunas de mis opiniones. Le dejo al lector, luego que se forme en el modelo , llegar a sus propias conclusiones. Por veces y sobre todo en los proyectos que buscan la armonización y la estandarización, es necesario sacrificar la perfección teórica del modelo en pos de facilitar justamente lo importante del proyecto. La armonización y la estandarización.

DIP

[imagen]

El siguiente paso en acercamiento del modelo teórico a algo práctico y usable son los DIP. Por sus siglas en inglés Derived Information Package. O en español, Modelo Derivado

Un DIP entonces es una selección más específica de alguno de los 5 BIP. Si ud lo que quiere es hacer un modelo de importación, entonces lo primero que precisa es encontrar o crear un DIP que tenga la selección de los elementos existentes en el BIP Declaration que sean relevantes para un modelo que pretende representar los datos de las importaciones.

Podemos encontrar publicados por la OMA varios DIP. Algunos basados en Declaration, otros en LPCO, otros en Response. No hay ningún DIP basados en Intergov ni en Metadata publicados oficialmente por la OMA. Tal vez en los párrafos anteriores encontrara un explicación al porque aún no hay DIP Intergov ni Metadata.

Unas líneas más arriba decía que se deben encontrar o crear el DIP. Bastante confuso. Ha sido un tema largamente discutido, en alguna documentación técnica se puede encontrar como una regla que cualquier implementación debe estar basada en un DIP y si un país quiere implementar el modelo, debía ajustarse a los DIP existentes. Uno teóricamente no podía crearse un modelo basándose directamente en el BIP Declaration.

Recordamos que en el BIP Declaration tenemos los elementos y clases para representar cualquier tipo de declaración aduanera. Ya sean importaciones, exportaciones, manifiesto de carga de entrada o salida o básicamente, cualquier cosa que el privado tenga que declarar a la aduana.

Por lo que si uno está pensando en comenzar a modelar un proceso de importación, todos los elementos y clases que precisemos los deberíamos tomar del BIP Declaration.

Sin embargo, aunque la documentación en ciertos casos es contradictoria, la teoría decía (y uso la conjugación en pasado) que no debías basarte directamente en el BIP, sino en algún DIP existente.

En el modelo publicado por la OMA hay 2 DIP que son el centro de todo. El DIP GoodsDeclaration y el DIP CargoReport. Ambos están basado en el BIP Declaration, el DIP GoodsDeclaration representa las operaciones de Impo, Expo y Tránsito y el DIP CargoReport las operaciones de manifiesto de entrada o salida (permítanme por ahora la simplificación).

A modo de resumen. Por ahora tenemos entonces el modelo de datos de la OMA, que tiene todo un catálogo de elementos y clases. Tenemos el BIP Declaration que tiene únicamente lo que es útil para las declaraciones del privado y tenemos el DIP GoodsDeclaration, que tiene solamente lo necesario para específicamente las declaraciones de impo, expo y tránsito. Entonces, si mi objetivo inicialmente es implementar el modelo para las importaciones, los elementos que preciso los debería encontrar en el DIP GoodsDeclaration.

Pero esto es la teoría. Ahora, veamos la práctica.

La realidad es que las primeras implementaciones que se han hecho basadas en el modelo no se basaron únicamente en los elementos que se encontraban en los DIP, sino que se basaron directamente en los BIP. En la práctica lo que ha pasado es que los proyectos regionales o de otros países en vez de ir actualizando el DIP correspondiente se crearon un DIP propio con una selección de los elementos del BIP que precisaban. Lo cual yo al menos no lo veo mal.

Es muy común que en una declaración de importaciones se pidan adicionalmente alguna información que es específica del manifiesto o de algún certificado LPCO y cada vez esto es más común, al generalizarse las implementaciones de ventanillas únicas.

La teoría que busca esta regla es correcta, lo que pretende es evitar que si cada país implementa sus mensajes y sus declaraciones tomando cualquier combinación de elementos del BIP, entonces se tendrán tantos tipos de mensajes diferentes que entonces el objetivo de armonizar y estandarizar se diluye.

Pero por otro lado la realidad se ha impuesto y hoy aunque es recomendable seguir o tener muy en cuenta los DIP existentes, no es estrictamente necesario apegarse a ellos.

Para ejemplificar, la Unión Europea ha creado su propio DIP, tengo entendido que EEUU tambien lo hará. Mercosur creó su DIP MODDA y la tendencia es que cada región o implementación va generando sus DIP a medida que se van definiendo.

En mi opinión lo que sucederá en el futuro es que los pesos económicos y políticos de las regiones y de las implementaciones ya existentes tendrán su efecto sobre las nuevas implementaciones. Quiero decir, si ud quiere modelar un proceso de importaciones en su país y el principal socio comercial es la Unión Europea, pues yo le aconsejaria tener muy en cuenta el DIP de importación creado por la EU para su propia implementación. Aunque el modelo le permite más libertades , seguramente sus despachantes y agente de comercio estarán muy contentos que los procesos de exportación en su país sean compatibles con los procesos de importación europeos.

MyIP

[imagen]

Finalmente, el objetivo de la implementación del modelo es seleccionar del DIP correspondiente los elementos necesarios para su Aduana. Allí encontrara entonces todos los datos que se usarán en cualquier tipo de declaración del privado su Aduana. En caso que su MyIP esté basado directa o indirectamente en el BIP Declaration, las respuestas o comunicaciones que la Aduana enviará, en caso que si MyIP este en este caso basado en el BIP Response.

Ya para esta etapa se debería tener claro las estructuras básicas del modelo. Pero para llegar a eso, seguramente precisa ayuda más allá de revisar y revisar de arriba a abajo las planillas. Por ello en el próximo capítulo detallare las opciones de asistencia presencial y virtual que brinda la OMA.

Modelo OMA en el LUCIA. Capítulo 2. En ruta, plan A. Ruta panorámica, Mercosur y MODDA

Modelo OMA en el LUCIA. Capítulo 2. En ruta, plan A. Ruta panorámica, Mercosur y MODDA

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
[imagen]

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
[imagen]

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
[imagen]

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
[imagen]

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.
[imagen]

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)
[imagen]

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

[imagen]

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.

Implementación del Modelo de datos de la OMA en el sistema LUCIA de la aduana de Uruguay

Implementación del Modelo de datos de la OMA en el sistema LUCIA de la aduana de Uruguay

La primera vez que leí sobre el modelo de datos del la OMA fue en el año 2013. Cuando estábamos en CONCEPTO diseñando y preparándonos para lo que en el futuro sería la VUCE de Uruguay. Esta serie de artículos busca compartir la experiencia del proceso desde el comienzo mismo, hasta el hito de la puesta en producción de un proceso aduanero basado en el modelo OMA.

Una de las mayores dificultades que enfrente en este proceso fue el acceso a la información y a las experiencias previas. Algo contradictorio se daba en el modelo, por un lado leía maravillas y lo encontrabas como recomendación en muchos lados, pero la información práctica y concreta estaba casi que escondida.

Es por ello que en su momento me comprometí a mi mismo que si un día se ponía en producción algo utilizando el modelo de datos de la OMA en Uruguay, publicaría todo el proceso vivido para no hacer lo mismo que yo mismo criticaba en mis primeros pasos.

En esta serie de artículos entonces lo que pretendo es compartir el proceso de adquirir los conocimientos que nos permitieron cumplir con éxito el primer paso de la puesta en producción, obviamente que desde mi propio punto de vista y opiniones. Estos artículos entonces deben ser tomados como una experiencia compartida y no como un curso de capacitación del modelo, también me reservo el derecho a estar equivocado!

Capítulo 1. Primeros pasos, primeras piedras

Como buen informático, lo primero que hice cuando quise saber más sobre el modelo de datos de la OMA fue Googlearlo!

Lamentablemente ni en la primera página ni en la página dos ni en ninguna pagina encontré mas alla de titulares o documentación gerencial de alto nivel. Nada! Tal vez fue un claro caso del efecto Streisand. Este efecto dice que si pretendes esconder algo, el esfuerzo de intentar esconderlo genera una curiosidad que hace a ese algo aun mas preciado de ser encontrado. Algo así como una anti-campaña publicitaria. Ya de por si esto es una gran contradicción, el modelo era recomendado por todos lados, pero no estaba publicado en ningún sitio.

Con el tiempo entendí dos factores que explican esto. Lo primero a tener en cuenta es que el modelo es propiedad intelectual de la OMA, lo que hace que la distribución del modelo se haga por vías restringidas y no esté disponible para ser estudiado libremente. Otro factor a mi entender, es que las pocas personas que conocen el modelo en profundidad no tienen como tarea asignada el apoyo a la divulgación del mismo. Ya que finalmente estos expertos son funcionarios aduaneros y sus tareas refieren a sus propias aduanas y no a dar soporte a un público en general.

Esto hace que la divulgación del modelo a nivel técnico haya sido y en general sigue siendo muy escasa y limitada. Generando entonces un fuerte desconcierto a quien intenta acercarse al mismo en una etapa inicial del aprendizaje.
[imagen]

Un oasis en el desierto de la información

Cuando me encontraba en el más profundo de las decepciones y ya dispuesto a desistir y catalogar al modelo de datos OMA como simplemente un monto de frases hechas y marketing de consultores internacionales. Carente de todo contenido o uso práctico, fue cuando se dieron dos hechos que me volvieron a poner en la ruta correcta.

El primero fue el pedido de la Dirección Nacional de Aduanas de Uruguay para apoyarlos en el análisis del modelo de datos. La Aduana de Uruguay estaba a su vez en el mismo proceso de comprensión del modelo y como miembro de la OMA tiene acceso a los documentos técnicos que componen la distribución del modelo. Por lo que por medio de nuestro cliente, finalmente accedimos a las preciadas planillas excel que son en sí, el medio de publicación del modelo.

Esto nos permitió tener finalmente una visión más clara de lo que el modelo era técnicamente y además, con términos técnicos más precisos, encontrar referencias de alguna caso de uso real. En particular, la documentación de la Aduana de Nueva Zelanda, que publica en internet todos sus mensajes en el siguiente link.

Siempre me habían caído bien los Kiwis, no se porque. Es como que no conozco a nadie que le caigan mal, será porque no tienen vecinos terrestres con quienes generar rivalidad. Pero desde entonces tengo un motivo real para apreciarlos. La publicación de su implementación fue sin duda un faro para guiarse. El ver concretamente el resultado de la implementación del modelo OMA en un país y poder estudiar específicamente cada tipo de mensaje para cada tipo de operación aduanera, fue sin duda una hallazgo clave para comprender el modelo.
[imagen]

Años después tuve la oportunidad de conocer al representante de Nueva Zelanda en las reuniones del modelo en la sede de la OMA en Bruselas, en su momento personalmente la agradecí que tengan toda su documentación publicada y aprovecho nuevamente estas líneas para volver a agradecerles. Realmente el compartir esta información es de mucha ayuda para quienes se inician en el modelo. Gracias Kiwis!!

Otro país que publica su modelo, aunque no esté abierto y requiere un registro previo son los Países Bajos. Ellos tienen un portal dedicado a su ventanilla única en https://odb.belastingdienst.nl/

El portal está orientado a dar soporte a las empresas que deben enviar mensajes a la Aduana de ese país, yo me registre (con ayuda del traductor de google) y en la solicitud aclare que no pretendía hacer declaraciones en los Países Bajos, que únicamente quería estudiar la documentación disponible y con ello me dieron las credenciales necesarias para acceder.

Con estas dos implementaciones de referencia y con acceso al modelo la cosa cambio y recién entonces teníamos todo lo necesario para ir paso a paso comprendiendo el modelo y su uso.

Como conclusiones de este primer capítulo me gustaría resumir lo siguiente:

  • El modelo se distribuye muy restrictivamente a mi entender debería haber alguna versión de acceso libre, no tiene mucho sentido que el objetivo del modelo sea la facilitación de la actividad privada en las aduanas y el modelo no tenga un canal de publicación de estudio y análisis para el sector privado.
  • Las buenas practicas de Nueva Zelanda y Países Bajos debería ser replicada por todas las implementaciones. Pues si el objetivo es estandarizar, nada mejor que husmear lo que están haciendo otros para intentar alinearse a ellos.

Ya para complementar, tiempo después se publicaron dos nuevas implementaciones. La Unión Europea tiene un sitio específico para compartir su EUCDM (Modelo Europeo basado en el modelo de la OMA)

https://svn.taxud.gefeg.com/svn/Documentation/EUCDM/EN/index.htm

Y Brasil que también tiene un portal con documentación de su implementación

https://val.portalunico.siscomex.gov.br/docs/api/#introdu-o

Y si Ud es funcionario de una aduana entonces puede acceder a credenciales que le permiten entrar al canal de distribución oficial del modelo en este link.

Lamentablemente entonces no hay forma de acceder libremente al modelo para su estudio si no por medio de una Aduana miembro de la OMA, eso ayudaría mucho en su promoción.