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.