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.