Oct 4, 2021 | General
La semana del 27/9 al 1/10 se realizó en Bruselas aunque con asistencia virtual la 61ª reunión del DMPT. Reunión de seguimiento y mantenimiento del Modelo OMA.
En esta oportunidad, realizamos la primera edición de la reunión Resumen y Comentarios de la 61ª reunión del DMPT, en español. El objetivo de esta webinar fue básicamente dos puntos, repasar y resumir lo ocurrido en 61ª reunión del DMPT pero en español y por otro lado, dar un espacio de a la comunidad de habla hispana para compartir experiencias y generar sinergia entre todos.
Realmente para haber sido la primera edición , estamos más que satisfechos. 35 registrados al evento de Aduanas y VUCEs de 7 países de la región. Uruguay, Argentina, Colombia, Costa Rica, Perú, Guatemala y República Dominicana. Durante el evento repasamos la agenda del DMPT sobre todo los puntos
– Resumen de los 50 DMR presentados por la UE
– Progresos y agenda de trabajo de la version 4.0 del modelo
– Avances del grupo de trabajo conjunto UPU-WCO
– Declaración de carga IMO, Armonización de declaración ferroviaria
– Nuevo formato de publicación del modelo
Durante el DMPT participaron 20 personas de 9 países manteniendo la cuota de participación de latinoamericanos. Eso es bueno! Será importante de cara a un , esperemos , pronto regreso a las reuniones presenciales el poder mantener la virtualidad de forma de facilitar el acceso desde nuestros países. Obviamente, las reuniones presenciales ganan mucho en capacidad de generar sinergia, sin embargo es sabida la dificultad para ir hasta Bruselas a una reunión de seguimiento. Esperemos que este buen aspecto de la virtualidad se pueda compatibilizar con las reuniones presenciales.
May 21, 2021 | General
Para Customs-hub haber recibido el pedido de apoyo en los trabajos que está realizando Brasil en su implementación del modelo OMA ha sido todo un gusto y honor.
Brasil es el primer país que comenzó su proceso de adopción del modelo, implementado su ventanilla única aduanera siguiendo este estándar. Como todo proyecto innovador, Brasil llevó el modelo un poco más lejos y adoptó la sintaxis JSON como su sintaxis. Desde entonces se ha convertido en un motor del impulso del modelo en la región, no solo generando la sinergia por su proyecto, sino además incorporando una nueva sintaxis como lo es OpenAPI/JSON.
Por ello, para Customs-hub es un enorme desafío entrar a este proyecto ya tan avanzado. Citando a su líder técnico, que amablemente nos dio su opinión sobre nuestras herramientas.
“[Customs-hub DMToolKit] es una herramienta muy buena. La curva de aprendizaje es muy fluida, la interfaz es más amigable y los recursos ofrecidos, al menos hasta el punto en que pude trabajar, son muy buenos.”
Su opinión es doblemente importante, no solo por su importancia como proyecto, sino además por la experiencia previa que Brasil ya arrastraba de años anteriores.
La confianza dada por Brasil nos redobla el compromiso de apoyar las implementaciones del Modelo de Datos de la Organización Mundial de Aduanas.
Más información sobre el proyecto de Ventanilla Única de Brasil lo puede encontrar aquí https://docs.portalunico.siscomex.gov.br/
May 12, 2021 | General
Durante el 60° reunión del grupo de trabajo del Modelo de Datos de la OMA (DMPT) realizado virtualmente la semana del 26 al 29 de Abril, Costa Rica presentó un conjunto de ampliaciones al modelo necesarias para dar soporte a las diferentes operativas que actualmente su Ventanilla Única de Comercio Exterior tiene.
Estas solicitudes de ampliación del modelo cubren temas técnicos muy variados, desde los certificados de exportación de productos Orgánicos, exportación de café y certificados fitosanitarios. Todos procesos que para Costa Rica son de gran importancia para su economía nacional. En total fueron 11 los pedidos (DMR) los cuales fueron todos aceptados tanto a nivel de la necesidad del negocio, así como de la propuesta técnica. Con apoyos muy variados de varios países, incluyendo Guatemala, México, Alemania, República Dominicana, Brasil, Jordania, China, Polonia, Filipinas, Suecia, Países Bajos y Canadá que demostraron un gran interés por estas mejoras planteadas por Costa Rica.
Para Customs-hub que a través de su director Alejandro Rinaldi apoyó todo el proceso fue un gusto ver como un equipo local de la VUCE logró pasar de recibir su primera inducción al modelo OMA a presentar técnicamente sus necesidades de ampliación. Esto es doblemente relevante pues no solo completaron exitosamente el proceso de comprensión del modelo, sino que lograron un nivel de autonomía que les permite encarar próximas etapas con ya una excelente experiencia ganada.
Todo el trabajo se hizo íntegramente en forma remota, dadas las circunstancias sanitarias que sufrimos a nivel mundial, pero aun en este contexto y en solo 6 meses, el equipo de la Ventanilla Única de Costa Rica con el apoyo técnico de la plataforma Customs-hub nos permitió realizar la tarea en tiempo y forma.
Costa Rica ahora tiene un gran desafío planteado, presentar a la OMA el primer MyIP latinoamericano y por supuesto, llevarlo exitosamente a producción. Proyecto que ya con el apoyo del BID se encuentra en fase de selección de ofertas.
Apr 6, 2021 | General
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
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
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
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
Clase específica para reflejar todo lo relacionado con el consignador y un consignatario. Esta clase es ‘hija’ de Declaration
29A ConsignmentItem
Nuevamente es un detalle de items, pero ahora como clase ‘hija’ de Consignment.
23A Commodity
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
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.
Apr 6, 2021 | General
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
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.
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
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
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
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.
Apr 6, 2021 | General
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.
Recent Comments