Select Page
VUCE Argentina se incorpora a la comunidad de usuario de Customs-hub

VUCE Argentina se incorpora a la comunidad de usuario de Customs-hub

Tenemos mucho gusto en confirmar que VUCE Argentina se apoyara en las herramientas Customs-hub y en particular en nuestro DMToolKit para acelerar su proceso de adopción del modelo de datos de la OMA.

Esto nos llena de orgullo y responsabilidad. Las Ventanilla única son otro de los pilares donde se apoya el modelo OMA además de las Aduanas, contar con la primera VUCE dentro del MERCOSUR nos permitirá desarrollar la experiencia esencial para los procesos de integración.  El Modelo OMA cuenta con dos grandes bibliotecas, conocidas como BIP. La DECLARATION que es todo lo referente a procesos aduaneros, bibliotecas en las que se basan los proyectos de Uruguay  y Brasil, y la biblioteca LPCO por Licencias , Permisos , Certificados y Otros. Que es donde se basan los proyectos de Costa Rica y ahora Argentina.

Poco a pocos los puntos de la cadena logística se van estandarizando , con lo que el beneficio de este proceso comienza a tomar una curva exponencialmente positiva. Es para nosotros en Customs-hub una enorme alegría saber que poco a poco estamos cambiando los cimientos del comercio regional , es una apuesta , pero seguros de ir en el rumbo correcto. La preferencia de VUCE por nuestra solución nos lo confirma. Muchas gracias!

 

 

 

El modelo Europeo EUCDM 6.1 disponible en la plataforma Customs-hub

El modelo Europeo EUCDM 6.1 disponible en la plataforma Customs-hub

Sin lugar a dudas, la implementación del modelo OMA en la Unión Europea es de los proyectos más ambiciosos de implementación del modelo. La Unión Europa creó un modelo europeo, llamado EUCDM (European Union Customs Data Model) alineado al modelo OMA. Cada país miembro deberá internacionalizarse para 2024 alineando a su vez su propia implementación al EUCDM.
No solo es importante por la relevancia económica del bloque, sino también por la enorme generación de experiencias en las 27 implementaciones que están sucediendo ya ahora.

En Customs-hub entendemos esta relevancia y el impacto que puede tener en las propias implementaciones en la región de Latinoamérica, por ello desde Noviembre 2021 el modelo EUCDM en su última version publicaba estará disponible en la plataforma DMToolKit como forma de  apoyar y dar un punto de referencia. Así, el modelo EUCDM será otra fuente de análisis y comparación y sin lugar a dudas un importante fuente de consulta. La publicación oficial y documentación completa no solo del modelo EUCDM pero también lo UCC (Union Customs Code) lo pueden encontrar aquí

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

Resumen y Comentarios de la 61ª reunión del DMPT, en español.

Resumen y Comentarios de la 61ª reunión del DMPT, en español.

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.

 

 

 

Aduana de Brasil se incorpora a la comunidad de usuario de Customs-hub

Aduana de Brasil se incorpora a la comunidad de usuario de Customs-hub

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/

Costa Rica presenta sus primeros DMR logrando su aceptación por parte de la OMA

Costa Rica presenta sus primeros DMR logrando su aceptación por parte de la OMA

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.

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

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.