E“CUELA “UPERIOR DE INGENIERÍA MECÁNICA Y ELECTRICA UNIDAD PROFE“IONAL ADOLFO LÓPEZ MATEO“
DE“ARROLLO DE UN “I“TEMA DE LOGÍ“TICA
INTERNACIONAL PARA ITALIKA® MÉXICO
TE“I“
QUE PARA OBTENER EL TITULO DE
INGENIERO EN COMUNICACIONE“ Y ELECTRÓNICA
PRE“ENTA:
MARCO ANTONIO LÓPEZ HERNANDEZ
A“E“OR:
ING. HÉCTOR PIÑA CANALE“
Dedicatorias
.A is a igos de a e a:
Po su guía y te pla za y po so e todo, su a istad.
A los ue o ití po otivos de espa io.
A todos, ¡GRACIAS!
A is o pañe os de t a ajo: Po su e seña za y su pa ie ia.
A i fa ilia:
Po su esfue zo y su apoyo i o di io al sie p e.
A i p o etida:
Justificación.
En 2008 Italika® funda su planta de ensamblaje en Toluca, capital del Estado de
México, con más de 200,000 motocicletas vendidas cada año. En 2010 Italika® se hizo con
el 55% del mercado de motocicletas, en 2011 había alcanzado ya el 70% de cuota de
mercado.
Italika® México plantea la necesidad de sistematizar el esquema actual de
operación, basado sustancialmente en la importación de la mercancía y contabilidad de la
misma, por lo que también es necesario contabilizar las importaciones dentro de los
módulos a desarrollar.
SISLOGIN plantea la solución de estructurar módulos en los que se calcula y envía
la información contable, transacciones en los puntos estratégicos, movimientos de
mercancías y manejo de costos, esto a través de una programación de procesos que
consideren las configuraciones a las que se verá sometida la operación de importaciones,
para ello se diseñó y desarrolló una solución.
Con este sistema, Italika® México planea tener información actualizada en los
diferentes módulos de importaciones para su consulta y análisis, lo que permitirá hacer la
toma de decisiones basada en información confiable y reflejarse en un mejor desempeño
Objetivo General.
Analizar, diseñar y desarrollar un sistema web de registro de importaciones con
estructura JEE (Java Edición Empresarial).
Desarrollar módulos adecuados a tareas particulares en los diferentes procesos
operativos, para lograr una interfaz web que sea un canal de comunicación y que sea un
acoplamiento entre las áreas involucradas en el proceso de importaciones.
Objetivos Específicos.
Los módulos creados para cada operación deben permitir en su respectivo proceso
lo siguiente:
Recibir y cargar las órdenes de compra originadas en SAP® (Systems, Applications
and Products in Data Processing).
Recibir y cargar la información de las listas de empaque provenientes del
proveedor.
Cargar y calcular la información contable con las leyes aduanales de importación.
Generar asientos contables para la toma de decisiones.
Ingresar la documentación de los registros en los que incurrió la importación.
En cada uno de éstos procesos serán evaluadas la condiciones para ajustarse a las
reglas de negocio que aplican según el caso, esto es, que los datos deberán seguir los
lineamientos de las leyes aduanales para el cálculo de los costos integrados; finalmente, una
vez capturados, pasan a ser conciliados en un módulo correspondiente realizando las
Justificación del trabajo.
Con la misión de dar acceso a los clientes para tener un medio de transporte propio,
que les permita ser más eficientes en sus actividades diarias de una forma cómoda,
confiable y divertida. Italika® es una marca de motocicletas y partes de motocicletas
mexicana, fundada en 2006, distribuye sus productos principalmente en las tiendas Elektra,
las cuales también forman parte del Grupo Salinas.
La operación de la empresa se gestionaba por medio de archivos electrónicos, hojas
de papel impresas, hojas de cálculo, envío de documentos impresos por medio de
paquetería, etcétera. Lo anteriormente mencionado, daba origen a un incremento en el
número de errores al momento de gestionar una compra de importación, el volumen de
papel empleado para la impresión de documentos era demasiado, lo cual implicaba un gasto
muy grande a la empresa, la manipulación de la información originada en hojas de
cálculo, se traducía en un sin fin de errores humanos, es decir, las hojas de cálculo eran la
base para obtener los costos y gastos originados para una compra de importación, si el
usuario introducía una cifra incorrecta, ésta impactaba en el costo ó gasto directamente,
provocando un cálculo erróneo del margen de ganancias.
Debido a la carga de trabajo, era imposible hacer una validación confiable de los
archivos electrónicos enviados por los proveedores, una validación deficiente de los
archivos se convertía en un error operacional al momento de comprar un producto.
El manejo de papeles impresos, producían que la operación de auditoría en las
importaciones se duplicara quitando tiempo a todos los usuarios y áreas que incurren en una
Fundamento teórico.
Con el desarrollo de una aplicación web basada en una programación JEE (Java
Edición Empresarial), la cual no representará mayor complejidad para el usuario final, se
estructura y establece una relación correspondiente de la información de las diferentes áreas
dentro del Sistema de Logística Internacional (SISLOGIN).
Por medio del lenguaje Java se desarrollan las interfaces que los distintos módulos
Italika® requiere para acoplar las operaciones de importaciones, contabilidad y finanzas,
esto es, las transacciones de pago y comprobación, los movimientos en el proceso de
importación, variaciones de costo y unidades contra órdenes de compra, así como su
registro en base a documentación aduanal.
Es de gran importancia cumplir con los cálculos tanto de importaciones como
contables que la empresa exige, es decir, la confiabilidad de que los montos calculados sean
correctos, con respectivas referencias técnicas para su mantenimiento y su tiempo de
Dedicatorias i
Justificación ii
Objetivos iii
Justificación del trabajo iv
Fundamento teórico iv
Tabla de contenido vi
Tabla de figuras viii
Tabla de diagramas x
Tabla de cuadros xi
Introducción 1
Capítulo 1 JEE (Java Edición Empresarial), Generalidades. 2
1.1 Estructura JEE 3
1.2 MVC – JSF – Spring – Hibernate – Web Services 6
1.2.1 Modelo, Vista y Controlador 6
1.2.2 Java Server Faces 8
1.2.3 Spring 10
1.2.4 Hibernate 12
1.2.5 Web Services 14
Capítulo 2 Desarrollo de Sistema de Logística Internacional Italika® México 17
2.1 Configuración de ambiente WEB 18
2.2 Módulos de importación 20
2.3 Creación y envío de orden de compra SAP Italika® 21
2.4 Generación de carta de crédito 26
2.4.1 Proceso de liberación de carta de crédito 27
2.5 Carga de la lista de empaque del proveedor 33
2.6 Costeo previo de la importación 37
2.6.1 Comunicación con agente aduanal 35
2.7 Variaciones del Costo 37
2.8 Documentación 47
Capítulo 3 Pruebas y Resultados. 58
3.1 Generación de Carta de Crédito 59
3.1.1 Proceso de Autorización de Carta de Crédito 63
3.2 Proceso de Carga de Lista de Empaque del Proveedor 64
3.3 Costeo Previo de Importación 67
3.4 Análisis de Variaciones de Costos de Importación 73
3.5 Documentación de Importación 75
Conclusiones 82
Acrónimos 85
Bibliografía 89
Figura 1.1 Patrón de funcionamiento JEE. 4
Figura 1.2 Patrón de diseño MVC. 7
Figura 1.3 Proceso de integración Spring. 12
Figura 1.4 Proceso de comunicación de Web Service. 16
Figura 2.1 Ejemplo del formato de un archivo de embarque en Excel. 35
Figura 3.1 Pantalla de acceso principal al sistema. 59
Figura 3.2 Pantalla del menú principal del sistema. 60
Figura 3.3 Pa talla de ús ueda de O de de P o eedo .
60
Figura 3.4 Pa talla supe io de Ca ta de C édito. 61
Figura 3.5 Pa talla i fe io de Ca ta de C édito. 62
Figura 3.6 Co eo soli itud de a ta de édito. 63
Figura 3.7 Pa talla de ús ueda de a hi o E el. 65
Figura 3.8 Detalle de E a ue. 66
Figura 3.9 Co sulta I po ta ió pa a Costeo P e io. 68
Figura 3.10 Pa talla de osteo p e io. 69
Figura 3.11 Sele ió del Age te Adua al. 70
Figura 3.12 Gastos de Age te Adua al po o te edo de i po ta ió .
70
Figura 3.13 Gastos de Ma io as po o te edo . 71
Figura 3.14 Gastos de Flete Na io al po o te edo . 72
Figura 3.15 Costeo p e io o pleto. 73
Figura 3.16 Bús ueda de lo ue pa a a álisis de a ia io es.
74
Figura 3.17 Pa talla de a ia ió de osto. 75
Figura 3.19 Mo ito eo de do u e ta ió . 77
Figura 3.20 Captu a de pedi e to de i po ta ió . 78
Figura 3.21 É ito al al a e a pedi e to de i po ta ió .
79
Figura 3.22 Captu a de Fa tu a de Age te Adua al. 80
Figura 3.23 Co fi a ió de fa tu a de p o eedo . 80
Figura 3.24 Captu a de fa tu as de p o eedo es de se i ios.
Diagrama 2.1 Flujo ope ati o de Ca tas de édito. 31
Diagrama 2.2 Flujo ope ati o pa a a ga de a hi o de e a ue Pa ki g List .
36
Diagrama 2.3 Flujo ope ati o de Costeo P e io de I po ta ió .
39
Diagrama 2.4 Co u i a ió o Age te Adua al. 42
Diagrama 2.5 Va ia io es del Costo. 45
Diagrama 2.6 Flujo de ope a ió pa a Do u e ta ió . 48
Diagrama 2.7 Captu a de Pedi e to de I po ta ió . 50
Diagrama 2.8 Captu a de Age te Adua al. 52
Diagrama 2.9 Captu a de P o eedo es de Se i ios. 54
Cuadro 1.1 No e latu a de pa uetes a hi os. 20
Cuadro 1.2 Eje plos de est ategias de li e a ió . 28
Cuadro 2.1 Codifi a ió pa a e ío de o eo ele t ó i o.
24
Cuadro 2.2 Codifi a ió de e se i e pa a e i o de o de de o p a.
26
Cuadro 2.3 Codifi a ió pa a ús ueda de Ca ta de C édito.
32
Cuadro 2.4 Codifi a ió pa a lee u a hi o E el. 37
Cuadro 2.5 Codifi a ió pa a o sulta de osteo p e io. 40
Cuadro 2.6 I o a ió de e se i e de Age te Adua al.
43
Cuadro 2.7 Codifi a ió pa a ús ueda de folios pa a o te e a ia io es.
46
Cuadro 2.8 Código pa a ús ueda de estatus de fa tu as. 49
Cuadro 2.9 Código pa a ús ueda de pedi e tos. 51
Cuadro 2.10 Código pa a ús ueda de fa tu a de age te adua al.
53
Cuadro 2.11 Código pa a ús ueda de fa tu a de p o eedo es de se i ios.
55
Cuadro 2.12 Código pa a o u i a ió o SAP Fi a zas. 57
Cuadro A. 1 Fe has de pla ea ió . 89
Introducción
.
Las aplicaciones web actuales requieren entre otras cosas, distribución transaccional, portabilidad y seguridad, un desarrollo más rápido, con menos recursos. El objetivo de JEE es proveer a los desarrolladores un conjunto de API’s (Interfaces de Programación de Aplicaciones) que ofrezcan: reducción del tiempo de desarrollo, reducción de la complejidad y aumento de la velocidad. Además de introducir un modelo simplificado de programación como el uso de XML, anotaciones, una programación basada en DTOs (Objeto de Transferencia de Datos), inyección de dependencias, etc. Se debe nombrar la correspondencia objeto contra relación para manejar datos relacionales en configuraciones empresariales, componentes web y clientes.
Siendo una base del modelo de aplicación JEE, ofrece una serie de características:
Servicios Web: Transferencia segura de información y medio de comunicación entre diferentes lenguajes de programación.
Java Data Base Connection: Framework para acceso y manipulación de bases de datos.
Java Server Pages: Desarrollo de páginas con programación Java, complementadas con frameworks.
Software abierto: Su uso hace posible construir una aplicación web con recursos de bajo costo.
Herramientas de desarrollo: JEE, admite una amplia gama de herramientas de desarrollo de aplicaciones, en todos los aspectos del MVC (Modelo Vista Controlador).
El capítulo 1, explica las generalidades de JEE, es decir, la estructura que se debe seguir para lograr una aplicación empresarial, así como las herramientas que pueden ser utilizadas con dicha tecnología y el alcance que puede tener el desarrollar una aplicación fundamentada en Java Edición Empresarial.
CAPÍTULO 1
En éste capítulo se trata el funcionamiento de Java Edición Empresarial, componentes,
servicios y comunicación utilizados para programar en base a esta arquitectura de programación, se
detalla el funcionamiento de la arquitectura MVC (Modelo Vista Controlador) y de las diferentes
tecnologías con las que se puede implementar. Se explica de cómo los Web Services son una
herramienta poderosa para lograr la comunicación entre diferentes tecnologías y lenguajes de
programación.
1.1
Estructura JEE.
Es un conjunto de especificaciones y prácticas coordinadas que juntas permiten soluciones para
el desarrollo, despliegue y gestión de aplicaciones multicapa centradas en un servidor.
JEE se basa en la tecnología modelo, vista y controlador, pues para su utilización primero es
necesaria la instalación del IDE (Entorno de Desarrollo Integrado) como Eclipse o NetBeans.
Posteriormente en una aplicación web dinámica se podrá construir y definir la estructura del patrón de
diseño MVC.
Internet y WWW (World Wide Web, por sus siglas en inglés) representan el fundamento sobre
los cuales se está construyendo la economía de la información. La meta de JEE es definir un estándar
que ayude a suplir los retos tecnológicos en esta nueva era. Soporta aplicaciones distribuidas que
toman ventajas de las tecnologías existentes y en desarrollo simplificando el proceso a través de un
modelo de aplicaciones basados en componentes.
JEE soporta aplicaciones desde las creadas para funciones corporativas hasta e-commerce
(Comercio electrónico) con Web en Internet. Define estándares que son implementados por distintos
proveedores y fabricantes, no obliga a emplear ningún producto específico y máxima
Figura 1.1 Patrón de Funcionamiento JEE.
JEE comprende tres categorías:
1. Componentes.- Utilizados por desarrolladores para crear partes esenciales de una
aplicación empresarial. Se usará en la interfaz de usuario y lógica de negocio. Se refiere
a la unidad de software de nivel aplicación, ejemplo: JavaBeans, applets, componentes
web. Los componentes web son entidades que sirven respuestas a peticiones http, los
servlets se encargan de extender la funcionalidad de un servidor web, además de ser
portables.
2. Servicios.- Los cuales simplifican el desarrollo de aplicaciones poniendo recursos a su
disposición. Algunos servicios ofrecidos por el contenedor de la aplicación a los
componentes se declaran en lugar de programarse. La declaración (por ejemplo,
especificar que un método tiene que estar inmerso en una transacción) se realiza
mediante descriptores de despliegue, el cual es un contrato entre contenedor y
de recursos, etc. Generalmente se hace uso de un Framework que ayude a la gestión de
las configuraciones para delimitar por ejemplo el tiempo de vida de recursos,
intercomunicación entre vistas y JavaBeans así como definición de reglas de negocio y
reglas en las vistas para los usuarios.
3. Comunicación.- Son entidades que sirven respuestas a peticiones http, normalmente se
generan interfaces de usuario basadas en web, comunicación con bases de datos por
medio de servicio JDBC (Java Data Base Control) proporcionando conectividad
independiente entre la base de datos y la plataforma JEE. Implementa los mecanismos
de comunicación de los protocolos de internet por ejemplo, TCP/IP (Protocolo de
Control de Transmisión / Protocolo Internet), http, etc. Dentro de la comunicación se
localizan las utilerías de mensajería, JMS (Servicio de Mensajes Java), Java Mail, como
conjunto de clases e interfaces para el acceso a servidores de email, por ejemplo: POP3,
SMTP (Protocolo Simple de Transferencia de Mail), etc.
La definición de un Framework dedicado a las tres capas de la arquitectura MVC es
considerada dentro del desarrollo de JEE como una de las mejores prácticas para obtener un sistema
estable y confiable ya que se basa en utilizar arquitecturas de varias capas distribuidas apoyándose en
componentes de software ejecutados sobre un servidor de aplicaciones. Otros beneficios son, por
ejemplo, que el servidor de aplicaciones puede manejar transacciones, la seguridad, escalabilidad,
concurrencia y gestión de los componentes desplegados, significando que los desarrolladores pueden
concentrarse más en la lógica de negocio de los componentes en lugar de en tareas de mantenimiento
1.2
JEE MVC – JSF – Spring – Hibernate – WebServices
La arquitectura de una aplicación web se rige básicamente por los frameworks que compondrán
las capas de diseño de dicha aplicación, se debe reforzar la capa de la vista con elementos que sean
atractivos para el usuario y funcionales para el desarrollador, es por ello que JSF (Java Server Faces)
es una tecnología que con el conjunto de API´s y componentes para la interfaz de usuario,
complementa perfectamente la capa de Vista en el MVC.
Spring, con la complejidad que conlleva este framework, cuenta con diferentes módulos con los
que logrará ser el controlador de nuestra aplicación y mantener en comunicación a la Vista y el
Modelo.
Hibernate, es una herramienta de mapeo ORM (Objeto de Mapeo Relacional) la cual estará en
constante comunicación con la base de datos, almacenando y consultando la información requerida por
el controlador.
Web Services, es el conjunto de protocolos y estándares que sirven para intercambiar datos
entre las aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programación
diferentes.
1.2.1
El Modelo Vista Controlador.
Es un patrón de arquitectura de software que separa los datos y la lógica de negocio de una
aplicación de la interfaz de usuario y el módulo encargado de gestionar eventos y las comunicaciones.
Para ello MVC propone la construcción de tres componentes distintos que son el modelo, la vista y el
controlador, es decir, por un lado define componentes para la representación de la información y por el
otro lado para la interacción del usuario. Este patrón de diseño se basa en las ideas de reutilización de
aplicaciones y su posterior mantenimiento. En la figura 1.2 se muestra al MVC como el motor de un
[image:20.612.165.485.132.388.2]flujo de petición del cliente a base de datos.
Figura 1.2 Patrón de Diseño MVC.
El MVC permite la realización de diversas tareas seccionadas por la naturaleza de su acción:
a) Recibo de peticiones (request) del usuario. El controlador recibe las peticiones del usuario. Las
cuales son generadas en una vista, la cual es diseñada en JSP con la infraestructura de algún
framework para completar su potencial.
b) El controlador recibe las peticiones y toma las decisiones correspondientes. Para el buen
funcionamiento del controlador es necesario tener el conocimiento operativo de la aplicación
que se está diseñando.
c) El modelo recibe una petición por medio del controlador, éste toma la tarea requerida y
controlador. La operación del modelo puede ir desde una lectura de base de datos como un
llenado de la misma.
d) La vista puede recibir la petición del controlador, directamente sin pasar por el modelo o el
controlador puede recibir la respuesta del modelo, interpretarla y generar la respuesta que tiene
que mostrar la vista.
1.2.2
JSF (Java Server Faces)
Es un Framework de aplicaciones Java basadas en web, que simplifica el desarrollo de interfaces
de usuario en aplicaciones Java EE. Utiliza una JSP como motor base para su implementación la cual
permite el despliegue de páginas, JSF incluye las siguientes características:
a) API´s para representar componentes de una interfaz de usuario y administrar su estado, manejar
eventos, validar entradas, definir un esquema de navegación de las páginas y dar soporte para
internacionalización y accesibilidad.
b) Un conjunto por defecto de componentes para la interfaz de usuario.
c) Dos bibliotecas de etiquetas personalizadas para JavaServer Pages que permiten expresar una
interfaz JavaServer faces dentro de una página JSP.
d) Un modelo de eventos en el lado del servidor.
e) Administración de estados.
f) Beans Administrados.
Un objetivo importante de la tecnología JSF es mejorar los conceptos familiares a componentes UI
(Interfaz de Usuario) y capa Web sin limitarnos a una tecnología de Script particular o un lenguaje de
marcas. Aunque la tecnología JSF incluye una librería de etiquetas JSP personalizada para representar
componentes es una página JSP, los API´s de la tecnología JSF se han creado directamente sobre el
junto a JSP (Java Server Pages), crear nuestros propios componentes personalizados directamente
desde las clases de componentes y generar salida para diferentes dispositivos cliente.
Son cuatro procedimientos para realizar el proceso de desarrollo con JSF:
1. Desarrollo de los objetos del modelo, los cuales contendrán los datos. Son clases como
cualquier componente Java, cuenta con su método set o accesor y un campo privado o
propiedad. Incluye los tipos de datos a utilizar como String, int, doublé, etc.
2. Declaración del objeto de negocio comúnmente llamado "Bean", después de desarrollar los
objetos Bean, se requiere añadir las declaraciones en un archivo de configuración de la
aplicación. La implementación de JSF procesa este archivo en el momento de arrancar el
servidor y lo almacena en el ámbito de sesión, es decir, el Bean estará disponible en todas las
páginas de la aplicación.
3. Creación de páginas, este proceso implica distribuir los componentes UI en las páginas a
mapear los componentes a los datos de los objetos del modelo, y añadir otras etiquetas
importantes (como etiquetas del validador) a las etiquetas de los componentes. La etiqueta más
importante en una página será el “form” la cual representa el formulario de entrada que permite
al usuario introducir algún dato y enviarlo al servidor.
4. Definición de reglas de navegación, el desarrollo de JSF permite navegar entre las páginas
mediante el archivo de configuración, mismo archivo en el que fue declarado la referencia
manejada. Cada regla de navegación define como ir de una página a otra dentro de la
aplicación, basada en una regla lógica definida dentro del archivo, esta salida será
proporcionada por el método invocado el cual tiene la facultad de tomar la decisión de que
navegación, gracias a su archivo de configuración Faces-Config.xml podemos definir las reglas
incluso para diferentes salidas en diferentes acciones y eventos.
1.2.3
Spring
Es un framework para el desarrollo de aplicaciones y contenedor de inversión de control, si
bien las características fundamentales de Spring Framework pueden ser usadas en cualquier
aplicación desarrollada en Java, existen varias extensiones para la construcción de aplicaciones
web sobre la plataforma Java EE. A pesar de que no impone ningún modelo de programación en
particular, este Framework se ha vuelto popular en la comunidad al ser considerado una alternativa,
sustituto, e incluso un complemento al modelo EJB (Enterprise JavaBean).
Spring Framework comprende diversos módulos que proveen un rango de servicios:
1. Contenedor de Inversión de Control, permite la configuración de los componentes de
aplicación y la administración del ciclo de vida de los objetos Java, se lleva a cabo
principalmente a través de la inyección de dependencias. El objetivo es lograr un bajo
acoplamiento entre los objetos de nuestra aplicación. Con este patrón de diseño, los objetos
no crean o buscan sus dependencias (objetos con los cuales colabora) sino que éstas son
dadas al objeto. El contenedor (la entidad que coordina cada objeto en el sistema) es el
encargado de realizar este trabajo al momento de instanciar el objeto. Se invierte la
responsabilidad en cuanto a la manera en que un objeto obtiene la referencia a otro objeto.
De esta manera, los objetos conocen sus dependencias por su interfaz.
2. Programación Orientada a Aspectos, habilita la implementación de rutinas transversales.
Intenta separar las funcionalidades secundarias de la lógica de negocios. En inglés
denominan a estas funcionalidades “cross – cutting concerns” algo que se traduciría como
transacciones, etc. Son funcionalidades que atraviesan nuestro programa en varias
abstracciones de éste. Por lo tanto corremos el riesgo de caer en la repetición de código y el
acoplamiento entre nuestra lógica de negocios y la implementación de los cross-cutting
concerns.
3. Acceso a datos, se trabaja con RDBMS (Sistema Manejador de Bases de Datos
Relacionales) en la plataforma Java, usando Java Database Connectivity y herramientas de
mapeo objeto relacional con bases de datos no SQL.
4. Gestión de Transacciones, unifica distintas API´s de gestión y coordina las transacciones
para los objetos Java.
5. Framework de acceso remoto, permite la importación y exportación estilo RPC (Llamado a
Procedimiento Remoto), de objetos Java a través de redes que soporten RMI, CORBA y
protocolos basados en HTTP, incluyendo servicios web (SOAP).
6. Soporte de clases para desarrollo de unidades de prueba e integración (Testing).
La figura 1.3 muestra como está integrado Spring y las bases sobre las cuales se soporta cada una de
Figura 1.3 Proceso de interacción Spring.
1.2.4
Hibernate
Es una herramienta ORM (Mapeo Objeto Relacional) para Java el cual se localiza en la capa de
persistencia de una aplicación, la cual facilita el mapeo de atributos entre una base de datos relacional
tradicional y el modelo de los objetos de una aplicación, mediante archivos declarativos XML, o
anotaciones en los beans de las entidades que permiten establecer estas relaciones.
Hibernate busca solucionar el problema de la diferencia entre los dos modelos de datos coexistentes en
una aplicación, el uso de memoria de la computadora (orientación a objetos) y el usado en las bases de
datos (modelo relacional). Esto permite al desarrollador detallar como es su modelos de datos, que
Con esta información Hibernate permite a la aplicación manipular los datos en la base de datos
operando sobre objetos, con todas las características de la POO (Programación Orientada a Objetos).
Hibernate convertirá los datos entre los tipos utilizados por java y los definidos por SQL. Hibernate
genera las sentencias SQL y libera el manejo manual de los datos que resultan de la ejecución de
dichas sentencias, manteniendo la portabilidad entre todos los motores de bases de datos con un ligero
incremento en el tiempo de ejecución.
Hibernate ofrece al desarrollador un lenguaje de consulta de datos llamado HQL (Hibernate Query
Language) al mismo tiempo que una API para construir las consultas programáticamente (conocida
como Criteria). El mapeo XML de Hibernate consta de las siguientes partes:
1. Declaración de la DTD (Definición de Tipo de Documento), el documento DTD que se usa en
archivos XML se encuentra en cada distribución de Hibernate en el propio .jar o en el
directorio src. El principal elemento es el elemento raíz <hibérnate-mapping> dentro de él se
declaran las clases de los objetos persistentes. Aunque es posible declarar más de un elemento
<class> en un mismo fichero XML, no debería hacerse ya que aporta mayor claridad a la
aplicación al realizar un documento XML por clase de objeto persistente.
2. Declaración <class>, este es el tag donde se declara la clase persistente. Una clase persistente
equivale a una tabla en la base de datos, y un registro o línea de esta tabla es un objeto
persistente de esta clase. Entre sus posibles atributos destacan:
a. Name, nombre completo de la clase o interface persistente.
b. Table, nombre de la tabla en la base de datos referenciada. En esta tabla se realizarán
las operaciones de transacciones de datos. Se guardarán, modificarán o borrarán
registros según la lógica de negocio de la aplicación.
d. Proxy, nombre de la clase Proxy cuando esta sea requerida.
3. Declaración <id>, permite definir el identificador del objeto. Se corresponderá con la clave
principal de la tabla en la base de datos. Se tienen que asignar identificadores únicos a los
objetos persistentes. Utilizando identificadores de objetos tanto a nivel código como en la base
de datos, se simplifica mucho la complejidad de la aplicación y se pueden programar partes de
la misma como código genérico.
4. Declaración <property>, declara una propiedad persistente de la clase, que corresponde a una
columna de la tabla relacional,
a. Name, indica nombre lógico de la propiedad.
b. Column, denota la columna de la tabla relacional.
c. Type, indica el tipo de los datos almacenados en Hibernate.
5. Declaración <one-to-one>, Asociación entre dos clases persistentes, en la cual no es necesaria
otra columna extra. Los identificadores de las dos clases serán idénticos.
a. Name, nombre de la propiedad.
b. Class, la clase persistente del objeto asociado.
c. Cascade, (all,none,save-update,delete) operaciones en cascada a partir de la asociación.
1.2.5
Web Services
Los Web Services permiten una integración de aplicaciones desarrolladas en diferentes
lenguajes y corriendo en diferentes plataformas. Una aplicación puede implementar un web service
usando una interface para definir un servicio en un web service con formato XML.
El web service es publicado en un servidor centralizado, entonces otras aplicaciones que necesitan
acceder a la información o depositar información lo pueden lograr por este medio ya que, un web
Simple), WSDL (Definición de Lenguaje de Servicio Web), UDDI (Descripción Universal de
Revelación e Integración). La principal razón para usar servicios Web es que se pueden utilizar
con HTTP sobre TCP (Protocolo de Control de Transmisión) en el puerto 80. Dado que las
organizaciones protegen sus redes mediante firewalls que filtran y bloquean gran parte del tráfico de
Internet, cierran casi todos los puertos TCP salvo el 80, que es, precisamente, el que usan
los navegadores.
Para hacer esto posible el web service provee una interface que intercambia datos entre aplicaciones
independientemente del lenguaje o sistema operativo.
Las características de los web service son:
1. Interpolabilidad, Permite a las aplicaciones desarrolladas en diferentes lenguajes y corriendo en
sistemas heterogéneos comunicarse.
2. Integración dinámica, permite aplicaciones a localizar dinámicamente e integrarse con alguna otra
para proveer soluciones empresariales.
3. Estándares de las industrias, Permite a las aplicaciones comunicarse con otras usando estándares
conocidos como XML, SOAP, WSDL y UDDI.
4. Seguridad, Permite a las aplicaciones comunicarse bajo un ambiente seguro usando XML signature
y XML encryption, los cuales son mecanismos de seguridad para mantener la integridad de los
datos que es transferida por internet.
Los servicios Web fomentan los estándares y protocolos basados en texto, que hacen más fácil
acceder a su contenido y entender su funcionamiento. Permiten que servicios y software de diferentes
compañías ubicadas en diferentes lugares geográficos puedan ser combinados fácilmente para proveer
web de destino, los protocolos que siguen la construcción de un web service permitirán siempre que se
logre una compatibilidad entre el origen de la información así como el destino, manteniendo siempre la
[image:29.612.133.516.171.443.2]integridad de la información. La figura 1.4 muestra el proceso de comunicación de un Web Service.
CAPÍTULO 2
En éste capítulo se explica cómo se desarrolla un sistema para controlar la operación de
importaciones de Italika®. Se muestra cuál es la configuración establecida para la codificación del
sistema, así como cuales son los módulos que se deben codificar para lograr una parte del correcto
funcionamiento de una importación.
2.1
Configuración de ambiente.
Se desarrolló un ambiente JEE para una aplicación web el cual permitirá generar un archivo de
extensión .war que deberá ser alojado en el servidor de aplicaciones. El ambiente web consta de una
nueva aplicación web dinámica, la cual en su estructura tiene como elementos principales:
Paquete.- Paquetes o carpetas en las que se deberá ir estructurando el codificado en
Java.
Build.- Carpeta en la cual se almacena el código Java compilado, con la extensión .class
WEB-CONTENT.- Carpeta en la cual se estructura el contenido web, es decir, la
configuración del archivo web.xml y las carpetas que contienen las vistas a usuarios
(.jsp)
WEB-INF.- Carpeta donde se localiza la configuración de los archivos para Java Server
Faces, Spring, Hibernate, etc.
META-INF.- Contiene la versión y configuración del ambiente bajo el cual se está
desarrollando.
Lib.- Carpeta en la cual se depositan todos los archivos .jar utilizados a lo largo de la
aplicación.
Cuando se desarrolla una aplicación JEE es necesario establecer, cuáles serán las
inicio, etc. Para la aplicación de SISLOGIN (Sistema de Logística Internacional), la nomenclatura que
se estableció se muestra en la tabla 2.1 "Nomenclatura de paquetes y archivos":
Elemento Descripción
mx.com.elektra.portalsislogin Nombre para el paquete raíz.
mx.com.elektra.portalsislogin.beans Nombre para el paquete que contendrá las clases tipo Bean.
mx.com.elektra.portalsislogin.dto
Nombre para el paquete que contendrá las
clases tipo DTO (Objeto de Transferencia
de Datos)
mx.com.elektra.portalsislogin.service Nombre para el paquete que contendrá las clases e interfaces de tipo Service
mx.com.elektra.portalsislogin.dao
Nombre para el paquete que contendrá las
clases e interfaces de tipo DAO (Objeto de
Acceso a Base de Datos)
mx.com.elektra.portalsislogin.utils
Nombre para el paquete que contendrá las
clases que son utilizadas por los demás
desarrolladores.
index.jsp Nombre a la JSP de inicio para cualquier
modulo.
cada modulo llevará su correspondiente
archivo .xml
aplicationContext.xml
Nombre del archivo de configuración en el
cual se definirán los objetos de servicio y
acceso a base de datos.
web.xml
Archivo de configuración en el cual se
declaran los componentes faces, servlets,
etc.
sun_jaxws.xml
Archivo de configuración en el cual se
declaran los componentes para web
[image:33.612.77.528.65.411.2]services.
Tabla 2.1 Nomenclatura de paquetes y archivos.
Una vez establecida la nomenclatura se deberá configurar y codificar cada uno de los archivos
requeridos.
2.2
Módulos de importación.
La logística de importación juega un papel sumamente importante para el negocio de la
empresa, ya que la mayor operación se encuentra en la importación de motocicletas y refacciones de
motocicletas. Es por ello que se requiere tener una visión muy amplia de la importación, la cual
permita gestionar el proceso de importaciones. El proceso de importaciones parte del origen de una
Orden de Compra, la cual será negociada con el proveedor de la producción, llegado a un acuerdo se
“Financiamiento”. Una vez embarcada la mercancía producida, el proveedor envía la información del
embarque, para registrar esta información será necesario el módulo de Carga de Packing List segundo
módulo del sistema a desarrollar. Es indispensable para la empresa, saber el costo al cual estará
recibiendo el producto comprado, de ahí dependerá el costo a la venta, para ello es necesario que el
sistema genere los cálculos de los costos en los que incurre la importación, para ello se desarrolla el
módulo de Costeo Previo. Es importante analizar el comportamiento de los costos de importación, es
decir, se deberán tomar decisiones importantes al momento de actualizar los costos de un producto
debido a los resultados arrojados por los costos de importación, información que el sistema deberá
enfrentar con un historial de importaciones del mismo producto, para ello el módulo de Registro de
Variaciones será de gran utilidad. Para concluir el proceso de la importación será necesario tener un
registro de los documentos en los que incurre la importación, es decir, todas las facturas generadas por
los proveedores involucrados en una importación, éste registro se llevara a cabo en el módulo de
Documentación.
2.3
Creación y envío de Orden de Compra SAP
Italika®
Cuando existe una Orden de Compra nueva, la Dirección de Producto y Compras debe:
Enviar vía correo electrónico al área de Importaciones la copia del contrato de la Orden de
Compra, los descuentos si es que aplican, la agenda de embarque y solicitar la fecha de
descarga de la mercancía en el almacén (Due Date).
El área de Importaciones debe:
Asignar un buque por Orden de Compra.
Enviar vía correo electrónico al Gerente de Planeación de Producción, Analista de
Planeación de Producción y al Asistente de Dirección General los siguientes datos:
o Número de Pedido.
o Modelo.
o Cantidad.
o Número de Contenedores.
o Fecha de salida tentativa.
o Fecha de llegada tentativa.
o Fecha real de salida.
o Fecha real de llegada.
o Semana en que arriba la mercancía al puerto.
o Fecha de disponibilidad de la mercancía.
El área de Planeación de Producción debe realizar su plan de producción y notificar vía
correo electrónico al área de Importaciones y Producto y Compras la fecha en que requiere la
descarga de la mercancía en el almacén (Ver Anexo 1. Ejemplo de archivo con fechas de descarga
de mercancía en la Planta (Due Date).
El área de Producto y Compras debe cargar la Orden de Compra en SAP Italika® y solicitar al
área de Sistemas SAP que pase la información de la Orden de Compra a SISLOGIN.
SISLOGIN debe:
Notificar al área de Importaciones vía correo electrónico que hay una nueva Orden de
o Orden de Proveedor
o Proveedor
o Tipo de financiamiento ( Carta de Crédito / Transferencia Bancaria)
o Orden de Compra
o Comprador
o Monto Total
o Descripción de la mercancía
o Fechas de embarque por cada orden
o Due date (Fecha de entrada a Almacén)
El cuadro 2.1 muestra parte de la codificación requerida para realizar un envío de correo
electrónico con un formato definido para distinguir los correos del sistema.
public void enviaCorreoBase(EstructuraMailDTO mailDetalle, String aux) throws Exception{
String subject = mailDetalle.getSubject();
String titulo = mailDetalle.getTitulo();
String subTitulo = mailDetalle.getSubTitulo();
String cuerpo = mailDetalle.getCuerpo();
String pie = mailDetalle.getPie();
Properties properties = new Properties(); properties.put("mail.smtp.host", servidor);
properties.put("mail.smtp.localhost", "ekt.com.mx"); properties.put("mail.smtp.port", 25);
properties.put("mail.smtp.auth", "false");
Cuadro 2.1 Codificación para envío de correo electrónico.
2.3.1
Comunicación con SAP
Para que el sistema de importaciones pueda recibir la información del contrato generado por
el proveedor e Italika®, fue necesario generar un servicio web el cual esté al alcance entre los dos
sistemas. El servicio web se publica dentro de la misma aplicación y dentro de los servidores
aplicativos de la empresa. La información que el servicio web requerirá es:
Orden de Compra.- Es el folio con el cual SAP identificará el contrato de la compra.
Orden de Proveedor.- Es el folio que relaciona al proveedor con el contrato de SAP.
Session sesion = Session.getInstance(properties); Message msg = new MimeMessage(sesion);
msg.setFrom(new InternetAddress(mailDetalle.getRemitente().getMail(), mailDetalle.getRemitente().getNombre()));
StringBuffer msgHTML = new StringBuffer(""); msgHTML.append(" <html> "); msgHTML.append(" <body> "); msgHTML.append(" <center> "); msgHTML.append( subTitulo ); msgHTML.append( cuerpo );
if(mailDetalle.getDatosInteresMail() != null){
for(DatosInteresMailDTO elem : mailDetalle.getDatosInteresMail()) { msgHTML.append(elem.getConcepto() + ": <b>" + elem.getValor() +"</b>"); }
msgHTML.append( pie ); msgHTML.append( pieMail ); msgHTML.append(" </body>"); msgHTML.append(" </html>");
InternetAddress[] toAddresses = new InternetAddress[mailDetalle.getDestinatarios().size()]; int a = 0;
for (MailDTO elem : mailDetalle.getDestinatarios()) {
toAddresses[a] = new InternetAddress(elem.getMail(),elem.getNombre());
msg.setRecipients(Message.RecipientType.BCC, bCCAddresses); } a++; } msg.setRecipients(Message.RecipientType.TO, toAddresses); msg.setSubject(subject); msg.setContent(msgHTML.toString(), "text/html"); Transport t = sesion.getTransport("smtp"); t.connect();
Proveedor.- Es el folio con el cual se dio de alta el Proveedor en SAP y que es el reconocido
por todos los sistemas de la empresa.
Comprador.- Es el folio que identifica por medio de un número quien es el comprador y dueño
de la mercancía a importar.
Descripción del Producto.- Es el nombre a detalle del artículo importado.
Cantidad de Piezas.
Modelo.
Precio Unitario.
Precio Total.
Ésta información viajara a través del servicio para posteriormente ser almacenada en la base de datos
de SISLOGIN. El cuadro 2.2 muestra la parte de la codificación para establecer un servicio web el cual
será invocado por SAP para transferir la información de una orden de compra.
@XmlRootElement(name = "guardaImpBase", namespace = "http://sap.ws.portalsislogin.elektra.com.mx/") @XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "guardaImpBase", namespace = "http://sap.ws.portalsislogin.elektra.com.mx/", propOrder = {"orden"}) /**
*
* @author malopezh */
public class GuardaImpBase {
@XmlElement(name = "orden", namespace = "") private ImportacionBase orden;
public ImportacionBase getOrden() { return orden;
}
public void setOrden(ImportacionBase orden) { this.orden = orden;
Cuadro 2.2 Codificación de web service para recibo de orden de compra.
2.4
Generación de Carta de Crédito.
El área de Importaciones debe:
Revisar que el contrato de la Orden de Compra coincida con los datos que aparecen en
SISLOGIN. En caso de que no coincidan, debe notificar a la Dirección de Producto y
Compras para que corrija la diferencia
Registrar la Orden de Proveedor en SISLOGIN para elaborar la solicitud de la Carta de
Crédito
Registrar en idioma inglés los términos y condiciones de la Orden de Compra (Ver Anexo 2.
Forma: Solicitud de la Orden de Compra)
import javax.xml.bind.annotation.XmlAccessType; import javax.xml.bind.annotation.XmlAccessorType; import javax.xml.bind.annotation.XmlElement; import javax.xml.bind.annotation.XmlRootElement;
@XmlRootElement(name = "guardaImpBaseResponse", namespace = "http://sap.ws.portalsislogin.elektra.com.mx/") @XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "guardaImpBaseResponse", namespace = "http://sap.ws.portalsislogin.elektra.com.mx/")
/** *
* @author malopezh */
public class GuardaImpBaseResponse {
@XmlElement(name = "return", namespace = "") private WSResponse _return;
public WSResponse getReturn() { return _return;
}
public void setReturn(WSResponse _return) { this._return = _return;
Colocar el descuento en caso de que aplique
Escoger la estrategia de liberación de la Orden de Compra de acuerdo con el tipo de material:
o CKD / IKD
o SKD
o Refacciones
o Otros
2.4.1
Proceso liberación de Carta de Crédito.
Una vez que el área de Importaciones ingresa los datos, SISLOGIN debe:
Generar número de folio de referencia de la Carta de Crédito
Generar correo electrónico dirigido a los autorizadores con la información que el área de
Importaciones ingresó de acuerdo con la estrategia de liberación.
La tabla 2.2 muestra un ejemplo de estrategias de liberación que se pueden elegir en el sistema.
Tipo de Material Autorizadores
CKD / IKD Dirección de Producto y Compras / Dirección General de
Italika®
SKD Dirección de Producto y Compras / Dirección General de
Italika®
Otros Compras Refacciones / Dirección de Producto y Compras / Dirección General de Italika®
Tabla 2.2 Ejemplos de estrategias de liberación.
Los autorizadores deben:
Analizar el detalle de la Orden de Compra
Autorizar el folio de liberación de la Carta de Crédito y colocar sus comentarios. En caso de
que no autoricen el folio, deben cancelarlo y colocar sus comentarios con las razones de la
cancelación.
Una vez que el folio está autorizado, SISLOGIN debe generar un correo electrónico y enviarlo
a las áreas de Importaciones y de Tesorería Elektra notificando que el folio de liberación de la Carta de
Crédito y la Orden de Compra está autorizado en su totalidad.
El área de Importaciones debe enviar a Tesorería Elektra los términos y condiciones de la Orden de
Compra en un archivo de Excel.
El área de Tesorería Elektra debe:
Realizar el trámite del folio ante el Banco con el que se cuente con línea de crédito en ese
momento para procesar la información de la Carta de Crédito
Enviar correo electrónico al área de Importaciones con la confirmación de la carta de crédito
(SWIFT)
Para comprobar la fecha de emisión de la Carta de Crédito y el número SWIFT en SISLOGIN,
Revisar los datos de la Carta de Crédito y verificar que el consignatario, el monto total y los
términos y condiciones coincidan con el folio correspondiente de la Orden de Compra en
SISLOGIN
Ingresar a SISLOGIN y registrar el número de la Orden de Compra
Registrar la fecha en la que se emitió la Carta de Crédito y el número de SWIFT
Una vez que el área de Importaciones haya guardado la fecha y el número SWIFT, SISLOGIN debe
notificar al área de Contabilidad
El área de Importaciones debe:
Dar seguimiento a la Orden de Compra para asegurar que la mercancía llegue a su destino de
acuerdo con las fechas de embarque
Asignar un buque de importación de acuerdo con el número de contenedores y la semana en
que sale
Revisar el número de contenedores del Bloque de Importación
Notificar a la Naviera vía correo electrónico la siguiente información:
o Número de contenedores
o Número de orden
o Modelo
o Cantidad
o Fecha de embarque
o Origen del embarque
o Consignatario
La Naviera debe mandar un reporte semanal al área de Importaciones para informarle si el
Proveedor ya hizo la reservación del embarque (Booking). En caso de que el proveedor no lo haya
hecho, el área de Importaciones debe enviar un recordatorio al Proveedor vía correo electrónico.
El área de Importaciones debe:
Actualizar los reportes los días lunes de cada semana para monitorear los embarques que
salen los fines de semana
Revisar en la página de Internet de la naviera para identificar y notificarle los retrasos de los
embarques (http://www.maerskline.com)
Enviar un correo electrónico con el reporte semanal actualizado a las siguientes áreas:
o Gerente y Analista de Planeación de Producción
o Asistente de Dirección Genera
En el diagrama 2.1 "Flujo operativo para Cartas de Crédito" se pueden visualizar los pasos a seguir
El cuadro 2.3 muestra parte de la codificación necesaria para la búsqueda de una carta de
crédito almacenada en una base de datos.
Cuadro 2.3 Codificación para búsqueda de Carta de Crédito public String mostrarAction(){
this.esLink = false;
log.info("Entrando a Mostrar Action de Prov.. "+ordenProv);
totalesCCDTO = new ArrayList<SolTipoFinanciamientoDTO>();
SolicitudRefaccionesService servRef=
(SolicitudRefaccionesService)serviceLocator.getService("solicitudRefaccionesService");
try {
SimpleDateFormat sdf = new SimpleDateFormat("dd-MM-yyyy");
SimpleDateFormat an = new SimpleDateFormat("yyyy");
SimpleDateFormat me = new SimpleDateFormat("MM");
Date f = new Date();
fechaCC = sdf.format(f);
mes = me.format(f);
Integer m = new Integer(mes);
mes = mount[m-1];
anio = an.format(f);
BigDecimal tipoFin = new BigDecimal(1);
dtoTT = servRef.cargarDatosTipoFinanciamiento(ordenProv,null,tipoFin);
if(dtoTT==null){
FacesContext.getCurrentInstance().addMessage(null, new
FacesMessage(FacesMessage.SEVERITY_ERROR,
"No se encontró orden de proveedor "+ordenProv+ ".", ""));
returnnull; }
totalesCCDTO.add(dtoTT);
SolTipoFinanciamientoDTO dt = (SolTipoFinanciamientoDTO)dtoTT.getCantidades().get(0);
dtoTT.setDescripcionGod(dtoTT.getCantidadesModelos().get(0).getDescripcionGod());
montoTotal = dt.getMonto();
cantidadPza = dt.getCantidad();
//log.debug("[ORDENES_SAP]"+dtoTT.getOrdenesCompra()); //log.debug("[MONTO]"+montoTotal);
conCartaCredito=false; llenaCabeceroCommentarios();
return"OK"; } catch (ServicioException e) {
e.printStackTrace();
log.error("Error al cargar datos para TT");
}
2.5
Carga de la lista de empaque del proveedor.
El área de Importaciones debe:
Solicitar al Proveedor los siguientes documentos vía correo electrónico:
o Factura (con la Orden de Compra a la que pertenece el embarque)
o Lista de empaque
o Lista de precios
o Puerto de Salida
o Certificado de Origen
Revisar que los documentos vengan completos y que los Datos de la Factura coincidan con la
Orden de Compra. En caso de que no coincidan, debe solicitar al Proveedor que corrija la
información
Solicitar al Proveedor el archivo de embarque en un formato de Excel
El Proveedor debe enviar al área de Importaciones los documentos solicitados y el Price List con la
siguiente información por contenedor
o Número de Factura
o Nombre del Proveedor
o Número de contenedor el cual debe estar indicado como “Container No.” antes del
número del contenedor que debe ser escrito sin espacios
o Modelo
o Número PLM
o Descripción en Inglés
o Cantidad Total de Piezas
o Precio unitario en dólares
o Precio total en dólares
o Número de Orden Italika®
o Factura
o Descuento
Cuando haya SKDs (Partes Para Motocicletas) y números de serie, el Proveedor debe completar la
siguiente información por contenedor:
o Serie (En caso de que no aplique debe aparecer NA)
o Motor (En caso de que no aplique debe aparecer NA)
o Tipo (En caso de que no aplique debe aparecer NA)
o Color (En caso de que no aplique debe aparecer NA)
En el caso de refacciones, el Gerente de Compras Refacciones debe enviar el archivo de embarque
con la información descrita al área de Importaciones
El área de Importaciones debe:
Revisar que el archivo de embarque tenga el formato correcto. En caso contrario, debe
solicitar al Proveedor al área de Producto y Compras si es que no tiene contacto directo con
el Proveedor que corrija el archivo y lo envíe nuevamente.
Realizar la carga del archivo de embarque en SISLOGIN
Enviar al Gerente de Planeación de Producción, Analista de Planeación de Producción,
Asistente de Dirección General y al área de Refacciones los siguientes documentos:
o Lista de empaque
o Lista de precios
o Puerto de Salida
o Certificado de Origen
La figura 2.1 muestra un ejemplo del formato que debe llevar el archivo de embarque
generado en formato Excel, el cual será requerido para que el sistema forme un folio el cual relacione
la información, a este folio se le llama bloque de importación. Es de suma importacia que el formato
sea respetado en cada columna y fila, ya que el sistema buscará información especifica por celda,
además de que el sistema detectará por medio de la palabra "container no" el número de contenedor y
todo lo que sea localizado hasta las siguiente palabra llave "container no" pertenecerá a un
contenedor de importación, no se debe alterar el orden de las columnas ya que de hacerlo, el sistema
almacenara datos erroneos en la base de datos, lo cual puede provocar problemas en los módulos
[image:48.612.63.547.429.689.2]subsecuentes.
En el diagrama de flujo 2.2 se muestra el "Flujo operativo para carga de archivo de embarque".
Diagrama 2.2 Flujo Operativo para carga de archivo de embarque (Packing List).
El cuadro 2.4 muestra la codificación mas importante para realizar la lectura de un archivo
Excel, se diseño la lectura por medio de una matriz, identificando la palabra clave y delimintando el
número de columnas que se deben recorrer hasta no encontrar información y dar por leido todo el
Cuadro 2.4 Codificación para leer un archivo Excel.
2.6
Costeo previo de la importación
.El objetivo del costeo previo es reflejar de manera aproximada los costos totales de
importación por item de forma anticipada, no se toman en cuenta gastos adicionales no contemplados
public PackingListRefacDTO cargaPackingList(UploadedFile archivoPL)throws ServicioException {
this.filaInicio = 0;
this.filaFin = 0;
this.columnaFin=15;
PackingListRefacDTO dto = new PackingListRefacDTO();
try {
if(archivoPL==null){
returnnull; }
InputStream is = archivoPL.getInputStream();
Workbook workbook = Workbook.getWorkbook(is);
sheet = null;
sheet = workbook.getSheet(0); getExcelInicio();
getExcelFin();
asignaIndiceColumnas();
do{
//Se debe recorrer cada columna extrayendo la posición actual. }
}
listProd.add(productosDTO);
NoRegistro++;
}while(NoRegistro< this.filaFin);
dto.setProductos(listProd);
} catch (IOException ioe) {
log.error("No fue posible cargar el archivo");
ioe.printStackTrace();
thrownew ServicioException("No fue posible cargar el archivo", ioe); } catch (BiffException be){
log.error("El archivo debe tener formato xls");
be.printStackTrace();
thrownew ServicioException("El archivo debe tener formato xls", be); }
returndto; }
privatevoid notificaCeldaVacia(intcelda, String contError) throws ServicioException {
switch (celda) {
case 1:
thrownew ServicioException("Existe una celda de Modelo Vacia en el archivo xls, favor de verificar Contenedor: "+contError+" ó intente nuevamente.");
(demoras, almacenajes, maniobras o modificaciones en el flete nacional por cambio de destino o
equipo) .
El área de Producto y Compras debe enviar vía correo electrónico al área de Importaciones el
desglose de los descuentos del bloque de importación en caso de que apliquen e indicar si se cargan
al costo o a la reserva.
El área de Importaciones debe:
Ingresar a SISLOGIN para generar el costeo previo del bloque de importación
Ingresar el tipo de cambio real y el tipo de cambio estándar del pedimento
Validar que los datos de importación que aparecen en SISLOGIN sean los mismos que el
monto real pagado. En caso contrario, debe modificar el monto en SISLOGIN con la
cantidad real pagada.
Verificar que no hubo otro costo incremental. En caso de que exista, debe incluirlo en el
Sistema.
Ingresar el monto pagado de impuestos de:
o Agente Aduanal: contempla el monto, el IVA, la retención y los honorarios del Agente
Aduanal.
o Maniobras: contempla el tipo de tarifa dependiendo si la inspección de los contenedores
en la terminal portuaria es ocular o no ocular.
o Flete Nacional: contempla el tipo de tarifa dependiendo si el transporte es sencillo (1
el Flete Nacional se deben tomar en cuenta las tarifas establecidas para la Planta
Ensambladora sin importar el destino de la mercancía.
Ingresar los descuentos en caso de que apliquen
SISLOGIN debe notificar vía correo electrónico al área de Costos que hay un costeo previo de un
bloque de importación. Nota: Para efectos del costeo previo, no se toma en cuenta el IVA. En el
diagrama de flujo 2.3 se observa el flujo que se debe seguir para concretar la operación de "Costeo
Previo."
El cuadro 2.5 muestra parte de la codificación necesaria para la búsqueda de un costeo
almacenado en una base de datos.
Cuadro 2.5 "Consulta costeo previo" public String consultaCosteoPrevio() {
PackingListRefacDTO dt = (PackingListRefacDTO) data.getRowData();
costeoDTO.setBloqueValor(dt.getBloque());
CotizacionRefacService cotizacionRefacService =
(CotizacionRefacService)serviceLocator.getService("cotizacionRefacService");
CosteoPrevioRefacService costeoServ = (CosteoPrevioRefacService) serviceLocator.getService("costeoPrevioService");
try {
List<PackingListRefacDTO> packList = new ArrayList<PackingListRefacDTO>();
packList = cotizacionRefacService.consultaPackingListConArancelPrevioGuardado(costeoDTO.getBloqueValor());
costeoDTO.setResultPL(packList);
if (costeoDTO.getResultPL() != null && costeoDTO.getResultPL().size() > 0) {
costeoDTO.setDatosPL(true);
for (PackingListRefacDTO itDTO : costeoDTO.getResultPL()) {
costeoDTO.setDestino(itDTO.getDestino());
suppOrder = itDTO.getOrdenesProveedor().get(0);
if(itDTO.getListaDescuentos()!=null)
costeoDTO.setMontoOC(itDTO.getListaDescuentos().get(0).getMontoOCTotal());
if (itDTO.getBloque().trim().equals(dt.getBloque().trim())) {
try {
this.listMapa = costeoServ.obtenDetalleCotizacionSKU(itDTO.getProductos());
costeoDTO.setMapa(this.listMapa);
costeoDTO.getMapa();
this.setListMapa(costeoDTO.getMapa());
this.setListMapaSTD(costeoDTO.getMapaSTD());
} catch (ServicioException e) {
e.printStackTrace();
} }
}
}else{
FacesContext.getCurrentInstance().addMessage(null,new FacesMessage(FacesMessage.SEVERITY_ERROR,"No se encontró
infromación. Vuelva a intentar ó contacte al Administrador del Sistema.", ""));
returnnull; }
costeoDTO = costeoServ.asignaValoresConsultaCosteoPrevio(dt.getBloque(),costeoDTO);
if(costeoDTO!=null){
costeoDTO.setRealizaCotizacion(true);
setExportaExcel(true);
this.getListMapa();
this.getListMapaSTD();
return"OK";
}else
returnnull;
} catch (ServicioException e1) {
e1.printStackTrace();
FacesContext.getCurrentInstance().addMessage(null,new FacesMessage(FacesMessage.SEVERITY_ERROR,"Se produjo error al
consultar. Vuelva a intentar ó contacte al Administrador del Sistema.", ""));
[image:53.612.69.564.125.498.2]2.6.1
Comunicación con el Agente Aduanal.
Debido a la naturaleza de la importación, se debe manejar una empresa externa la cual se
encarga de clasificar los productos importados, de acuerdo al material de fabricación, con ello se
puede asignar una fracción arancelaria y un porcentaje de arancel, esta información es requerida
para la base de cálculos de SISLOGIN, ya que con ello puede aplicar la fórmula para obtener los
impuestos generados. Se desarrollo un cliente de web service para consumir un servicio web
creado por el Agente Aduanal, en el cual sistemas debe:
Enviar dentro del cliente de WS, cadena de números de parte a consultar fracción
arancelaria.
Enviar dentro del cliente de WS, la llave que identifica al sistema como un usuario
valido.
El servicio web resuelve como respuesta:
El numero de parte enviado por SISLOGIN.
La fracción arancelaria que ocupa el número de parte enviado.
El porcentaje de arancel en el que incurre el número de parte.
Fecha en la que se actualizó la información.
El diagrama 2.4 "Comunicación con Agente Aduanal", muestra los pasos a seguir para gestionar la
Diagrama 2.4 Comunicación con Agente Aduanal.
El cuadro 2.6 contiene parte de la codificación más relevante para el desarrollo de la interfaz
