UNIVERSIDAD UNIVERSIDAD SIMÓN BOLÍVAR LÍVAR

UNIVERSIDAD SIMÓN BOLÍVAR
DECANATO DE ESTUDIOS PROFESIONALES
COORDINACIÓN DE INGENIERÍA DE LA COMPUTACIÓN
IMPLEMENTACIÓN DEL MÓDULO DE COMPRAS INTERNACIONALES EN EL
SISTEMA COMPIERE ERP
Por:
JORGE ENRIQUE DUQUE NARVAEZ
INFORME FINAL DE PASANTÍA
Presentado ante la ilustre Universidad Simón Bolívar
como requisito parcial para optar al título de
Ingeniero en Computación
Sartenejas, diciembre de 2011
UNIVERSIDAD SIMÓN BOLÍVAR
DECANATO DE ESTUDIOS PROFESIONALES
COORDINACIÓN DE INGENIERÍA DE LA COMPUTACIÓN
IMPLEMENTACIÓN DEL MÓDULO DE COMPRAS INTERNACIONALES EN EL
SISTEMA COMPIERE ERP
Por:
JORGE ENRIQUE DUQUE NARVAEZ
Realizado con la asesoría de:
TUTOR ACADÉMICO: PROF. LUIS EDUARDO MENDOZA
TUTOR INDUSTRIAL: ING. JORGE LEBRÚN
INFORME FINAL DE PASANTÍA
Presentado ante la ilustre Universidad Simón Bolívar
como requisito parcial para optar al título de
Ingeniero en Computación
Implementación del módulo de Compras Internacionales
en el Sistema Compiere ERP
PROYECTO DE PASANTIA presentado por:
JORGE ENRIQUE DUQUE NARVAEZ
RESUMEN
El proyecto de pasantía fue realizado en la empresa SUMINDU, S.A., una empresa
del grupo BECOBLOHM, en búsqueda de las mejoras y la automatización de los
procesos que se llevan a cabo internamente, con el objetivo principal de incrementar
la productividad de la organización. Éste ayuda a la introducción de nuevas
tecnologías, como el ERP Compiere para aumentar el nivel de competitividad con
respecto a otras compañías y agilizar procesos propios. El proyecto consistió en
diseñar e implementar un módulo para el ERP Compiere, que permite automatizar
el proceso de las Compras Internacionales. Para llevar a cabo el proyecto se utilizó la
metodología Cascada que comprende 6 fases de desarrollo de software, de las cuales
sólo se ejecutaron las 3 primeras. Durante la primera fase se recopilaron los
requerimientos. Durante la segunda fase se hizo un análisis del negocio y se
realizaron todos los diseños de los componentes. Durante la fase de codificación se
implementó todo el módulo de Compras Internacionales. Luego se realizó el manual
de usuario de la aplicación. La fase de implantación no se efectuó ya que no se
encontraba dentro del alcance del proyecto, así como las pruebas de desempeño y de
carga, sin embargo, en la empresa se está trabajando actualmente con un prototipo
funcional que usan de manera paralela junto con la operación manual, apoyada en
Microsoft Excel, que se realiza hoy en día.
PALABRAS CLAVES:
Compiere, ERP, CRM, Orden de Compra, Java, Importación
Sartenejas, diciembre 2011
iv
INDICE GENERAL
CAPÍTULO 1 – INTRODUCCIÓN…………………………………………………..
1
CAPÍTULO 2 – ENTORNO EMPRESARIAL……………………………………...
4
2.1. Descripción de la Organización………………………………………………….
4
2.2. Reseña Histórica…………………………………………………………………..
4
2.3 Misión………………………………………………………………………………..
5
2.4 Visión………………………………………………………………………………...
6
2.5 Objetivos de la Organización……………………………………………………..
6
2.6 Servicios Ofrecidos por la Organización………………………………………..
6
2.7 Estructura Organizativa………………………………………………………….
7
CAPÍTULO 3 – MARCO TEÓRICO…………………………………………………
9
3.1 ERP.………………………………………………………………………………….
9
3.2 Software Libre……………………………………………………………………...
11
3.2.1 Licencias y sus tipos……………………………………………………………..
12
3.3 Compiere…………………………………………………………………………….
13
3.3.1 Compiere como ERP y CRM……………………………………………………
14
3.3.2 Arquitectura dirigida por modelos (MDA)…………………………………...
16
3.3.3 MDA y Compiere…………………………………………………………………
17
3.3.4 La plataforma MDA de Compiere……………………………………………..
18
3.3.5 Ventajas y desventajas que presenta la implantación de Compiere……..
19
3.3.6 Versiones de Compiere………………………………………………………….
21
3.4 Herramientas y lenguajes utilizados……………………………………………
22
3.4.2 Oracle……………………………………………………………………………...
22
3.4.3 Oracle SQL Developer…………………………………………………………..
22
3.4.4 Eclipse……………………………………………………………………………..
23
3.4.5 Subversion………………………………………………………………………...
24
CAPÍTULO 4 – MARCO METODOLÓGICO………………………………………
25
4.1 Metodología en Cascada…………………………………………………………..
25
v
4.1.1 Fases del modelo de cascada…………………………………………………...
26
4.2 Fases contempladas en la pasantía……………………………………………..
27
4.3 Variantes del Modelo………………………………………………………………
28
CAPÍTULO 5 – DESARROLLO DE LA SOLUCIÓN……………………………..
29
5.1 Fase Análisis de Requerimientos………………………………………………..
30
5.1.1 Requerimientos funcionales.…………………………………………………...
32
5.1.2 Requerimientos no funcionales………………………………………………..
34
5.1.3 Identificación de Casos de Uso………………………………………………...
35
5.2 Fase Diseño del Sistema………………………………………………………….
39
5.2.1 Documento de Arquitectura de Software – DAS……………………………
41
5.2.2 Modelo Conceptual………………………………………………………………
41
5.2.3 Diagramas de Clases……………………………………………………………
42
5.2.4 Diagramas de Secuencia………..……………………………………………...
44
5.2.5 Diagrama ER-E…………………………………………………………………..
45
5.2.6 Prototipo inicial de la interfaz…………………………………………………
46
5.3 Fase de Codificación……………………………………………………………….
47
5.3.1 Restricciones de Implementación……………………………………………..
51
5.4 Logros Adicionales…………………………………………………………………
54
CAPÍTULO 6 – CONCLUSIONES Y RECOMENDACIONES………………….
55
REFERENCIAS…………………………………………………………………………
59
APENDICE A – Lista de Requerimientos…………………………………………..
63
APENDICE B – Documento de Casos de Uso………………….…………………..
63
APENDICE C – Modelo de Interfaz…………………………………………………
63
APENDICE D–Arquitectura de Software…………………………………………..
63
APENDICE E – Ventanas del Sistema……………………...……………………..
63
APENDICE F – Logros Adicionales………………………...……………………….
63
vi
INDICE DE TABLAS
Tabla 5.1.1 Usuarios del Sistema……………………………………………………
32
Tabla 5.1.1.1 Lista de Requerimientos Funcionales……..……………………….
33
Tabla 5.1.1.2 Detalle de Requerimiento R4..……………………………………….
34
Tabla 5.1.3.1 Casos de Uso y Actores………………………………………………..
35
Tabla 5.1.3.2 Narrativa de Caso de Uso (Entrar al Sistema)……………………
38
vii
INDICE DE FIGURAS
Figura 2.7.1 Organigrama Estructural……………………………………………..
8
Figura 3.1.1 Interacción facetas del Negocio……………………………………….
9
Figura 3.3.1.1 Soluciones de Compiere ERP y CRM………………………………
15
Figura 3.3.2.1 Proceso y roles en MDA……………………………………………...
17
Figura 3.3.4.1 Plataforma MDA de Compiere………………………………...……
19
Figura 5.1.3.1 Diagrama de Casos de Uso………………………………………….
37
Figura 5.2.2.1 Modelo Conceptual……………………………………………………
42
Figura 5.2.3.1 Diagrama de Clases………………………………………………….
43
Figura 5.2.4.1 Diagrama de Secuencia del Caso de Uso “Agregar Proveedor”..
44
Figura 5.2.5.1 Diagrama ER-E……………………………………………………….
45
Figura 5.3.1 Pantalla Orden de Compra Internacional…………………………
48
Figura 5.3.2 Pantalla Detalles………………………………………………………..
49
Figura 5.3.3 Acercamiento a campo Toneladas Métricas. Campo calculado
con clase Java……………………………………………………………………...……
viii
51
LISTA DE ABREVIATURAS

AGPL: Licencia Pública General Affero. De sus siglas en ingles: Affero
General Public License.

AS400: Servidor I-Series de IBM.

BSD: Distribución del Software Berkeley. De sus siglas en ingles: Berkeley
Software Distribution.

CIM: Modelos independientes de la Computación. De sus siglas en ingles:
Computationally-IndependentModels.

COBOL: Lenguaje Común Orientado a Negocios. De sus siglas en ingles:
Common Business-Oriented Language.

CRM: Gestión de la Relación con los Clientes. De sus siglas en ingles:
Customer Relationship Management.

CVS: Sistema de Control de Versiones. De sus siglas en ingles: Concurrent
Versions System.

DBA: Administrador de Base de Datos. De sus siglas en ingles: Data Base
Administrator.

DDL: Lenguaje de definición de datos. De sus siglas en ingles: Data Definition
Language.

DML: Lenguaje de Manipulación de Datos. De sus siglas en ingles: Data
Manipulation Language.

EPL: Licencia Pública Eclipse. De sus siglas en ingles: Eclipse Public License.

ERP: Planificación de Recursos Empresariales. De sus siglas en ingles:
Enterprise Resource Planning.

FSF: Fundación para el Software Libre. De sus siglas en ingles: Free Software
Foundation.

GNU: Es un acrónimo recursivo que significa GNU No es Unix (GNU isNot
Unix).Proyecto iniciado con el objetivo de crear un sistema operativo
completamente libre: el sistema GNU.GPL.
ix

GPL: Licencia Pública General. De sus siglas en ingles: General Public
License.

IBM: Máquinas de Negocios Internacional. De sus siglas en ingles:
International Business Machines.

IDE: Entorno de Desarrollo Integrado. De sus siglas en ingles: Integrated
development environment.

Java: No es un acrónimo, es un lenguaje de programación desarrollado por
Sun Microsystems.

JDBC: Interfaz de programación de aplicaciones que permite la ejecución de
operaciones sobre bases de datos desde el lenguaje de programación Java. De
sus siglas en ingles: Java Database Connectivity.

JPEG: Grupo de Expertos Fotográficos. De sus siglas en ingles: Joint
Photographic Experts Group.

MDA: Arquitectura Dirigida por Modelos. De sus siglas en ingles: ModelDriven Arquitecture.

MPL: Licencia pública de Mozilla. De sus siglas en ingles: Mozilla Public
License

MRP: Planificación de Requerimientos de Material. De sus siglas en ingles:
Material Requirements Planning.

PHP: Lenguaje de programación interpretado, diseñado originalmente para la
creación de páginas web dinámicas. De sus siglas en ingles: Hipertexto Preproceso.

PIM: Modelos Independientes de la Plataforma. De sus siglas en ingles:
Platform-Independent Models.

PSM: Modelos Específicos de la Plataforma. De sus siglas en ingles: PlatformSpecific Models.

SAP: Análisis de Sistemas y Desarrollo de Programas. De sus siglas en ingles:
System Analysis and Program Development.
x

SDD: Documento de Diseño del Software. De sus siglas en ingles: Software
Design Document.

SQL: Lenguaje de Consulta Estructurado. De sus siglas en ingles: Structured
Query Language.

SRD Documento de Sistema de Referencia. De sus siglas en ingles: System
Reference Document.

SVG: Gráficos Vectorial Escalable. De sus siglas en ingles: Scalable Vector
Graphics.
xi
CAPÍTULO 1
INTRODUCCIÓN
En los tiempos actuales, cada vez son menos las empresas que no tienen sus
negocios manejados por algún sistema automatizado que les sirva de ayuda a la hora
de realizar las operaciones del día a día. Sin embargo, estos sistemas que en algún
momento han sabido cumplir y satisfacer con todos los requerimientos de la
empresa, en los tiempos actuales tal vez no sean los más adecuados para una
empresa que se encuentra en proceso de expansión y con miras a suplir y competir
en el mercado internacional. Este es el caso de SUMINDU, S.A., una empresa que
apunta a consolidarse como líder del mercado nacional y pasar, a mediano plazo, a
competir en el mercado internacional.
El proyecto General de la empresa tiene como objetivo la puesta en producción del
sistema de Planificación de Recursos Empresariales (Enterprise Resource Planning,
ERP) Open Source Compiere en SUMINDU, S.A. En la empresa hay partes del
negocio que funcionan con un sistema en AS400 de IBM. Sin embargo, hay partes
del negocio que aún a estas alturas simplemente trabajan de manera manual; es
decir, con Hojas en Excel. Una de las partes del negocio que trabaja de esta manera
es el departamento de Compras Internacionales.
El departamento de Compras Internacionales abarca el 97 % de las compras de la
empresa por lo que un sistema automatizado que le pueda brindar el soporte y
2
seguimiento necesario a todo el proceso de la compra, pasa de ser un deseo a una
necesidad.
Compiere es un sistema ERP de código abierto que cuenta ya con ciertas
funcionalidades útiles para SUMINDU, S.A., en particular para el módulo de
Compras Internacionales, pero hay otras funcionalidades que son requeridas por el
departamento con las que no cuenta Compiere, como por ejemplo, un seguimiento de
la mercancía desde que sale del proveedor fuera del país a través de todos los
procesos que hay que cumplir para su entrada al país y finalmente es recibida por el
almacén de destino. Compiere permite crear y/o desarrollar estas funcionalidades,
ya sea trabajando con las opciones del sistema o modificando su código fuente. Esto
se puede hacer en Compiere por la flexibilidad que brinda ser de código abierto.
Inicialmente, se desarrollaron los módulos del negocio y posteriormente los módulos
contables y administrativos.
SUMINDU es una empresa del grupo BECOBLOHM, y este grupo tiene como
objetivo que cada una de las empresas que conforman el grupo migren sus sistemas
al ERP Compiere. Esta migración la realiza la empresa de manera descentralizada y
asimismo, cada una de las empresas están migrando bajo sus propios parámetros y
necesidades.
Los objetivos de este trabajo de pasantía son:
Objetivo General

Desarrollar el prototipo funcional del Módulo de Compras Internacionales
para ser implementado en Compiere ERP (Enterprise Resource Planning).
Objetivos específicos

Realizar el análisis de los Proveedores, productos que ofrece y formas de
venta.

Levantar, en Compiere, el maestro de proveedores de la empresa.
3

Crear, en Compiere, el maestro de productos y codificación.

Desarrollar el Módulo de Fletes.

Desarrollar el Módulo de Rastreo de Mercancía.

Desarrollar el Módulo de Servicios Aduanales.
Para cumplir con los objetivos planteados se utilizó la metodología Cascada que
comprende 6 fases de desarrollo de software, de las cuales sólo se ejecutaron las 3
primeras: Análisis de Requerimientos, Diseño del Sistema y Codificación. Luego se
realizó el manual de usuario de la aplicación. La fase de implantación no se efectuó
ya que no se encontraba dentro del alcance del proyecto.
El resto del informe está estructurado como sigue: en el Capítulo 2 se definen las
características que distinguen a la empresa con el fin de proveer una idea global del
ambiente de trabajo donde fue desarrollado el proyecto. En el Capítulo 3 se
presentan las bases teóricas y se presentan las herramientas utilizadas para la
construcción del sistema. En el Capítulo 4 se expone la metodología utilizada para el
desarrollo de la aplicación. En el Capítulo 5 se describen las actividades más
importantes realizadas en cada una de las fases del desarrollo. Finalmente, en el
Capítulo 6 se detallan las conclusiones y recomendaciones futuras para el proyecto.
CAPÍTULO 2
ENTORNO EMPRESARIAL
En este capítulo se describe el entorno empresarial en el cual el proyecto de
pasantía fue desarrollado. Con el fin de conocer a la empresa SUMINDU, S.A se
expone brevemente la trayectoria de la empresa, su misión y visión, seguido de la
estructura corporativa y, finalmente, la ubicación del pasante dentro de la empresa.
2.1. Descripción de la Organización [1]
SUMINDU, S.A. es una empresa distribuidora de aceros especiales, inoxidables y
otros metales. Cuenta con sucursales en diferentes puntos del país, lo que permite
atender las necesidades de los clientes en tiempo récord. Posee un amplio inventario
de aceros de diversos tipos, formas, y calidades en rangos de medidas que abarcan
los usos más comunes del mercado nacional.
Mantiene un alto nivel de confiabilidad para los clientes, ya que cuenta con un
sistema de aseguramiento de la calidad, certificado bajo la norma Covenin - ISO
9001:2000. Ofrece además diversos servicios a los clientes tales como corte, despacho
y asesoría técnica.
2.2. Reseña Histórica [2].
La empresa fue fundada el 23 de junio del año 1969, por iniciativa de capitales
privados y en el año de 1986, luego de una reestructuración de la gerencia,
cambiando también objetivos y metas. SUMINDU se encaminó a ser la primera
5
empresa en la distribución de aceros especiales, inoxidables y aleaciones no ferrosas
del país; haciendo énfasis en el servicio y el respeto a sus clientes y proveedores.
La sede principal de SUMINDU, S.A. se encuentra en Caracas; asimismo, posee
cuatro 4 almacenes, los cuales se encuentra ubicados en Barcelona, Maracaibo,
Puerto Ordaz y Valencia, manteniendo un inventario de material, adecuado para
satisfacer las demandas de sus clientes, los cuales se encuentran distribuidos en
gran parte del territorio nacional.
La empresa cuenta con equipos de corte, manipulación de materiales y transporte
adecuado para realizar la entrega de los pedidos en el tiempo y las dimensiones
ofrecidas. SUMINDU, S.A., establece como una de sus prioridades comerciales, el
distribuir sus materiales en un tiempo de entrega acordado con el cliente.
SUMINDU S.A., cuenta con más de 170 empleados, hombres y mujeres con una
filosofía de trabajo en equipo, servicio y calidad. Ellos siguen programas
permanentes de adiestramiento y mejoramiento profesional para lograr llevar
adelante el buen funcionamiento de la organización.
2.3 Misión [3]
Comercializar Aceros Especiales, Inoxidables y Materiales no Ferrosos, de la más
alta calidad, producidos por proveedores de trayectoria reconocida, con la
contribución de personal calificado, instalaciones, equipos adecuados para el manejo
de los productos y el apoyo de recursos tecnológicos que permitan satisfacer las
necesidades y expectativas de nuestros clientes en pro de su desarrollo, para así
consolidar una empresa rentable, eficiente y confiable, capaz de adaptarse a las
exigentes condiciones del mercado y generar bienestar a nuestros colaboradores y
accionistas.
6
2.4 Visión [4]
Ser la mejor empresa del país en la distribución de Aceros Especiales, Inoxidables y
Materiales no Ferrosos, suministrando productos y servicios de primera calidad que
les proporcionen a nuestros clientes ventajas comparativas y competitivas.
2.5 Objetivos de la Organización
Los objetivos de la Empresa SUMINDU S.A., son:

Mantener un Sistema de Gestión de la Calidad bajo el modelo COVENIN ISO
9001:2000 en un total cumplimiento.

Implementar un Sistema de Higiene y Seguridad Industrial a nivel nacional.

Implementar un sistema de control y búsqueda automática de los Certificados
de Calidad de los Proveedores de importación a nivel nacional.

Establecer un mecanismo donde el personal de ventas pueda tener
información más precisa sobre los cortes por naves y barras completas.

Aumentar la cantidad de clientes con ventas realizadas en cada cartera
existente.

Evaluar a nuestros clientes activos para obtener información por el servicio
que prestamos.
2.6 Servicios Ofrecidos por la Organización [5]
SUMINDU, S.A. ofrece diferentes servicios para todos sus clientes con la finalidad
de satisfacer sus requerimientos y exigencias. Los Servicios que ofrece SUMINDU,
S.A. se dividen en: El Servicio de Corte, El Servicio de Asesora Técnica, El Servicio
de Transporte o Despacho y El Servicio de Compra de Importación Directa a Cliente.
A continuación se describe cada uno de los servicios:
El Servicio de Corte: Cada uno de los diferentes tipos de materiales que
comercializa SUMINDU, S.A. puede ser vendido en piezas completas, ya que los
mismos se compran en longitudes estándar. Los requerimientos y exigencias de
7
todos los clientes de la empresa son diferentes, cada uno de ellos, transforma el
material de acuerdo a su actividad comercial.
El Servicio de Asesoría Técnica: consiste en proporcionar información para
orientar y recomendar el Material acorde con el proceso de fabricación del producto
final del cliente, de acuerdo con sus requerimientos y exigencias. Este servicio
también es ofrecido a través de dos empresas, que trabajan bajo convenio con
SUMINDU, S.A. para brindar asesoría técnica.
El Servicio de Transporte y Despacho: Este servicio se lleva a cabo diariamente.
Los pedidos son entregados a sus respectivos clientes en los vehículos propiedad de
SUMINDU, S.A. Estos son transportes equipados apropiadamente, para el correcto
y efectivo traslado de la mercancía desde los almacenes de SUMINDU, S.A. hasta la
dirección indicada por sus clientes.
El Servicio de Compras de Importación Directa a Clientes: SUMINDU, S.A. es una
empresa dedicada a la distribución de aceros especiales e inoxidables y otros
materiales, y cabe destacar que existen más de 3.000 calidades de aceros, que no
todos son comercializados por la empresa; es por ello que surge la idea del Servicio
de Compras, que consiste en la adquisición de materiales importados solicitados por
el cliente, en cantidades, formas y medidas específicas
2.7 Estructura Organizativa
SUMINDU, S.A. cuenta con una estructura organizacional vertical (ver Figura
2.7.1), conformada por 5 niveles jerárquicos manejados de la siguiente manera: El
primer nivel corresponde a la Gerencia General, el segundo nivel corresponde a los
Gerentes de Áreas, el tercer y cuarto nivel a los cargos de nivel medio (Asistentes,
Coordinadores, Jefes y Encargados) y el quinto nivel para cargos básicos y
operativos (Analistas, Auxiliares, Choferes, Oficinistas, entre otros).
8
El pasante laboró en la sección de Sistemas llevando a cabo labores de Analista y
Programador bajo la supervisió
supervisión
n de la gerencia de este departamento.
Figura 2.7.1 Organigrama Estructural. Fuente: (Organización y Métodos Sumindu, 2011)
CAPÍTULO 3
MARCO TEÓRICO
Este capítulo tiene por objetivo presentar los conceptos teóricos sobre los cuales se
basa el proyecto de pasantía como: ERP, Software Libre, Compiere y MDA.
Asimismo se exponen las tecnologías empleadas: Oracle, Oracle SQL Developer,
Eclipse y Subversion.
3.1 ERP
Los Sistemas de Planificación Empresarial (Enterprise Resource Planning, ERP)
se definen como un sistema de administración de negocios que integra todas las
facetas del negocio, incluyendo planificación, manufactura, ventas, compras y
finanzas (Ver Figura 3.1.1). El software ERP planea y automatiza muchos procesos
con la meta de integrar información a lo largo de la empresa y elimina los complejos
enlaces entre los sistemas de las diferentes áreas del negocio [6].
Finanzas
Manufacturación
Compras
Sistema ERP
Contabilidad
Ventas
Recursos
Humanos
Y otros más
Figura 3.1.1 Interacción facetas del Negocio [6].
10
Una lista de las secciones de negocio que podría manejar un ERP serían: el manejo
de una cadena de suministros, desde la compra y recepción de la materia prima; la
manufactura, hasta la venta del producto final; el manejo de los recursos humanos;
la gestión de finanzas; el manejo de la contabilidad de la empresa; la gestión de
proyectos, y muchas otras actividades que se llevan a cabo a nivel empresarial [7].
Lo más destacable de un ERP es que unifica y ordena toda la información de la
empresa en un solo lugar. De este modo cualquier suceso queda a la vista de forma
inmediata, posibilitando la toma de decisiones de forma más rápida y segura,
acortando así los ciclos productivos. Con un ERP tendremos la empresa bajo control
e incrementaremos la calidad de nuestros servicios y productos. La implantación de
un ERP conlleva la eliminación de barreras ínter departamentales; la información
fluye por toda la empresa eliminando la improvisación por falta de información [7].
Por otro lado, los ERP se definen como paquetes de sistemas configurables de
información dentro de los cuales se integra los datos a través de áreas funcionales de
la organización [8].
La creciente y sostenida demanda de los ERP en el mercado empresarial resulta
notable. Algunas necesidades fundamentales de las empresas como justificación de
este interés son: [9]
• La necesidad de contar con una plataforma tecnológica que mejore el
procesamiento de las órdenes de los clientes.
• La necesidad de consolidar y unificar las funciones del negocio, tales como
manufactura, finanzas, distribución-logística y recursos humanos.
• La necesidad de integrar diversas tecnologías de información, junto con los
procesos subyacentes que soportan, en una única columna vertebral de información,
en un denominador común informático que mejore la eficiencia.
• La necesidad de contar con una infraestructura informática que permita a las
empresas adaptarse rápidamente al entorno actual de los negocios; esto implica el
11
disponer de capacidades como multi-idiomas, multimonedas, multicompañías,
etcétera.
La percepción de la alta inversión requerida, en términos de tiempo y costo,
constituye una de las mayores preocupaciones de las organizaciones a la hora de
emprender un proyecto de esta naturaleza. Inclusive, los sistemas ERP se ven como
aptos para las grandes organizaciones que pueden permitirse invertir en el rediseño
de los procesos medulares del negocio [9]. Es importante que los usuarios estén
convencidos de los beneficios que se obtendrán con los ERP, pues esto facilitará la
implementación en la empresa [10].
Los ERP son una evolución de los sistemas de Planificación de Requerimientos de
Material (Materials Requirement Planning, MRP), los cuales estaban enfocados
únicamente en la planificación de materiales y capacidades productivas. Esta
planificación se efectúa enfrentando los requerimientos de materiales y capacidad de
los productos a fabricar contra las existencias y capacidades sin asignar. Los ERP
son el núcleo de otras aplicaciones como pueden ser la Gestión de las Relaciones con
los Clientes (Customer Relationship Management, CRM), Data Mining (Conversión
de datos en información útil) [11].
3.3 Software Libre
El software libre se refiere a la libertad de los usuarios para ejecutar, copiar,
distribuir, estudiar, modificar el software y distribuirlo modificado. El software libre
suele estar disponible gratuitamente, o al precio de costo de la distribución a través
de otros medios; sin embargo no es obligatorio que sea así, por lo tanto no hay que
asociar software libre a software gratuito, ya que, conservando su carácter de libre,
puede ser distribuido comercialmente [12].
12
Son cuatro las libertades las que debe cumplir una aplicación para que pueda
considerase como software libre: [13], [14]
1. Se tiene la libertad de usar el programa, con cualquier propósito.
2. Se tiene la libertad de estudiar cómo funciona el programa, y adaptarlo a las
necesidades.
3. Se tiene la libertad de distribuir copias, con lo que puedes ayudar a tu vecino y
4. Se tiene la libertad de mejorar el programa y hacer públicas las mejoras a los
demás, de modo que toda la comunidad se beneficie.
El software libre es aquel que puede ser distribuido, modificado, copiado y usado;
por lo tanto, debe venir acompañado del código fuente para hacer efectivas las
libertades que lo caracterizan [13].
3.2.1 Licencias y sus tipos
Una licencia es aquella autorización formal con carácter contractual que un autor
de un software da a un interesado para ejercer actos de explotación legales. Pueden
existir tantas licencias como acuerdos concretos se den entre el autor y el
licenciatario. Desde el punto de vista del software libre, existen distintas variantes
del concepto o grupos de licencias: [13]

Licencias GPL, Licencia Pública General (General Public License)

Licencias AGPL, Licencia Pública General Affero (Affero General Public
License)

Licencias BSD, Distribución del Software Berkeley (Berkeley Software
Distribution)

Licencias MPL, Licencia Pública Mozilla y Derivadas (Mozilla Public License)
La Licencia Pública General (más conocida por su acrónimo en inglés GPL) es con
diferencia la licencia más popular de todas las licencias del mundo del software libre.
Su autoría corresponde a la Fundación de Software Libre (Free software
13
Foundation, FSF) y es también la licencia más utilizada, incluso por proyectos con
tanta reputación del mundo del software libre y código de fuente abierto como Linux.
La licencia GPL pretende garantizar la libertad de compartir y modificar software
libre más allá del ámbito contractual inmediato, asegurando que el software sea
libre también para otros usuarios posteriores [14].
El Compiere se distribuye bajo los términos de la GNU General Public License
(GPL). Las licencias de código abierto ofrecen una oportunidad única para la
comunidad de código abierto y para los que desarrollan software de código abierto.
[15]
3.3 Compiere
Compiere es el líder del mercado entre las compañías de Open Source Software. Se
desarrolló en el año 1999, con capital de riesgo de $ 6 millones, por un grupo de ex
funcionarios de alto rango de la División de Aplicaciones de Oracle (es decir, su
operación de software ERP). Los fundadores tenían típicamente diez, veinte o más
años de experiencia en ventas, consultoría o desarrollo [16].
El software Compiere ERP está destinado a las pequeñas y medianas empresas
(PYME). Este fue un segmento objetivo de mercado distinto a la corriente principal
porque inicialmente su software fue en general demasiado complejo y costoso de
instalar. La oferta inicial de Compiere ERP era muy limitada en sus capacidades,
constaba de módulos básicos en la gestión de inventarios, contabilidad y gestión de
relaciones con los clientes (CRM) [16].
Compiere genera ingresos ofreciendo servicios de apoyo y formación. Su
trayectoria de crecimiento tiene algunos paralelismos con los primeros años de SAP.
Como SAP, Compiere ha fomentado y certificado consultores, y utilizaron su primera
mano de inteligencia de mercado para ayudar a definir las capacidades de su
software [16].
14
Compiere fue originalmente diseñado y escrito por Jorg Janke quien tiene 20 años
de experiencia en sistemas ERP, certificación en Java y DBA Oracle. En 1999, Jorg
Janke y Rosa Kathy comenzaron el desarrollo de las soluciones basadas en Java,
Compiere, y en el 2000 instalaron la primera versión del software. La primera
instalación fue patrocinada por Goodyear en Alemania. El sitio piloto ha estado en
producción desde mayo de 2000. Compiere es utilizado por pequeñas y medianas
empresas en todo el mundo. El programa ha sido implementado en una amplia
variedad de industrias, así como por agencias gubernamentales [17].
3.3.1 Compiere como ERP y CRM
Compiere es un sistema de amplia capacidad y profunda integración de código
abierto ERP y de solución de negocios CRM. La solución está construida sobre una
plataforma de aplicaciones basada en modelos de gran alcance que le da la
capacidad para ejecutar su negocio. El uso del software Compiere de soluciones
negocios automatiza todas las funciones financieras, distribución, ventas y servicio
de una manera rápida, asequible y fácil [18].
La plataforma de Compiere es administrada de la siguiente manera: [18]

Informes estándar: Gestiona el rendimiento de la empresa mediante informes
y herramientas estándar de reportes integrados.

Paneles de gestión: Son paneles basados en funciones que permiten
profundizar para controlar y analizar sus operaciones de manera más eficaz.

La Vista de negocios: Es un acceso seguro a los datos empresariales a través
de esquemas de presentación de informes optimizados.
Las soluciones en ERP disponibles para la última versión de Compiere son: [18]

Producción: Controla las operaciones de Producción en la planificación de
materiales, planificación de la producción y las capacidades de ejecución en
taller.
15

Gestión de almacenes: Mejorará la productividad mediante la automatización
de almacenes de logística de entrada y salida.

Compras: Cubre los procesos de negocio necesarios para la creación de
requisiciones, órdenes de compra, recepción de facturas de proveedores, y el
procesamiento de pagos.

Gestión
de
materiales:
Gestiona
los
recibos
de
inventario,
envíos,
movimientos y cuentas a través de los almacenes, proveedores y clientes.

Gestión de pedidos: Controla los comentarios de creación, los libros de
pedidos, gestión de materiales, generar facturas y recoger dinero en efectivo.

Gestión Financiera Global: Automatiza los procesos de solución empresarial y
maneja los registros financieros.
Las soluciones en CRM disponibles para la última versión de Compiere son: [18]

Ventas: Controla la gestión de relación con los clientes.

Comercio
electrónico:
Permite
administrar
una
tienda
web
de
almacenamiento seguro.

Servicio: Gestiona el ciclo de vida completo de prestación de servicios.

Historia de los clientes: Muestra una vista de 360 grados de las interacciones
con los clientes.
Lo anteriormente descrito puede verse resumido en la Figura 3.3.1.1
Figura 3.3.1.1 Soluciones de Compiere ERP y CRM. [18]
16
3.3.2 Arquitectura dirigida por modelos (MDA)
El papel de los modelos es fundamental en el desarrollo de software para potenciar
el reúso de los diferentes elementos del software y facilitar la labor de los diferentes
roles que participan del proceso. La Arquitectura Dirigida por Modelos (Model
Driven Architecture, MDA) propone un proceso de desarrollo basado en la realización
y transformación de modelos. Los principios en los que se fundamenta MDA son la
abstracción, la automatización y la estandarización. El proceso central de MDA es la
transformación de modelos que parten del espacio del problema hasta modelos
específicos de la plataforma, pasando por modelos que describen una solución
independientemente de la computación [19].
En MDA, el proceso de transformación se realiza de forma asistida utilizando
mecanismos que garantizan la consistencia con los modelos anteriores. Para tal
propósito MDA caracteriza los siguientes tipos de modelos: [19]

CIM
(Computation
Independent
Model):
Representa
los
modelos
independientes de la computación que caracterizan el dominio del problema.

PIM (Platform Independent Model): Representa los modelos que describen
una solución de software que no contiene detalles de la plataforma concreta en
la que la solución va a ser implementada.

PSM (Platform Specific Model): Son los modelos derivados de la categoría
anterior, que contienen los detalles de la plataforma o tecnología con que se
implementará la solución. Estos modelos se construyen entre el diseño y la
codificación.

Y, finalmente, el código mismo que se genera después de la codificación y las
pruebas.
A la luz de este enfoque, surgen nuevos esquemas de trabajo en los que se
distinguen los diferentes roles de los participantes del proceso (Ver Figura 3.3.2.1):
a) EI analista de negocio, experto en el dominio del problema, que modela una
17
realidad por medio de CIM; b) el arquitecto y el diseñador que definen una
propuesta de solución (transformación del CIM en PIM) y progresivamente la
concretan (transformación de PIM a PIM), hasta llegar a un diseño detallado; c) el
desarrollador o el probador que tiene amplio conocimiento de la tecnología y decide
la manera más adecuada cómo el diseño detallado se implementará en una
plataforma particular (transformación del PIM a PSM) [19].
Figura 3.3.2.1 Proceso y roles en MDA. [19]
3.3.3 MDA y Compiere [20]
Compiere utiliza una arquitectura dirigida por modelos para aumentar la
capacidad de adaptabilidad de la aplicación, un despliegue más rápido de la misma y
una reducción en los costos como propietario del software. Este tipo de diseño
permite que la aplicación sufra personalizaciones de manera inmediata, como:

Agregar nuevas columnas a las tablas.

Agregar validaciones de manera opcional.

Rediseñar las ventanas de la aplicación para agregar nuevos campos.

Agregar nuevos datos a través de las ventanas de la aplicación.

Crear reportes que ya contengan los campos que se agregaron.
18
El MDA de Compiere ofrece:

Rápida personalización de las aplicaciones a las necesidades empresariales
específicas.

Una mayor estabilidad porque las ventanas y los informes son generados a
partir de reglas almacenadas en un diccionario de la aplicación activa en
lugar de programar utilizando código 3GL.

Una mayor productividad para los desarrolladores y los usuarios.

Personalización de las aplicaciones accesibles en cualquier momento sin el
personal de programación especializada.

Preservación de las personalizaciones al actualizar.
3.3.4 La plataforma MDA de Compiere
Compiere permite automatizar todas las finanzas, distribución, ventas y servicio
de forma rápida y sencilla. Al mismo tiempo, utiliza un innovador modelo de
arquitectura dirigida que le da la capacidad de adaptación sin precedentes, una gran
velocidad de implementación y bajo costo de propiedad [21].
Compiere se compone de un diccionario de aplicaciones, un motor de transacción y
una base de datos de transacciones. El diccionario es el repositorio de aplicaciones de
la lógica de negocio de meta-datos, tales como ventanas, campos, informes y las
definiciones de flujo de trabajo. La base de datos de transacción es el depositario de
la transacción (por ejemplo, las facturas) y la puesta en marcha (por ejemplo, los
clientes) de datos. El motor de transacciones gestiona la interacción entre la lógica
del negocio del diccionario de aplicaciones, los datos de las transacciones de la base
de datos de transacciones y las solicitudes de los usuarios [21].
A continuación se muestra, en la Figura 3.3.4.1 una representación de lo
anteriormente descrito:
19
Figura 3.3.4.1 Plataforma MDA de Compiere. [21]
3.3.5 Ventajas y desventajas que presenta la implantación de Compiere
A la hora de la implantación del software en una empresa es necesario conocer el
conjunto de ventajas y desventajas que éste presenta.
Ventajas: [15], [20]

Bajos costos en adquisición de hardware debido a que no es necesario instalar
componentes adicionales.

Bajos costos de configuración, ya que las configuraciones adicionales
requeridas traen costos prácticamente nulos ya que pueden ser aplicados por
el personal experto de la empresa.

Bajo costo de implementación, ya que la instalación de la aplicación es rápida
y no hace falta tener algún sistema operativo o manejador de base de datos
especial.

Bajos costos en la adaptación de los procesos del negocio debido a los bajos
costos de configuración que tiene el sistema.

La actualización a una versión más nueva no es tan costosa. La empresa
puede absorber dicha actualización sin causar un gran impacto en sus
finanzas.

Ofrece un mejor control sobre los proveedores y los precios que tienen los
productos que despachan.
20

El acceso a la información es más rápido y fácil para ayudar al proceso de
toma de decisiones.

Permite tener al día las finanzas de la compañía y cerrar los ciclos fiscales de
manera más rápida.

Permite que el cliente sienta una mayor satisfacción acerca de los productos y
servicios que recibe por parte de la compañía.

La aplicación Compiere es independiente del sistema operativo, de la base de
datos, del hardware y del explorador Web que se esté utilizando en una
compañía.

Los desarrolladores de Compiere siempre están actualizando y corrigiendo los
problemas que tenga el sistema.

La productividad de los desarrolladores y usuarios de la aplicación aumenta
gracias a un conjunto de facilidades que presta el tener un sistema como
Compiere.
Desventajas: [15], [20]

Esta solución ha sido desarrollada para el mundo de las medianas y pequeñas
empresas, por esta razón las grandes compañías siguen actualmente
implementando los servicios de proveedores de ERP comerciales.

La interfaz de la aplicación es muy rígida y no es muy amigable, es una gran
restricción ya que los usuarios pueden reaccionar de manera negativa a la
hora de interactuar con el sistema.

Aunque Compiere se puede adquirir de manera gratuita y es de código
abierto, es necesario pagar una licencia para poder obtener el soporte técnico
y la documentación del sistema.

Los problemas que presente el software a nivel de su lógica, de interfaz o de
conexión con la base de datos no son resueltos de manera inmediata como lo
haría el personal que mantiene un sistema pago en una empresa.

Compiere a pesar de pertenecer al mundo del software de código abierto, ha
ignorado los avances y desarrollos que han hecho compañías que trabajan con
21
el sistema. Por lo que no han entrado a formar parte del código fuente de
Compiere, lo que no contribuye a la unificación y trabajo comunitario en el
que debería estar inmerso un sistema con estas características.
3.3.6 Versiones de Compiere [22]
Actualmente Compiere cuenta con dos ediciones que ofrecen soluciones ERP. La
versión que se utilizó en este proyecto es la Compiere Professional Edition.
Compiere Professional Edition (Edición Profesional de Compiere): Esta versión
está enfocada en las medianas y grandes empresas, prestando las mejores
funcionalidades, la mayor usabilidad y el mejor soporte de la solución ERP
Compiere. Tiene una arquitectura Web interactiva, para aprovechar la experiencia
productiva de los usuarios desde un explorador Web. Tiene un soporte ilimitado y es
distribuida bajo una licencia comercial. El código puede ser modificado por el equipo
de desarrollo que se encargue de administrarlo.
Compiere Community Edition (Edición Comunitaria de Compiere): Es para todas
aquellas medianas y pequeñas empresas que quieren aprovechar la adaptabilidad
del software al entorno del negocio. Tanto el código ejecutable como el código fuente
están disponibles de manera gratuita. No incluye la actualización del software ni la
documentación y soporte del ERP. Está edición está distribuida bajo la licencia GPL
(Licencia Pública General) versión 2, y tiene la restricción de no poder restringir el
uso, copia o modificación del nuevo código que se incluye al software.
Compiere requiere de un software de gestión de datos para procesar su ERP y
CRM de información y transacciones. El software está certificado para trabajar con
Oracle (Express, Standard, Standard One y Enterprise Edition) y Postgres
Enterprise DB, proporcionando a los clientes una amplia gama de plataformas de
bases de datos y opciones de precios.
22
3.4 Herramientas y lenguajes utilizados
En esta sección se presentan las tecnologías, herramientas y lenguajes que fueron
utilizadas para la realización del proyecto, ya que son elementos necesarios para
hacer que un ERP como el de Compiere pueda ser personalizado y mantenido en la
empresa.
3.4.1 Oracle
Oracle es básicamente una herramienta cliente/servidor para la gestión de Bases
de Datos. Para su utilización sería necesaria principalmente la instalación de la
herramienta servidor y posteriormente se puede atacar a la base de datos desde
otros equipos con herramientas de desarrollo como Oracle Designer y Oracle
Developer, que son las herramientas básicas de programación sobre Oracle. Es
posible lógicamente atacar a la base de datos a través del SQL plus incorporado en
el paquete de programas Oracle para poder realizar consultas, utilizando el lenguaje
SQL [24].
Oracle XE es totalmente gratuito para ser utilizado en los procesos de desarrollo
de software. La última versión de este software es la 10g que se basa en el sistema
Oracle Database 10g. Esta herramienta puede ayudar durante el desarrollo y el
despliegue de la aplicación para la realización de pruebas con una buena
infraestructura, para luego migrarla a una herramienta más poderosa como la
versión que no es expresa. Las restricciones de trabajar con la versión XE son: sólo
puede almacenar hasta 4 GB (Giga Byte) de memoria, sólo puede usar hasta 1 GB
de memoria RAM (Memoria de acceso aleatorio) y sólo usa un CPU (Unidad Central
de Procesamiento) por máquina [24]. Esta es la versión utilizada para el desarrollo
del módulo.
3.4.2 Oracle SQL Developer [25]
Es la herramienta gráfica gratuita que proporciona Oracle para desarrollar, o
simplemente para ejecutar consultas o scripts SQL (Standard Query Languages),
23
tanto DML (Data Manipulation Language) como DDL (Data Definition Language),
sobre bases de datos Oracle.
Además, en las últimas versiones esta herramienta ha incorporado mejoras como
permitir la conexión con otras bases de datos tales como, SQLServer, MySQL o
Access. La conexión con MySQL o SQLServer se realiza a través de JDBC, y de
manera bastante sencilla. Una vez establecida la conexión, se pueden explorar los
objetos de las bases de datos como si se tratara de una base de datos de Oracle, y
ejecutar sobre ellas sentencias SQL. En cuanto a funcionalidades más avanzadas,
como la creación de estructuras, este tipo de conexión estará mucho más limitada.
La herramienta está escrita en Java y su versión estable más reciente es la 3.3.
3.4.3 Eclipse [26]
Eclipse es una plataforma de desarrollo de software de diferentes lenguajes. Está
compuesta por un IDE (Entorno de desarrollo integrado), que consiste en una
aplicación que tiene un editor de código, un compilador, herramientas de
construcción automáticas y un depurador, para facilitar el desarrollo de los
programas. El otro componente de Eclipse es el sistema de “plug-in” (software o
herramientas adicionales) utilizado para extender la herramienta. Esta plataforma
ésta escrita en código Java, y es utilizada para desarrollar aplicaciones tanto en
Java, como en otros lenguajes de programación tales como C, C++, COBOL, Python
y PHP, entre otros.
Eclipse es un software que ha sido liberado desde el año 2004 bajo la Licencia
Pública de Eclipse (EPL) que no es compatible con la GPL, pero no evita que Eclipse
sea un sistema libre y de código abierto.
Eclipse dispone de un Editor de texto con resaltado de sintaxis. La compilación es
en tiempo real. Tiene pruebas unitarias con JUnit, control de versiones con CVS,
integración con Ant, asistentes (wizards) para creación de proyectos, clases, tests,
24
etc., y refactorización. Asimismo, a través de "plugins" libremente disponibles es
posible añadir control de versiones con Subversion.
3.4.4 Subversion [27]
Subversion es un sistema de control de versiones diseñado específicamente para
reemplazar al popular CVS (Concurrent versions system). Es un software libre bajo
una licencia de tipo Apache/BSD y se le conoce también como SVN, por ser el
nombre de la herramienta utilizada en la línea de órdenes.
Una característica importante de Subversion es que, a diferencia del CVS, los
archivos versionados no tienen cada uno un número de revisión independiente, en
cambio, todo el repositorio tiene un único número de versión que identifica un estado
común de todos los archivos del repositorio en un instante determinado.
Subversion puede acceder al repositorio a través de redes, lo que le permite ser
usado por personas que se encuentran en distintas computadoras. A cierto nivel, la
posibilidad de que varias personas puedan modificar y administrar el mismo
conjunto de datos desde sus respectivas ubicaciones fomenta la colaboración. Se
puede progresar más rápidamente sin un único conducto por el cual deban pasar
todas las modificaciones. Puesto que el trabajo se encuentra bajo el control de
versiones, no hay razón para temer que la calidad del mismo vaya a verse afectada,
si se ha hecho un cambio incorrecto a los datos; simplemente se deshace el cambio.
CAPÍTULO 4
MARCO METODOLÓGICO
Para el desarrollo del proyecto de pasantía se aplicó la metodología usada por la
empresa, la cual es una metodología de desarrollo en Cascada. A continuación se
presentará qué es la metodología en Cascada y cómo está estructurada.
4.1 Metodología en Cascada [28].
En Ingeniería de software el desarrollo en cascada, también llamado modelo en
cascada, es el enfoque metodológico que ordena rigurosamente las etapas del proceso
para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar
a la finalización de la inmediatamente anterior.
Las fases de la metodología de desarrollo en cascada usada en la pasantía son:
1. Análisis de Requerimientos
2. Diseño del Sistema
3. Codificación
4. Pruebas
5. Verificación
6. Implantación
De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce
necesariamente al rediseño y nueva programación del código afectado, aumentando
los costes del desarrollo. La palabra cascada sugiere, mediante la metáfora de la
26
fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases
más avanzadas de un proyecto. El alcance del proyecto de pasantía se definió hasta
la etapa de codificación por limitaciones de tiempo. Esto indica que la fase de
pruebas e implantación que plantea el pase del software a producción no fue llevada
a cabo, y queda pendiente para cuando se retome el desarrollo del módulo. Sin
embargo, se tiene puesta una versión en desarrollo a los usuarios de tal manera que
ellos puedan trabajar un paralelo, de la manera en la que lo venían haciendo y
usando además con Compiere y el módulo de Compras Internacionales. De esta
forma, los usuarios pueden ir entrando en contacto con el sistema, adquirir
destrezas en sus funciones básicas e ir revisando lo que es cada módulo y su correcto
funcionamiento.
4.1.1 Fases del modelo de cascada
1 Análisis de Requerimientos: En esta fase se analizan las necesidades de los
usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase
surge una memoria llamada Documento de Especificación de Requerimientos
(Specification Requirement Document, SRD), que contiene la lista completa de lo
qué debe hacer el sistema sin entrar en detalles internos de diseño. Es importante
señalar que en esta etapa se debe consensuar todo lo que se requiere del sistema y
será esto lo que seguirá en las siguientes etapas, no pudiéndose introducir nuevos
requerimientos a mitad del proceso de elaboración del software.
2 Diseño del Sistema: Se descompone y organiza el sistema en elementos que puedan
elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como
resultado surge el DAS (Documento de Arquitectura del Software), que contiene la
descripción de la estructura relacional global del sistema y la especificación de lo que
debe hacer cada una de sus partes, así como la manera en que se combinan unas con
otras.
27
Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño
detallado. El primero de ellos tiene como objetivo definir la estructura de la solución
(una vez que la fase de análisis ha descrito el problema) identificando grandes
módulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello
se define la arquitectura de la solución elegida. El segundo define los algoritmos
empleados y la organización del código para comenzar la implementación.
3 Codificación: Es la fase en donde se implementa el código fuente, haciendo uso de
prototipos así como de pruebas y ensayos para corregir errores. Dependiendo del
lenguaje de programación y su versión, se crean las bibliotecas y componentes
reutilizables dentro del mismo proyecto para hacer que la programación sea un
proceso mucho más rápido.
4 Pruebas: Los elementos, ya programados, se ensamblan para componer el sistema
y se comprueba que éste funciona correctamente y que cumple con los requisitos,
antes de ser entregado al usuario final.
5 Verificación: Es la fase en donde el usuario final ejecuta el sistema. Previamente el
o los programadores han realizado pruebas exhaustivas para comprobar que el
sistema no falle.
6 Implantación: El objetivo de esta fase es la puesta en servicio del sistema
desarrollado y conseguir su adaptación final por parte de los usuarios del mismo.
4.2 Fases contempladas en la pasantía
En este desarrollo del proyecto se tiene estipulado realizar el desarrollo hasta la
fase de codificación. Las fases de prueba, verificación e implantación (puesta en
producción) quedarán a cargo del departamento de sistema de SUMINDU, S.A.
28
4.3 Variantes del Modelo
Existen variantes de este modelo; especialmente destacamos la que hace uso de
prototipos y en la que se establece un ciclo antes de llegar a la fase de
mantenimiento, verificando que el sistema final esté libre de fallos.
Este punto da un carácter más flexible a la metodología, la cual tiene un carácter
restrictivo a la hora del desarrollo del proyecto. Se acopla a la metodología de la
empresa tratando de dar mejoras para sacar un mejor provecho en el desarrollo.
CAPÍTULO 5
DESARROLLO DE LA SOLUCIÓN
Este capítulo describe el proceso de desarrollo del sistema objeto del proyecto de
pasantía. Se detalla por cada fase las actividades realizadas y los artefactos
producidos.
Los resultados y los avances que se obtuvieron en el transcurso del proyecto se
presentan a continuación. Éstos se muestran y analizan con base en la metodología
elegida para el desarrollo del sistema, Cascada. Cabe destacar que el desarrollo de la
solución llega hasta la fase de codificación como se planteó anteriormente en el
alcance del proyecto. En esa etapa no se realizaron pruebas como las de carga,
desempeño o de estrés, que normalmente se suelen hacer. La empresa SUMINDU,
S.A. está introduciendo el sistema ERP Compiere dentro de sus instalaciones.
Compiere fue la plataforma elegida para desarrollar el proyecto, que consiste en la
adición de un módulo nuevo llamado Compras Internacionales. Al tener que trabajar
con Compiere, se evitó la elección de la plataforma, del lenguaje de programación y
del manejador de base de datos; estas condiciones conforman las principales
restricciones del diseño. Por otro lado, el sistema facilitó la elaboración de las
pantallas, ya que cuenta con un modelo de interfaz basado en la estructura de los
datos, el cual permite construir las mismas de manera automática. Todo el apoyo y
soporte que se necesitó, acerca de cómo trabajar con el ERP Compiere, se obtuvo de
una de las personas especializadas en dicha herramienta que trabaja como consultor
en el departamento de Sistemas.
30
5.1 Fase Análisis de Requerimientos
Los requerimientos son la base del desarrollo del módulo, ya que todo el trabajo
que viene en las fases de diseño y codificación se guía por ellos. Es importante que
éstos queden muy claros, porque así se logra alcanzar un nivel más alto de
satisfacción por parte del cliente a la hora de entregar el sistema. Esta fase
comprendió el entendimiento de la actividad del negocio que se quiere automatizar y
se levantaron los requerimientos del módulo que se desea implementar en la
empresa. Para esto se realizaron una serie de tareas de las cuales resultaron una
serie de documentos, donde se plasman las necesidades de los clientes y los
requisitos del sistema a implementar.
A fin de poder recopilar la información necesaria para completar los
requerimientos, fue necesario realizar una serie de reuniones con los responsables
del departamento para entender cuáles eran las necesidades de éste. En las
reuniones se hicieron las siguientes actividades:
-Se hizo una introducción acerca del proceso que se quiere automatizar dentro
de la empresa, que es el de compras internacionales.
-Se dio una inducción acerca de los conceptos que se manejan en el mismo,
tales como, solicitud de orden de compra internacional, orden de compra, proveedor,
producto, línea de la orden, flete entre otros,
-Se identificaron los departamentos involucrados en dicho proceso (Compras
Internacionales, Obligaciones, Contaduría, Gerencia General), estos departamentos
son los clientes del sistema que se desarrolló.
-Se aclaró cómo se lleva a cabo el proceso de elaboración de una Orden de
Compra. La Orden de Compra consiste en rellenar una hoja Excel, donde se va a
organizar la información que se va a imprimir en la Orden de Compra.
-Se logró visualizar los beneficios para el negocio que traerá desarrollar el
módulo de compras internacionales con el sistema ERP Compiere. Además se pudo
tener una vista macro de lo que será la implantación de Compiere en resto de los
31
departamentos de la empresa y cómo será la comunicación entre los distintos
módulos del sistema.
Otro aspecto muy importante es el nivel de actualización al que nos lleva la
implantación de dicho sistema, usando un lenguaje de programación de vanguardia
como lo es Java, y poniéndonos a la altura de aquellas compañías que tienen en
funcionamiento dichos sistemas de planificación de recursos dentro de sus
instalaciones. La automatización del proceso de Compras Internacionales va a
permitir aumentar la productividad de la empresa y el posicionamiento de la misma
en el mercado de ventas.
La identificación del problema se hizo sencilla luego de la primera reunión que se
hizo con el usuario del departamento de compras internacionales. La forma manual
de llevar el proceso de la Compra Internacional ocasiona retrasos a la hora de querer
publicar o hacer una consulta
de un problema, ya que tiene que hacerse
manualmente. La comunicación de la plantilla de Excel se hace por medio de correo
electrónico, lo que trae como consecuencia que los correos puede que no lleguen o
lleguen con errores, así se tiene que esperar a que uno de los modificadores vuelva a
mandar la hoja. Existe una falta de control de versiones; esto es muy grave, ya que
como la comunicación se hace por medio de correo electrónico, esto hace que un
usuario pueda tener varias versiones del documento. Esto conlleva a que un usuario
pueda estar trabajando sobre una versión vieja y la mande de nuevo como la más
actual, ignorando los cambios que haya hecho otro trabajador.
Todos estos problemas originan un desperdicio de horas hombre, debido al tiempo
que hay que invertir en correcciones del documento y en el reenvío por correo
electrónico. Por lo tanto, se termina afectando la productividad de la compañía y la
colaboración entre los departamentos de la misma, ya que todas las complicaciones
pueden causar conflictos a la hora de trabajar como equipo. En la búsqueda de la
solución a estos problemas, se pensó en un producto que automatice el proceso de
32
Compras Internacionales en BECOBLOHM, de una manera rápida y eficiente.
Además se quiere que el sistema permita organizar y llevar un mejor control de las
tareas que se llevan a cabo durante el ciclo de vida de dicha actividad.
Una vez definidas las prestaciones que va a ofrecer el producto, se llegó a la
conclusión de cuáles serían los requerimientos del sistema y quiénes serían sus
usuarios. En la Tabla 5.1.1 se presenta un resumen de los usuarios, como los roles
que estos desempeñan en la aplicación.
Actor
Tabla 5.1.1 Usuarios del Sistema. Fuente: Elaboración propia
Descripción
Responsabilidades
Empleado
del
Departamento
Se encarga de realizar las
actividades
referidas
a
las
importaciones requeridas por la
empresa
Encargado
del
Departamento
Se encarga de supervisar las
actividades realizadas por los
empleados del departamento.
Administrador
del Sistema
Forma parte del equipo de
desarrollo del sistema, o personal
de mantenimiento y soporte
adiestrado para dar soporte
Compiere.
Tiene como responsabilidades la puesta de
solicitud
de importaciones, órdenes de
compra y el seguimiento de la mercancía.
Debe poder decir el estado de una
importación realizada por la empresa.
Tiene las mismas responsabilidades que los
empleados, más la responsabilidad de
manejar los productos y su creación,
modificación y eliminación. Esto con el fin
de que haya consistencia en los productos y
no hayan duplicados o faltantes.
Dar
soporte
a
la
usuarios
del
Departamento con el manejo de sus
cuentas de usuario, perfiles y roles. A su
vez otorgan los premisos al usuario
dependiendo
de
su
grado
de
responsabilidad
en
Empleado
de
Departamento
o
Encargado
de
Departamento
Una vez que se realizó la última reunión con los usuarios, se empezó con la
redacción de los requerimientos del sistema. Entre estos se encuentran los
requerimientos funcionales y los requerimientos no funcionales.
5.1.1 Requerimientos funcionales
La mayoría de los requerimientos propios del sistema o módulo estaban definidos
previamente en la orden de compra, sólo fue necesario separarlos y extraerlos de la
información que se presentaba en dicho documento. Completado el trabajo anterior
33
resultaron un conjunto de requerimientos del módulo de Compras Internacionales
que se nombran a continuación en la Tabla 5.1.1.1:
ID
R1
Tabla 5.1.1.1 Lista de Requerimientos Funcionales. Fuente: Elaboración propia.
Nombre
ID
Nombre
Entrar
al
Módulo
de
Compras
R16 Crear Producto
Internacionales
R2
Salir
del
Módulo
de
Compras
R17
Importar Productos
Internacionales
R3
Crear Proveedor
R18
Editar Producto
R4
Importar Proveedores
R19
Eliminar Producto
R5
Editar Proveedor
R20
Consultar Producto
R6
Consultar Proveedor
R21
Registrar Solicitud de Importación
R7
Eliminar Proveedor
R22
Imprimir Solicitud de Importación
R8
Crear Usuario
R23
Agregar
Producto
a
la
Solicitud
de
Importación
R9
Editar Usuario
R24
Registrar Orden de Compra Internacional
R10
Consultar Usuario
R25
Imprimir Orden de Compra Internacional
R11
Eliminar Usuario
R26
Agregar Producto a la Orden de Compra
Internacional
R12
Crear Perfil de Usuario
R27
Registrar Factura Comercial
R13
Editar Perfil de Usuario
R28
Imprimir Factura Comercial
R14
Eliminar Perfil de Usuario
R29
Registrar Seguimiento de Mercancía
R15
Editar Contraseña
R30
Registrar Requerimientos de Importación
A continuación, en la Tabla 5.1.1.2, se ejemplifica la especificación de uno de los
requerimientos. Para obtener el detalle del resto de los requerimientos puede
consultar el APÉNDICE A – Lista de Requerimientos.
34
Tabla 5.1.1.2 Detalle de Requerimiento R4. Fuente: Elaboración propia
R4
Importar Proveedores
Se requiere realizar la carga al sistema del maestro de
proveedores que maneja el Departamento de Compras
Internacionales
Tipo:
Funcional
Detalles y Restricciones:
Esta acción sólo puede ser realizada por personal
autorizado del departamento.
Versión:
1.1
Condición:
Debe (Obligatorio)
Número:
Nombre:
Descripción:
5.1.2 Requerimientos no funcionales
A la hora de desarrollar un sistema siempre se tiene que cumplir con ciertos
requisitos de desempeño y de entorno, entre otros. Ninguno de estos tiene que ver
con la funcionalidad que ofrece el software. Para el módulo de Compras
Internacionales se consideró la necesidad de que el sistema contara con ciertas
características, que faciliten el trabajo del usuario con la aplicación, tales como:
concurrencia. El sistema debe tener la capacidad de soportar concurrencia de
usuarios, es decir, al momento trabajar en una orden de compra puede haber más de
un usuario modificando la misma orden sin ningún problema. Este requerimiento se
encuentra cubierto por el sistema manejador de base de datos Oracle, el cual
garantiza concurrencia.
Los nuevos desarrollos de módulos o de mejoras a los ya existentes, que se tengan
que codificar adicionales a la plataforma de Compiere, tienen que realizarse en el
lenguaje Java. Las pantallas propias de la empresa, las validaciones de las pantallas
de Compiere, los procesos y tareas que haya que crear deben ser codificados en dicho
lenguaje.
Un requisito muy importante es la presentación de la interfaz del sistema. Tiene
que ser sencilla y auto explicativa. Se recomienda no sobrecargar una ventana del
sistema con más pestañas de las que trae por defecto Compiere. Si fueran necesarias
esas pestañas, lo más apropiado sería buscar alternativas para presentar la interfaz
35
para que siga manteniendo su sencillez. De esta manera se logra que el usuario
acepte de buena forma el módulo de Compras Internacionales y la introducción
definitiva del ERP Compiere a su ambiente de trabajo.
5.1.3 Identificación de Casos de Uso
Los casos de uso más relevantes nacieron a partir de los requerimientos del
sistema. La lista de los Casos de Uso (CU) contiene la idea de todas las facilidades
que va a prestar el software que se va a desarrollar durante las fases diseño y
codificación. En la Tabla 5.1.3.1 se presentan los casos de uso desarrollados en el
sistema.
Tabla 5.1.3.1 Casos de Uso y Actores. Fuente: Elaboración propia
Actor
Requerimiento
Funcional Asociado
Entrar al Sistema
Empleado del Departamento / R1
Encargado del Departamento
Salir del Sistema
Empleado del Departamento / R2
Encargado del Departamento
Gestionar Proveedor
Empleado del Departamento /
Encargado del Departamento
Agregar Proveedor
Empleado del Departamento / R3
Encargado del Departamento
Importar Proveedor
Empleado del Departamento / R4
Encargado del Departamento
Modificar Proveedor
Empleado del Departamento / R5
Encargado del Departamento
Consultar Proveedor
Empleado del Departamento / R6
Encargado del Departamento
Eliminar Proveedor
Empleado del Departamento / R7
Encargado del Departamento
Gestionar Usuario
Administrador del Sistema
Crear Usuario
Administrador del Sistema
R8
Modificar Usuario
Administrador del Sistema
R9
Consultar Usuario
Administrador del Sistema
R10
Eliminar Usuario
Administrador del Sistema
R11
Crear Perfil de Usuario
Administrador del Sistema
R12
Modificar Perfil de Usuario
Administrador del Sistema
R13
Eliminar Perfil de Usuario
Administrador del Sistema
R14
Modificar Contraseña
Empleado del Departamento / R15
Encargado del Departamento
Gestionar Producto
Encargado del Departamento
Agregar Producto
Encargado del Departamento
R16
Importar Producto
Encargado del Departamento
R17
Caso de Uso
36
Modificar Producto
Eliminar Producto
Consultar Producto
Gestionar Importación
Generar Solicitud de Importación
Imprimir Solicitud de Importación
Agregar Producto a Solicitud de
Importación
Generar
Orden
de
Compra
Internacional
Imprimir
Orden
de
Compra
Internacional
Agregar Producto a la Orden de
Compra Internacional
Gestionar Factura Comercial
Registrar Factura Comercial
Imprimir Factura Comercial
Registrar
Importación
Registrar
Importación
Seguimiento
de
Requerimientos
de
Encargado del Departamento
Empleado del Departamento
Empleado del Departamento
Encargado del Departamento
Empleado del Departamento
Encargado del Departamento
Empleado del Departamento
Encargado del Departamento
Empleado del Departamento
Encargado del Departamento
Empleado del Departamento
Encargado del Departamento
Empleado del Departamento
Encargado del Departamento
Empleado del Departamento
Encargado del Departamento
Empleado del Departamento
Encargado del Departamento
Empleado del Departamento
Encargado del Departamento
Empleado del Departamento
Encargado del Departamento
Empleado del Departamento
Encargado del Departamento
Empleado del Departamento
Encargado del Departamento
Empleado del Departamento
Encargado del Departamento
R18
R19
/ R20
/
/ R21
/ R22
/ R23
/ R24
/ R25
/ R26
/
/ R27
/ R28
/ R29
/ R30
El modelo de casos de uso del módulo de Compras Internacionales se concluyó,
contando con la aprobación del coordinador del proyecto. Cada uno de los casos de
uso que se identificaron en la fase de análisis de requerimientos fue desarrollado con
más profundidad, para así poder determinar cuáles eran los casos que se extendían
de ellos. Se identificaron todos los actores y cuáles son los casos de uso sobre los que
van a interactuar. El conteo final de casos de uso resultó ser de 35 Casos de Uso. El
modelo de CU se puede observar en la Figura 5.1.3.1
37
Figura 5.1.3.1 Diagrama de Casos de Uso. Fuente: Elaboración propia
38
En la Tabla 5.1.3.2 se muestra el detalle de uno de los Casos de Uso. Para obtener
el detalle del resto de los Casos de Uso puede consultar el APÉNDICE B –
Documento de Casos de Uso.
Tabla 5.1.3.2 Narrativa de Caso de Uso (Entrar al Sistema). Fuente: (Elaboración propia)
Caso de uso: Entrar al Sistema
Descripción: Este caso de uso permite al usuario del sistema iniciar sesión para trabajar en el
módulo.
Requerimiento Asociado: R1
Precondición:
Debe estar registrado.
FLUJO BASICO:
ACTOR
1. El usuario selecciona la opción de <Entrar al
sistema>
3. El usuario introduce su nombre de usuario y
contraseña.
SISTEMA
2. El sistema muestra la ventana solicitando
usuario y contraseña.
4. El sistema verifica y autentifica el nombre de
usuario y contraseña con la base de datos.
5. El usuario entra de forma exitosa al sistema.
FLUJOS ALTERNOS:
ACTOR
Flujo 1
Flujo 2
SISTEMA
4a. El sistema puede señalar que el nombre de
usuario no se encuentra en la base de datos y se
cancela la operación.
4b. Retornar al punto 3.
4a. El sistema autentica el nombre de usuario
pero la clave no concuerda con éste, entonces el
sistema cancela la operación.
4b. Retornar al punto 3.
Postcondición:
El usuario entra de manera exitosa al sistema y se cargan todos los permisos que tiene asignado.
Frecuencia:
Muy Frecuente
El modelo de Casos de Uso estableció las funcionalidades que tiene la aplicación de
Compras Internacionales implementada en Compiere. Cabe destacar que en el
39
APÉNDICE B – Documento de Casos de Uso, se especifica la descripción,
precondiciones y postcondiciones de cada uno de ellos. En dicho artefacto se explican
los flujos exitosos para los CU y cuáles son las vías alternas que pueden tomar.
También se habla acerca de las restricciones y aspectos que se deben tomar en
cuenta para que la ejecución se produzca de manera óptima. Toda esta información
que posee cada CU especificó con más detalle la función que desempeña en el
módulo de Compras Internacionales. Así se codificó de una manera más ágil en la
fase de codificación.
5.2 Fase Diseño del Sistema
Durante esta fase se establecieron las bases del sistema mediante el análisis y
diseño de sus componentes. Se hizo un bosquejo inicial de la arquitectura del
software y posteriormente se presentó el conjunto de diseños al usuario para así
recibir observaciones que ayudasen a mejorar el mismo. Lo que se hizo a lo largo de
la fase del Diseño del Sistema, fue perfeccionar o refinar todas las estructuras de los
diagramas que se habían bosquejado inicialmente. Además, se realizó el Modelo
Conceptual y los Diagramas de Secuencia.
El sistema está constituido por tres componentes o vistas:

Vista Lógica: Usa como herramienta de lenguaje visual el Diagrama de
Clases, donde se describen los elementos del dominio, en el caso del módulo,
qué usuarios han creado las Órdenes de Compra y a qué proveedores se les ha
hecho las compras, entre otros.

Vista de Implementación: Más orientada hacia el desarrollo que a la
comprensión del sistema en sí, muestra las relaciones entre los archivos y
demás elementos de software a través del diagrama de componentes.
40

Vista de Casos de Uso: Presenta los escenarios posibles del sistema, muestra
las funcionalidades conjuntamente con los actores que hacen uso de éstas y,
además, ofrece una noción acerca del flujo que siguen las mismas.

Vista de Implantación: Describe los métodos de comunicación entre los entes
involucrados en el sistema. Ubica al software dentro del hardware. La
interacción consta de un cliente basado en Java instalado en la computadora
del usuario final y de una conexión de red interna con un servidor Blade IBM,
donde se encuentra la base de datos Oracle que contiene tanto los
proveedores, productos y registros de importación, como las transacciones
hechas en el sistema y el usuario que las realizó. La conexión entre el sistema
y la base de datos se realiza con JDBC, que es un API para Java cuyo fin es
permitir el acceso a bases de datos relacionales.
Aunque no se planeó tener una aplicación con funcionalidad parcial, se elaboró un
prototipo de la interfaz. Este es interesante porque el prototipo no fue producido
desde cero, sino que el ERP Compiere, en conjunto con su motor transaccional,
facilitó la construcción de las pantallas del sistema. Esta ventaja se debe a que el
modelo de interfaz que posee Compiere está basado en el modelaje de los datos. Para
tener más detalles de la Interfaz de Compiere, puede consultar el APÉNDICE C –
Modelo de Interfaz.
Para que se puedan tener datos en una ventana del sistema se requiere que exista
una tabla en la base de datos asociada a esta ventana, de tal manera que esta tabla
sea la fuente que cargue los registros en la ventana. Así que para ese momento
inicial, se tenía esta funcionalidad parcial del sistema y sólo faltaba construir parte
de la lógica interna del software, es decir, la lógica del negocio que iba a mostrar la
ventana. Con funcionalidad parcial, se refiere a que se hacen acciones nativas de
Compiere que forman parte de los requerimientos levantados para el módulo, tales
41
como la creación de socios de negocio y productos, pero sin características del negocio
de la empresa que la lógica interna se encargará de darle al sistema.
5.2.1 Documento de Arquitectura de Software - DAS
El DAS es el artefacto más importante que se genera en la fase de Diseño del
Sistema. Para completar este documento se hizo el Modelo Conceptual del Sistema y
el Diagrama de Clases que muestra la interacción de las clases del Sistema; a partir
de estos últimos, se realizó el diseño de la base de datos. Este documento es
fundamental para lograr trasmitirle la información al cliente acerca del diseño del
Módulo de Compras Internacionales, y para esto se usa el lenguaje UML en los
diagramas. Para más detalle del DAS puede consultar el APÉNDICE D –
Documento de Arquitectura de Software.
5.2.2 Modelo Conceptual
A partir del diagrama de Casos de Uso se pudo diseñar el Modelo Conceptual. El
Modelo
Conceptual
permite
describir,
de
un
modo
independiente
de
la
implementación, los datos que el usuario quiere recoger en el sistema.
El objetivo fue captar toda la información del negocio que se desea representar en
el sistema. En este proceso es primordial abstraer los detalles sin importancia y
representar tan sólo aquella información que sea relevante. En este punto no nos
interesaba el cómo se iba a implementar el sistema. En esta etapa interesa recoger
la máxima cantidad de información posible con la mayor semántica posible y ser lo
más cercano al usuario.
Se usaron palabras clave para el usuario y el desarrollador, de tal manera que
ambos estuvieran de acuerdo en el problema que se quiere solucionar en un nivel
abstracto, sin muchos detalles. El modelo conceptual es el resultado del
levantamiento de los casos de uso junto con la idea del funcionamiento del negocio,
en este caso, el funcionamiento del departamento de compras internacionales.
42
Para más detalles del Modelo Conceptual puede consultar el APÉNDICE D –
Documento de Arquitectura de Software. A continuación en la Figura 5.2.2.1 se
muestra el Modelo Conceptual.
Figura 5.2.2.1 Modelo Conceptual. Fuente: Elaboración Propia.
5.2.3 Diagrama de Clases
El modelo de clases del software se diagramó a partir del problema que se quiere
solucionar, dicho problema se plasmó en el Modelo Conceptual. Para construirlo se
tuvo que conocer toda la terminología que gira en torno al proceso que se quiere
automatizar. Luego se identificaron los objetos que iban a ser relevantes para la
implementación del módulo y la relación entre ellos. Teniendo el diagrama
conceptual listo se pudo elaborar el diagrama de clases del sistema. Éste contiene
todas las clases que representan objetos en el sistema junto con sus atributos. El
Diagrama de Clases se puede observar en la Figura 5.2.3.1 que se muestra a
continuación. También se puede consultar el APÉNDICE D referente al DAS.
Figura 5.2.3.1 Diagrama de Clases. Fuente: Elaboración Propia
44
5.2.4 Diagramas de Secuencia
Los diagramas de secuencia son los diagramas que se usaron para modelar
interacción el conjunto de objetos de la aplicación a través del tiempo, se modelaron
para cada Caso de Uso. Estos diagramas son importantes porque ayudan a
determinar los objetos que son necesarios para la implementación del sistema. A
continuación se muestra un ejemplo de un Diagrama de Secuencia del Módulo.
A
continuación en la Figura 5.2.4.1 se muestra uno de los Diagramas de Secuencia.
Para mayor información acerca de los Diagramas de Secuencia puede consultar el
APÉNDICE D referente al DAS.
Figura 5.2.4.1 Diagrama de Secuencia del Caso de Uso “Agregar Proveedor”. Fuente: Elaboración
Propia.
45
5.2.5 Diagrama ER-E
El diagrama Entidad-Relación Extendido (ER-E) fue elaborado durante la Fase de
Diseño del Programa. A partir del Modelo Conceptual y del Diagrama de Clases que
resulta del mismo, se realizó el diseño de la base de datos. La versión final del
Modelo ER-E se tradujo al Modelo Relacional, siguiendo paso por paso el algoritmo
de traducción del ER-E a Relacional. El diagrama ER-E resultante de la fase de
elaboración, con atributos críticos, se puede ver en la Figura 5.2.5.1 que se muestra
a continuación. También se puede consultar el APÉNDICE D del DAS.
Figura 5.2.5.1 Diagrama ER-E. Fuente: Elaboración Propia
46
5.2.6 Prototipo inicial de la interfaz
Compiere ofrece la facilidad de poder crear la interfaz de los diferentes módulos
que se quieran agregar al sistema. Esta facilidad se debe a que el motor
transaccional, que mantiene al sistema funcionando, se encarga de interpretar el
modelo basado en la estructura de los datos que posee la interfaz de Compiere. Una
vez que los datos son consultados en la base de datos, se generan las interfaces que
se requieran para que los usuarios puedan interactuar con la aplicación.
En la fase de diseño del sistema se dedicó un tiempo a entender el funcionamiento
del modelo basado en la estructura de los datos que utiliza Compiere para configurar
y mostrar su interfaz. Se concluyó que este modelo consiste en interpretar los datos
que se almacenan en varias tablas de la base de datos de Compiere. Se diagramó el
ERE que utiliza Compiere para saber toda la información que se almacena acerca de
las ventanas, pestañas y campos que se dibujan en el monitor a la hora de cargar la
interfaz. Los datos de las ventanas, pestañas y campos se guardan en tres tablas
diferentes de manera respectiva. Todas las columnas de cada tabla representan las
propiedades de cada uno de estos componentes. Estas características pueden ser el
color de la ventana, la posición del campo en la ventana, las validaciones que se
quieran hacer sobre el campo y muchas otras.
Es necesario contar con al menos una pestaña para cada ventana, la cual va a
estar asociada con una tabla de la base de datos que almacena la información de
algún objeto del sistema. Cada una de las columnas de dicha tabla, será vista como
un campo en la pestaña de la ventana. En estos campos el usuario podrá introducir
información para crear registros de un tipo de objeto que maneja el sistema. Una vez
de que se ha llenado la información necesaria para crear una ventana nueva, el
motor transaccional tiene la capacidad de construirla y mostrarla al usuario para
que sea utilizada, por otro lado se podrá crear, modificar y eliminar registros que se
muestren en esa pantalla, ya que son funcionalidades que ofrece Compiere de forma
automática una vez que tiene la información de cómo crear la ventana. Para más
47
información acerca de la estructura de datos o diagrama ERE del modelo de interfaz
usado por Compiere, se puede consultar el APÉNDICE C - Modelo de Interfaz.
Durante la fase de Diseño del Programa se hicieron los primeros bosquejos de las
pantallas. En otras palabras, se creó la base de datos con las tablas que representan
a los objetos o clases del módulo de Compras Internacionales. Luego se asociaron
dichas tablas a las pestañas de las diferentes ventanas y se realizó la configuración
y distribución de los campos a mostrar en las pestañas. No se hizo ningún tipo de
validación sobre los campos, ni ningún tipo de lógica adicional para aplicar sobre la
ventana. Estos prototipos iniciales se le mostraron al responsable para su posterior
aprobación o corrección. Antes de empezar con la fase de codificación ya se podían
crear, modificar y eliminar registros, que es una funcionalidad que ofrece Compiere
al momento de generar las pantallas. Es por lo antes expuesto que se dice en la
sección 5.2, Diseño del Sistema, que se contaba con una funcionalidad parcial del
software.
5.3 Fase de Codificación
En esta etapa del ciclo de vida del desarrollo del software se construyó el módulo
de Compras Internacionales. Para más detalles ver el APÉNDICE E – Pantallas de
Módulo de Compras Internacionales. Durante la primera parte del desarrollo, se
codificaron los casos de uso o funcionalidades más importantes y se refinaron los
prototipos de interfaz. Luego se implementaron los demás casos de uso, se
estructuraron los reportes que genera el sistema, se realizaron pequeñas
modificaciones a las ventanas y por último se realizó el manual de usuario, que
agregamos en el APÉNDICE F – Logros Adicionales. Durante ambas partes se
hicieron pruebas unitarias de las funcionalidades que se iban agregando al módulo.
Se terminó implementando un total de 35 CU, es decir, un 100% de los CU.
Compiere cuenta con varios tipos de usuario para realizar operaciones sobre el
sistema. El usuario Super User, tiene el rol de administrar del sistema. Por otro
48
lado, se creó un usuario personalizado para cada miembro del equipo. Se le
asignaron a estos usuarios tres perfiles: Perfil Usuario, Perfil Administrador y el
Perfil System Administrator. Todas las ventanas del módulo se tuvieron que hacer
entrando con ese último perfil, ya que es el único que permite crear ventanas y
trabajar con la base de datos de una forma más directa.
En la Figura 5.3.1 se muestra la primera pestaña de la ventana Orden de Compra
Internacional, que es la que administra toda la información de una Orden de
Compra en SUMINDU, S.A.
Figura 5.3.1. Pantalla Orden de Compra Internacional. Fuente: Elaboración propia.
En la siguiente imagen, la Figura 5.3.2, se puede observar la pestaña del detalle
de la Orden. Esta pestaña maneja la información de todos los productos que están
contenidos en la Orden. La identación de esta pestaña tiene un nivel más interno
que la pestaña principal porque esta pestaña es hija de la pestaña de Orden de
49
Compra. La tabla del detalle es OrderLine y su clave primaria es el número de la
Orden de Compra.
Figura 5.3.2 Pantalla Detalles. Fuente: Elaboración propia.
Como se mencionó en el marco teórico, Compiere tiene como uno de sus principales
fuertes, el hecho de poder extender sus funcionalidades. Pero no cualquier extensión
se hace necesariamente en forma correcta, porque una extensión mal ejecutada
puede hacer que el corazón de Compiere deje de funcionar con la robustez que el
ERP garantiza.
El código fuente de Compiere consta de 23 proyectos en Java. Los desarrolladores
de Compiere crearon un proyecto llamado Extend, el cual iba a servir para que se
agreguen en este, todas las extensiones de código que se le realicen al sistema.
Cuando se hicieron las extensiones al código fuente de Compiere, se realizaron en el
proyecto Extend. De esta manera se garantizan las mejores prácticas a la hora de
50
modificar código fuente y se mantiene modelo de persistencia del sistema. Por otra
parte, esto trae el beneficio del orden, ya que todas las modificaciones que se hagan
de migrar a otras versiones sin ningún problema, ya que la base del sistema está
intacta y sólo se modifica el proyecto Extend, que funciona de extensión.
Las características de la Arquitectura Dirigida por Modelos (Model-Driven
Arquitecture, MDA) y Compiere permiten realizar muchos cambios en la interfaz de
manera rápida e intuitiva. Además, estas características brindan al desarrollador
una respuesta directa al requerimiento que quiere resolver.
El gran peso de los avances a gran escala en Compiere está en los callouts. Estas
son clases Java se crean en el proyecto Extend y sirven para brindar soluciones más
complejas que las validaciones con las que cuenta Compiere por defecto. Los callouts
se usan para hacer cálculos de una misma ventana (tabla) o incluso hacer código que
interactúe entre distintas ventanas o pestañas, es decir, entre distintas tablas de la
base de datos. Un ejemplo de este caso, se puede ver en la línea de la orden de
compra y la cabecera (Fig. 5.3.2) donde en cada línea de la orden está especificado el
peso en toneladas que representa esa cantidad de ítems. Esta característica es un
requerimiento del departamento, por lo que en la cabecera no hay algún campo
donde se pueda almacenar esta información. Para resolver este requerimiento,
hacemos el campo llamado “Total Métricas Recibidas” según el funcionamiento de
MDA que tratamos en el APÉNDICE C – Modelo de Interfaz y luego creamos un
clase Java en Extend, que llamamos MOrder y hacemos un método dentro de esta
clase, que calcule la sumatoria de las toneladas de las líneas de la orden. Esta
sumatoria de todas las toneladas de los productos de la orden, se actualiza en la
cabecera de la orden en el campo que recién creamos “Total Métricas Recibidas”.
De tal manera, este conjunto de pasos conlleva a que interactúen 2 pestañas de
una misma ventana, pero más importante aún, es reflejar la interacción que hay
entre las tablas del sistema, la arquitectura de Compiere, el proyecto Extend y el
51
código en Java que implementamos para encontrar el total de toneladas de la orden
de compra. A continuación en la Figura 5.3.3 vemos el campo Total Toneladas
Métricas, con el cálculo hecho de las toneladas de las líneas.
Figura 5.3.3 Acercamiento a campo Toneladas Métricas. Campo calculado con clase Java. Fuente:
Elaboración propia.
Se trabajó con una herramienta de reportes distinta a la nativa de Compiere
llamada Japer Reports. Con este herramienta, se realizó el diseño de lo que son
ahora los documentos de Solicitud de Importación, Solicitud de Compra Nacional,
Orden de Compra Internacional y Orden de Compra Nacional
5.3.1 Restricciones de implementación
Compiere es un ERP al cual se le puede extender su funcionalidad. Pero así como
ofrece está ventaja, se tuvo que lidiar con un conjunto de restricciones. Esto no evitó
que se implementara el módulo de Compras Internacionales, debido a que se buscó
una solución óptima y dentro de las posibilidades que posee Compiere. Estas
restricciones son las siguientes:

Las ventanas de Compiere se generan de manera estándar, todas tienen la
misma estructura y pueden que lleguen a cansar al usuario a la hora de usar
el módulo de Compras Internacionales. Compiere no ofrece libertad en cuanto
a la creatividad que puede tener el desarrollador al diseñar y crear una
interfaz. Para el sistema se usaron todos los componentes que brinda la
herramienta de construcción de interfaz, para poder satisfacer las necesidades
de los clientes de la mejor forma.
52

Las interrelaciones del diagrama ERE, que tienen cardinalidad N:N, no
pueden ser representadas como el resultado de su traducción. Como se sabe,
al aplicar el algoritmo de traducción de un modelo ER que tiene cardinalidad
N:N, se crea una tabla que contiene los atributos claves de las entidades que
interrelacionadas. Las tablas interrelacionas junto con la tabla se crea al
hacer la traducción,
no se pueden crear como una nueva ventana en
Compiere. Analizando el sistema se pudo observar que Compiere maneja las
relaciones N:N de otra forma. Las tablas que resultaron de la traducción de
las entidades que se interrelacionan, fueron colocadas en la misma ventana,
sólo que se emparentó una de las tablas a la otra. Así se lograba tener una
relación N:N. El que una tabla fuera el padre

Todas las tablas que se crean en Compiere poseen un identificador que va a
controlar el mismo motor transaccional. La clave de todas las tablas son
gestionadas por el sistema. Si más de una tabla contenía más de un campo
que era parte de la clave, se configuraba al mismo como un campo único para
evitar duplicidad de datos.

Los triggers o disparadores que suelen colocarse en la base de datos para
realizar validaciones, son trabajados en un nivel superior por Compiere.
Todos estos son codificados en clases de Java cuyos ejecutables son puestos en
marcha por el motor transaccional. Se ve como una forma más eficiente de
realizar validaciones, ya que se evitan una mayor cantidad de accesos a la
base de datos y ejecución de código SQL.
En la primera parte de la codificación se planificó el desarrollo de los casos de uso
con la prioridad más alta. El módulo de Compras Internacionales se conforma por
dos ventanas de manera principal, una donde se va a llevar el control de la Orden de
Compra, Detalle de Línea y seguimiento de información de forma general y la otra
pantalla que gestiona todo lo referente a la Solicitud de Importación.
53
La primera pantalla que se creó fue la denominada Orden de Compra
Internacional. Está compuesta por seis pestañas. Toda la información que se
muestra en éstas se puede crear, modificar y eliminar. Estas tres funcionalidades
son implementadas de manera automática al crear la pestaña, lo que significa que
de una vez se pueden realizar dichas operaciones sobre los registros de las tablas.
Teniendo en cuenta esto a la hora de implementar, se agregaron una gran cantidad
de validaciones que se hacen en los campos con los que interactúa el usuario. Es
importante resaltar que por cada pestaña, que es lo mismo que hablar de una tabla
en base de datos, se tiene una clase Java donde se codifican los callouts de
Compiere. Estas clases fueron implementadas para poder hacer los diferentes tipos
de validaciones. También se programaron los disparadores, que se ejecutan antes y
después de guardar o eliminar un registro de una tabla. Estos disparadores se
implementan en una clase Java aparte de las que contienen los callouts. Se tiene
una clase por cada nueva tabla.
Es importante resaltar que tanto los triggers como callouts son ejecutadas de
manera dinámica. La creación de un registro no se realiza totalmente de manera
automática, porque hay ciertos callouts que se implementan para buscar
información en la base de datos antes de proceder a guardar el registro. También se
juega con la lógica de la pantalla para mostrar campos que se pueden guardar o no,
es decir, que son opcionales. De igual forma sucede al tratar de modificar la
información que se refiere a un registro. La operación de eliminar puede que no
ejecute ningún callout, pero si puede ejecutar disparadores. Por todo lo antes
expuesto se puede decir que los casos de uso que no requirieron ninguna línea de
código, son todos los que tratan de consultar los diferentes registros de las tablas.
Toda la explicación que se presentó anteriormente sobre la construcción de una
pestaña, aplica para el resto de las pestañas que se crearon durante todo el
desarrollo del proyecto, con la diferencia en que cada pestaña tendrá su propia
configuración, así como sus propios callouts y triggers.
54
5.4 Logros Adicionales
Además de los objetivos del proyecto de la pasantía, logramos avances en otras
áreas fuera del alcance de la misma debido a que el proyecto de pasantía era parte
de un proyecto macro que aún para la fecha se sigue desarrollando. Este proyecto
consta de la implementación e implantación de Compiere en todas las áreas del
negocio de SUMINDU, S.A.
Se trabajó de igual manera en el módulo de Compras Nacionales, logrando cubrir
con un aproximado del 85 % de su funcionalidad beta, quedando por concretar
algunas retenciones del ámbito legal venezolano, como el I.V.A, I.S.L.R e impuestos
municipales.
Otro logro adicional es colocar una implantación en paralelo del módulo, de tal
manera que los miembros del departamento de Compras Internacionales, estén
trabajando con las dos versiones, así cuando se implante el nuevo sistema, el
impacto sea menor. Asimismo, se está en contacto con los usuarios del departamento
para responder a sus inquietudes y recibir sugerencias que podrían tomarse para
mejorar el módulo. Esta implantación paralela se mantiene al día con respecto a lo
que se está desarrollando actualmente, para que así siempre tengan la versión más
reciente.
Adicionalmente ya se empezó el desarrollo del módulo de Ventas. De momento
sigue activo el sistema paralelo de Compras Internacionales para que el pase a
producción, que se espera que sea dentro de los próximos 5 meses aproximadamente.
En el APÉNDICE F – Logros Adicionales, puede consultar los manuales de
usuario para los miembros del departamento y el uso de esta implantación paralela,
así como imágenes de las ventanas del módulo de Compras Nacionales.
CAPÍTULO 6
CONCLUSIONES Y RECOMENDACIONES
Una vez que se ha culminado el proceso de desarrollo del proyecto de pasantía, se
llega a las siguientes conclusiones:

El módulo de Compras Internacionales que se desarrolló en el ERP Compiere
de la empresa SUMINDU, S.A., automatizó el proceso de elaboración de las
compras internacionales, las cuales venían realizándose de forma manual.
También permite hacer el análisis del desempeño de los productos en cada
categoría y llevar una correcta traza de un producto, familia de productos,
órdenes, etc.

Se
logró
implementar
todos
los
requerimientos
del
cliente.
Estos
requerimientos cumplieron con las funcionalidades del software, ya que el
usuario y el responsable técnico (coordinador del proyecto) quedaron
satisfechos con la solución que se construyó. Aparte de los requerimientos que
se plantearon en la fase de implementación, fueron desarrolladas otras
funcionalidades adicionales que contribuyeron en la obtención de una solución
óptima. Esto debido a que Compiere además de ser un sistema para gestión
de empresas, es una herramienta que permite extender las funcionalidades
del software fácilmente.

El desarrollo se llevó a cabo hasta la fase de codificación de manera exitosa.
Tal y como se definió en el alcance del proyecto, se realizó una primera etapa
de levantamiento de información, luego la etapa de diseño de la
56
solución de problemas, seguido por la codificación, cumpliendo con la
metodología establecida para el desarrollo. Al final se cumplió con la entrega
de un producto 100 % funcional, pero no se hizo el paso a producción del
módulo,
que
queda
pendiente
para
un
futuro
mientras
se
siguen
desarrollando los otros módulos.

El desarrollo del módulo de Compras Internacionales representa un avance en
cuanto a la introducción del ERP Compiere en la empresa. Esto representa
una evolución tecnológica para el departamento de Sistemas y la compañía en
general, debido a que dicho software coloca a SUMINDU, S.A. en un nivel
empresarial más competitivo. La organización y control que ofrece el tener un
sistema de planificación de recursos, va a ayudar a automatizar los procesos
que se llevan a cabo en la empresa y que haya una mejor integración entre
ellos. Todo esto influye en el aumento de la productividad de los trabajadores,
así como en la colaboración entre las distintas áreas de la compañía. También
se fortalece la relación con los clientes en cuanto a la oferta de productos y
servicios.

La posibilidad de poder incluir el módulo de Compras Internacionales al ERP
Compiere, se debe a la característica “Open Source”, código abierto, del
mismo. Esta ventaja permitió ampliar las funcionalidades del sistema y
adaptarlo al entorno del negocio de SUMINDU, S.A.

El módulo de Compras Internacionales
va a poder implantarse en otras
empresas del consorcio BECOBLOHM luego de que haya pasado por las
pruebas comerciales y haya sido puesto en producción en las instalaciones de
SUMINDU, S.A. Recordemos que la empresa SUMINDU, S.A., en conjunto
con otras empresas, forman parte de la organización BECOBLOHM. La idea
de colaboración entre estas empresas es que los nuevos desarrollos
tecnológicos puedan ser compartidos. Si otra empresa desea implantar el
módulo, puede utilizar el que se desarrolló en éste proyecto e instalarlo, y a la
vez podría modificarlo sin ningún problema, previo acuerdo de las gerencias.
57

Finalmente se puede decir que se cumplieron los objetivos de este proyecto de
pasantía larga. Tanto el objetivo general, como los objetivos específicos que se
plantearon desde el principio.
Para asegurar que los resultados del proyecto de pasantía van a perdurar en el
futuro, es vital que el cliente (responsable comercial), el departamento de Sistemas y
los usuarios del software, tomen en cuenta las siguientes recomendaciones:

La recomendación más importante es terminar con el proyecto macro de
SUMINDU, S.A. Esto comprende la realización de la fase de implantación; es
decir, poner el módulo en producción. Luego se tienen que llevar a cabo las
pruebas comerciales durante un período de tres meses aproximadamente,
para analizar el desempeño de los usuarios utilizando el módulo de Compras
Internacionales. Estos presentan la retroalimentación respectiva para
implementar los ajustes finales y dejar de manera permanente
dicha
aplicación.

Como el sistema ERP Compiere no es tan ampliamente conocido, se debería
realizar un curso para que los usuarios conozcan la herramienta de trabajo,
cuáles son las ventajas que ofrece su uso y un curso técnico acerca del manejo
del software. Todo esto debería aplicarse a todas las gerencias, ya que a largo
plazo se planea sustituir todos los sistemas de SUMINDU, S.A. por Compiere.
Esta inducción debería realizarse antes de la del módulo de Compras
Internacionales, y así facilitar el entendimiento de los nuevos desarrollos a los
usuarios. Adicionalmente, se tiene que realizar una inducción a todos los
usuarios del sistema. En ésta se explicaran las funcionalidades de cada
ventana del módulo y de cómo interactuar con ella. Se les tiene que entregar a
los usuarios el manual del sistema, para que en caso de dudas a la hora de
usar el sistema tengan donde buscar la solución. Por otro lado, se tiene que
dar una inducción más profunda a la sección de soporte de la gerencia de
58
Sistemas, que van a ser los encargados de solventar los problemas y dudas
que se les presenten a los usuarios.

La herramienta que se encarga de generar reportes en Compiere carece de
ciertas funcionalidades que tienen otras a la hora de hacer reportes complejos.
Por esto se recomienda al departamento de Sistemas que busque una
herramienta más robusta para la creación de reportes, y que sea fácilmente
integrable. En Compiere se puede configurar un formato aparte del estándar,
pero lleva mucho más tiempo hacerlo que el de utilizar una herramienta
adicional. En este particular se recomienda usar la herramienta Jasper
Report, que brinda flexibilidad y muchas opciones para crear reportes
eficientes y útiles para la gerencia.

A pesar que a veces es difícil, otra recomendación importante es trabajar más
en comunicación con el usuario final en la empresa. Esto permite que el
usuario se sienta más identificado con el trabajo de desarrollo que se está
haciendo para su labor diaria y además ayuda a que la labor del desarrollador
sea más precisa. Una reunión de 2 horas semanal con el encargado del
departamento, me parece un buen punto de partida.

Se le recomienda a los usuarios del módulo de Compras Internacionales y
demás módulos de Compiere que emitan opiniones y nuevas ideas que sirvan
como retroalimentación al departamento de Sistemas, para que se lleven a
cabo las mejoras de la aplicación. Así se benefician ambas partes y se impulsa
el incremento de la productividad de la empresa.
59
REFERENCIAS
[1] La empresa: Inicio. Disponible
Consultado el 16 de agosto de 2011.
en:
http://www.sumindu.com/index.jsp
[2] La empresa: Inicio. Disponible en: http://www.sumindu.com/jsp/historia.jsp .
Consultado el 16 de agosto de 2011.
[3] La empresa: Visión. Disponible en: http://www.sumindu.com/vision.jsp .
Consultado el 16 de agosto de 2011.
[4] La empresa: Visión. Disponible en: http://www.sumindu.com/vision.jsp .
Consultado el 16 de agosto de 2011.
[5] La empresa: Servicios. Disponible en: http://www.sumindu.com/servicios.jsp
Consultado el 16 de agosto de 2011.
.
[6] Reuther, D., y Chattopadhyay, G. (2004). Critical factors for enterprise resources
planning system selection and implementation projects within small to medium
enterprises. 851-855
[7] Alvarado, J. Cimatic de México. México. 2009. Sistemas ERP (Enterprise
resource planning). Disponible en Internet: http://www.i-newswire.com/sistemaserp-enterprise-resource/3563 , consultado el 27 de diciembre de 2011.
[8] Kumar, K. y Hillegersberg, J. (2000). Enterprise resource planning: Introduction.
Communications of the ACM, 43(4), 22-26.
60
[9] Maldonado, Miguel. 2008. El impacto de los factores críticos de éxito en la
implementación de sistemas integrados de ERP. Cuadernos de difusión España y
Perú. Disponible en Internet:
http://web.ebscohost.com/ehost/pdfviewer/pdfviewer?sid=dd467592-3e8c-4197-965b4ab4ada96c1c%40sessionmgr14&vid=2&hid=19 , consultado el 27 de diciembre de
2011.
[10] Esteves, J y Bohorquez, V. 2007. El impacto de la cultura nacional en la
implantación de sistemas ERP. Revista de Empresa. Disponible en Internet:
http://web.ebscohost.com/ehost/pdfviewer/pdfviewer?sid=117a1cc3-089f-4e5f-962b94e991c02b5e%40sessionmgr112&vid=2&hid=126, consultado el 27 de diciembre de
2011.
[11] ERP Sistema de Gestión. Disponible en Internet:
http://www.adpime.com/ERP/Es_ERP_intro.htm, consultado el 27 de diciembre de
2011.
[12] Torricella, R y otros. 2008. Acceso abierto y software libre: premisas para la
independencia tecnológica. ACIMED. La Habana. Disponible en Internet:
http://web.ebscohost.com/ehost/pdfviewer/pdfviewer?sid=b21c4493-ea74-4c73-813d05f6e10b723c%40sessionmgr11&vid=2&hid=8, consultado el 27 de diciembre de
2011.
[13] Rodríguez, G. 2008. El software libre y sus implicaciones jurídicas. Revista de
Derecho. Barranquilla. Disponible en Internet:
http://web.ebscohost.com/ehost/pdfviewer/pdfviewer?sid=cd7a60e9-71ff-48a4-974df8391ee85883%40sessionmgr15&vid=2&hid=8, consultado el 27 de diciembre de
2011.
[14] Moreno, L. 2010. Antecedentes y aspectos generales de las licencias de Creative
Commons. Revista de Derecho Comunicaciones y Nuevas Tecnologías. Disponible en
Internet:
http://web.ebscohost.com/ehost/pdfviewer/pdfviewer?sid=daa8823a-59f04006-8774-152d5b5df6d7%40sessionmgr12&vid=2&hid=24, consultado el 27 de
diciembre de 2011.
[15] Compiere, Inc. 2010. Compiere Products Licenses. Estados Unidos. Disponible
en Internet:
http://www.compiere.com/products/compare-editions/index.php,
consultado el 27 de diciembre de 2011.
61
[16] Campbell, M y García, D. 2010. The Move to the Middle: Convergence of the
Open-Source and Proprietary Software Industries. International Journal of the
Economics of Business. Vol. 17, No. 2, July 2010, pp. 223–252. Chicago. Disponible
en Internet:
http://web.ebscohost.com/ehost/pdfviewer/pdfviewer?sid=140315ca62f3-41d6-bfb8-b8e068353748%40sessionmgr104&vid=2&hid=104, consultado el 27
de diciembre de 2011.
[17] Compiere, Inc. 2010. Compiere History. Estados Unidos. Disponible en Internet:
http://www.compiere.com/company/history.php, consultado el 28 de diciembre de
2011.
[18] Compiere, Inc. 2010. Compiere Capabilities. Estados Unidos. Disponible en
Internet: http://www.compiere.com/products/capabilities/index.php, consultado el
28 de diciembre de 2011.
[19] Quintero, J. B. y Anaya, R. Colombia. 2007. MDA y el papel de los modelos en
el proceso de desarrollo de software. Revista EIA 8: 131-146. Disponible en Internet:
http://web.ebscohost.com/ehost/pdfviewer/pdfviewer?sid=3b44633f-2529-4f5e-a69e2eb70e4fa71f%40sessionmgr11&vid=65&hid=19, consultado el 28 de diciembre de
2011.
[20] Compiere, Inc. 2010. Compiere Model Driven. Estados Unidos. Disponible en
Internet:
http://www.compiere.com/products/platform/model-drivenarchitecture.php, consultado el 28 de diciembre de 2011.
[22] Compiere, Inc. 2010. Compiere Platform. Estados Unidos. Disponible en
Internet: http://www.compiere.com/products/platform/index.php, consultado el 28 de
diciembre de 2011.
[22] Compiere, Inc. 2008. Compare Editions. Estados Unidos. Disponible en
Internet: http://www.compiere.com/products/compare-editions/index.php, consultado
el 28 de diciembre de 2011.
[23] Friesen, Jeff. 2011. Object-oriented language basics, Part 1. Disponible en
Internet:
http://www.javaworld.com/javaworld/jw-04-2001/jw-0406-java101.html,
consultado el 28 de diciembre de 2011.
62
[24] Oracle Corporation. 2010. Oracle Database 10g Express Edition. Disponible en
Internet:
http://www.oracle.com/technetwork/database/expressedition/overview/index.html, consultado el 28 de diciembre de 2011.
[25] Oracle Corporation. 2010. Oracle Developer. Disponible en Internet:
http://www.oracle.com/technetwork/developer-tools/sqldeveloper/overview/index.html, consultado el 28 de diciembre de 2011.
[26] The Eclipse Foundation. 2011. About the Eclipse Foundation. Disponible en
Internet: http://www.eclipse.org/org, consultado el 29 de diciembre de 2011.
[27] The Apache Software Foundation. 2011. Apache Subversion Features.
Disponible en Internet: http://subversion.apache.org/features.html, consultado
el 29 de diciembre de 2011.
[28] Centers for medicare & medicaid service. 2008. Selecting a development
approach. Disponible en Internet:
http://www.cms.gov/SystemLifecycleFramework/Downloads/SelectingDevelopmentA
pproach.pdf, consultado el 29 de diciembre de 2011.
SUMINDU, S.A
Documento de Lista de Requerimientos del
Software Para el módulo de Compras
Internacionales para el Sistema
Compiere ERP
Versión 1.2
1
Sumindu, S.A
Módulo de Compras Internacionales para el Sistema Compiere ERP
Especificaciones de Requerimientos del Software
Versión:
1.2
Fecha: 05/02/2012
Historia de Revisiones
Fecha
22/11/2011
28/12/2011
04/02/2012
Versión
1.0
1.1
1.2
Descripción
Elaboración Inicial
Correcciones documento
Correcciones documento
Autor
Jorge Duque
Jorge Duque
Jorge Duque
2
Sumindu, S.A
Módulo de Compras Internacionales para el Sistema Compiere ERP
Especificaciones de Requerimientos del Software
Versión:
1.2
Fecha: 05/02/2012
Documento de Lista de Requerimientos del Software
1. Introducción
Este documento expone los requerimientos de software para el Módulo de Compras
Internacionales para el Sistema Compiere ERP, especificando los requerimientos funcionales.
Una de las metas más importantes de este artefacto, es fundar las bases de lo que serán los
diseños de la arquitectura del sistema y la implementación del mismo. Este es el documento
será el punto de guía para el desarrollo del sistema.
1.1 Alcance
Esta lista de requerimientos tiene el objetivo de trascender a lo largo de todo el desarrollo del
proyecto, ya que es la base de todo. Lo que diga este documento tiene que estar presente
durante la transición de cada fase del desarrollo del software, hasta que se llega a la fase de
pruebas de aceptación donde el cliente utiliza el presente documento para rectificar que se
cumplieron con todos los requisitos y funcionalidades solicitadas.
1.2 Definiciones, Acrónimos y Abreviaturas
Compiere: es una aplicación para negocios de tipo código abierto, ERP y CRM destinada para
las empresas de pequeño y mediano tamaño.
CRM: La administración basada en la relación con los clientes, es un modelo de gestión de
toda la organización, basada en la orientación al cliente, es decir, servicio al cliente.
ERP: Sistema de Planificación de Recursos Empresariales que integra y maneja gran parte de
los negocios asociados con la producción de una empresa.
Java: es un lenguaje de programación orientado a objetos desarrollado por Sun Microsystems.
Open Source: Código abierto
Alafletes: Agencia de aduanas perteneciente al grupo.
1.3 Referencias
Compiere
Manual de Planificación y Colocación de Órdenes de Compra y Nacionalización de Materiales
Plan de Trabajo Pasantía
1.4 Vista Previa
A continuación se mencionará la lista de requerimientos que exige tanto el cliente como el
sistema para que se logre desarrollar el módulo de Compras Internacionales de la mejor
manera. También se va a describir con más detalles las características de cada uno estos.
3
Sumindu, S.A
Módulo de Compras Internacionales para el Sistema Compiere ERP
Especificaciones de Requerimientos del Software
Versión:
1.2
Fecha: 05/02/2012
2. Lista de Requerimientos Funcionales
ID
R1
Nombre
Entrar
al
ID
Nombre
Módulo
de
Compras
R16
Crear Producto
Módulo
de
Compras
R17
Importar Productos
Internacionales
R2
Salir
del
Internacionales
R3
Crear Proveedor
R18
Editar Producto
R4
Importar Proveedores
R19
Eliminar Producto
R5
Editar Proveedor
R20
Consultar Producto
R6
Consultar Proveedor
R21
Registrar Solicitud de Importación
R7
Eliminar Proveedor
R22
Imprimir Solicitud de Importación
R8
Crear Usuario
R23
Agregar
Producto
a
la
Solicitud
de
Importación
R9
Editar Usuario
R24
Registrar Orden de Compra Internacional
R10
Consultar Usuario
R25
Imprimir Orden de Compra Internacional
R11
Eliminar Usuario
R26
Agregar Producto a la Orden de Compra
Internacional
R12
Crear Perfil de Usuario
R27
Registrar Factura Comercial
R13
Editar Perfil de Usuario
R28
Imprimir Factura Comercial
R14
Eliminar Perfil de Usuario
R29
Registrar Seguimiento de Mercancía
R15
Editar Contraseña
R30
Registrar Requerimientos de Importación
2.1 Entrar al Módulo de Compras Internacionales
Número:
R1
Nombre:
Entrar al Módulo de Compras Internacionales
Descripción:
Iniciar sesión en el sistema.
Tipo:
Funcional
Versión:
1.2
Condición:
Debe (Obligatorio)
2.2 Salir del Módulo de Compras Internacionales
Número:
R2
Nombre:
Salir del Módulo de Compras Internacionales
Descripción:
Cerrar sesión en el sistema.
Tipo:
Funcional
Versión:
1.2
Condición:
Debe (Obligatorio)
4
Sumindu, S.A
Módulo de Compras Internacionales para el Sistema Compiere ERP
Especificaciones de Requerimientos del Software
2.3 Crear Proveedor
Número:
Nombre:
Descripción:
Tipo:
Versión:
Condición:
2.4 Importar de Proveedores
Número:
Nombre:
Descripción:
Tipo:
Versión:
Condición:
2.5 Editar Proveedor
Número:
Nombre:
Descripción:
Versión:
1.2
Fecha: 05/02/2012
R3
Crear Proveedor
Creación de un nuevo proveedor de la
empresa por parte del Departamento de
Compras Internacionales.
Funcional
1.2
Debe (Obligatorio)
R4
Importar de proveedores
Se requiere realizar la carga al sistema del
maestro de proveedores que maneja el
Departamento de compras Internacionales
Funcional
1.2
Debe (Obligatorio)
Tipo:
Versión:
Condición:
R5
Editar Proveedor
Modificación de un proveedor de la empresa
por parte del Departamento de Compras
Internacionales.
Funcional
1.2
Debe (Obligatorio)
2.6 Consultar Proveedor
Número:
Nombre:
Descripción:
Tipo:
Versión:
Condición:
R6
Consultar Proveedor
Revisión de datos de un Proveedor.
Funcional
1.2
Debe (Obligatorio)
2.7 Eliminar Proveedor
Número:
Nombre:
Descripción:
Tipo:
Versión:
Condición:
R7
Eliminar Proveedor
Eliminación de un proveedor de la empresa
del sistema.
Funcional
1.2
Debe (Obligatorio)
5
Sumindu, S.A
Módulo de Compras Internacionales para el Sistema Compiere ERP
Especificaciones de Requerimientos del Software
Versión:
1.2
Fecha: 05/02/2012
2.8 Crear Usuario
Número:
Nombre:
Descripción:
Tipo:
Versión:
Condición:
R8
Crear Usuario
Creación de un nuevo usuario delsistema
Funcional
1.2
Debe (Obligatorio)
2.9 Editar Usuario
Número:
Nombre:
Descripción:
Tipo:
Versión:
Condición:
R9
Editar Usuario
Modificación de un usuario del sistema.
Funcional
1.2
Debe (Obligatorio)
2.10 Consultar Usuario
Número:
Nombre:
Descripción:
Tipo:
Versión:
Condición:
R10
Consultar Usuario
Revisión de datos de un usuario del sistema
Funcional
1.2
Debe (Obligatorio)
2.11 Eliminar Usuario
Número:
Nombre:
Descripción:
Tipo:
Detalles y Restricciones:
Versión:
Condición:
2.12 Crear Perfil de Usuario
Número:
Nombre:
Descripción:
Tipo:
Versión:
Condición:
R11
Eliminar Usuario
Creación de un nuevo proveedor de la
empresa por parte del Departamento de
Compras Internacionales
Funcional
Solo puede ser realizable esta acción por
personal autorizado del departamento.
1.2
Debe (Obligatorio)
R12
Crear Perfil de Usuario
Crea el perfil del usuario (permisología) que
se la asignará a un usuario
Funcional
1.2
Debe (Obligatorio)
6
Sumindu, S.A
Módulo de Compras Internacionales para el Sistema Compiere ERP
Especificaciones de Requerimientos del Software
Versión:
1.2
Fecha: 05/02/2012
2.13 Editar Perfil de Usuario
Número:
Nombre:
Descripción:
Tipo:
Versión:
Condición:
R13
Editar Perfil de Usuario
Modificación de un perfil de usuario
Funcional
1.2
Debe (Obligatorio)
2.14 Eliminar Perfil de Usuario
Número:
Nombre:
Descripción:
Tipo:
Versión:
Condición:
R14
Eliminar Perfil de Usuario
Eliminación de un perfil de usuario
Funcional
1.2
Debe (Obligatorio)
2.15 Editar Contraseña
Número:
Nombre:
Descripción:
Tipo:
Versión:
Condición:
2.16 Crear Producto
Número:
Nombre:
Descripción:
Tipo:
Versión:
Condición:
2.17 Importar Productos
Número:
Nombre:
Descripción:
Tipo:
Versión:
Condición:
R15
Editar Contraseña
Modificación de la actual contraseña de
ingreso al sistema.
Funcional
1.2
Debe (Obligatorio)
R16
Crear Producto
Creación de un nuevo producto de la empresa
por parte del Departamento de Compras
Internacionales
Funcional
1.2
Debe (Obligatorio)
R17
ImportarProductos
Se requiere realizar la carga al sistema del
maestro de productos que maneja el
Departamento de compras Internacionales
Funcional
1.2
Debe (Obligatorio)
7
Sumindu, S.A
Módulo de Compras Internacionales para el Sistema Compiere ERP
Especificaciones de Requerimientos del Software
Versión:
1.2
Fecha: 05/02/2012
2.18 Editar Producto
Número:
Nombre:
Descripción:
Tipo:
Versión:
Condición:
R18
Editar Producto
Modificación de un producto del sistema.
Funcional
1.2
Debe (Obligatorio)
2.19 Eliminar Producto
Número:
Nombre:
Descripción:
Tipo:
Versión:
Condición:
R19
Eliminar Producto
Eliminación de un producto del sistema.
Funcional
1.2
Debe (Obligatorio)
2.20 Consultar Producto
Número:
Nombre:
Descripción:
Tipo:
Versión:
Condición:
R20
Consultar Producto
Revisión de la información de un producto.
Funcional
1.2
Debe (Obligatorio)
2.21 Registrar Solicitud de Importación
Número:
Nombre:
Descripción:
Tipo:
Versión:
Condición:
2.22 Imprimir Solicitud de Importación
Número:
Nombre:
Descripción:
Tipo:
Detalles y Restricciones:
Versión:
Condición:
R21
Registrar Solicitud de Importación
Un usuario del sistema genera una solicitud
de importación productos para stock o para
venta directa.
Funcional
1.2
Debe (Obligatorio)
R22
Imprimir Solicitud de Importación
Creación de un nuevo proveedor de la
empresa por parte del Departamento de
Compras Internacionales
Funcional
Solo puede ser realizable esta acción por
personal autorizado del departamento.
1.2
Debe (Obligatorio)
8
Sumindu, S.A
Módulo de Compras Internacionales para el Sistema Compiere ERP
Especificaciones de Requerimientos del Software
Versión:
1.2
Fecha: 05/02/2012
2.23 Agregar Producto a la Solicitud de Importación
Número:
R23
Nombre:
Agregar Producto a la Solicitud de
Importación
Descripción:
Se agregan productos a una solicitud de
importación ya existente.
Tipo:
Funcional
Versión:
1.2
Condición:
Debe (Obligatorio)
2.24 Registrar Orden de Compra Internacional
Número:
R24
Nombre:
Registrar Orden de Compra Internacional
Descripción:
Un usuario del departamento de Compras
Internacionales crea una orden de compra
internacional. Esta orden será aprobada por la
gerencia general de la empresa. La Orden de
Compra es el documento formal para realizar
compra de mercancía en la empresa.
Tipo:
Funcional
Versión:
1.2
Condición:
Debe (Obligatorio)
2.25 Imprimir Orden de Compra Internacional
Número:
R25
Nombre:
Imprimir Orden de Compra Internacional
Descripción:
Se requiere la impresión de la orden desde el
sistema
Tipo:
Funcional
Versión:
1.2
Condición:
Debe (Obligatorio)
2.26Agregar Producto a la Orden de Compra Internacional
Número:
R26
Nombre:
Agregar Producto a la Orden de Compra
Internacional
Descripción:
Se agregan productos a unaorden de compra
ya existente.
Tipo:
Funcional
Versión:
1.2
Condición:
Debe (Obligatorio)
9
Sumindu, S.A
Módulo de Compras Internacionales para el Sistema Compiere ERP
Especificaciones de Requerimientos del Software
2.27 Registrar Factura Comercial
Número:
Nombre:
Descripción:
Tipo:
Versión:
Condición:
2.28 Imprimir Factura Comercial
Número:
Nombre:
Descripción:
Tipo:
Versión:
Condición:
2.29 Registrar seguimiento de Mercancía
Número:
Nombre:
Descripción:
Tipo:
Versión:
Condición:
Versión:
1.2
Fecha: 05/02/2012
R27
Registrar Factura Comercial
El usuario registra la factura comercial de la
importación. Factura Comercial es el nombre
dado a la factura que emite el proveedor
internacional.
Funcional
1.2
Debe (Obligatorio)
R28
Imprimir Factura Comercial
Se requiere la impresión de la orden desde el
sistema
Funcional
1.2
Debe (Obligatorio)
R29
Registrar Seguimiento de Mercancía
Se actualiza el estado de la mercancía desde
que sale del país del proveedor hasta que
llega al almacén destino de Sumindu.
Funcional
1.2
Debe (Obligatorio)
2.30 Registrar Requerimientos de Importación
Número:
R30
Nombre:
Registrar Requerimientos de Importación
Descripción:
Especifica las obligaciones que debe cumplir
la importación o exigencias que debe cumplir
la importación.
Tipo:
Funcional
Versión:
1.2
Condición:
Debe (Obligatorio)
10
Sumindu, S.A
Módulo de Compras Internacionales para el Sistema Compiere ERP
Especificaciones de Requerimientos del Software
Versión:
1.2
Fecha: 05/02/2012
3. Requerimientos No Funcionales
A la hora de desarrollar un sistema siempre se tienen que cumplir con ciertos requisitos de
desempeño, de entorno, entre otros. Ninguno de estos tiene que ver con la funcionalidad que
ofrece el software. Para el módulo de Compras Internacionales se requiere que el sistema
cuente con ciertas características que faciliten el trabajo del usuario con la aplicación. El
sistema debe tener la capacidad de soportar concurrencia de usuarios, es decir, al momento
trabajar en una orden de compra puede haber más de un usuario modificando la misma orden
sin ningún problema. Este requerimiento se encontrará cubierto por el sistema manejador de
base de datos Oracle, el cual garantiza concurrencia y a su vez consistencia de datos.
Los nuevos desarrollos de módulos o de mejoras a los ya existentes, que se tengan que
codificar adicionales a la plataforma de Compiere, tienen que realizarse en el lenguaje Java.
Las pantallas propias de la empresa, las validaciones de las pantallas de Compiere, los
procesos y tareas que haya que crear serán codificados en dicho lenguaje. Un requisito muy
importante es la presentación de la interfaz del sistema. Tiene que ser sencilla y auto
explicativa, es decir, se requiere que las ventanas que se creen para el módulo tengo una
eficiente distribución de los campos y no tengan pestañas innecesaria. De esta manera se logra
que el usuario acepte de buena forma el módulo de Compras Internacionales y la introducción
definitiva del ERP Compiere a su ambiente de trabajo
11
SUMINDU, S.A
IMPLEMENTACIÓN DEL M
MÓDULO
ÓDULO DE COMPRAS
INTERNACIONALES EN E
EL
L SISTEMA COMPIERE
ERP
Casos de Uso
Versión 1.3
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Historial de Revisiones
Fecha
Versión
18/12/2011
1.0
02/01/2012
1.1
21/01/2012
1.2
05/02/2012
1.3
Versión:
1.3
Fecha: 06/02/2012
Descripción
Elaboración inicial
Correcciones Documento
Correcciones Documento
Actualización
y
Correcciones
Documento
Confidencial
Autor
Jorge Duque
Jorge Duque
Jorge Duque
Jorge Duque
Page 2 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
Documento de Casos de Uso
1. Introducción
1.1. Propósito
El presente documento expone los casos de uso propuestos para el desarrollo del
sistema. En otras palabras, tenemos que éstos van a ser transformados en
funcionalidades del sistema donde cada una tendrá su propio actor u operador. También
se va a mostrar un diagrama completo y general de los casos de uso del sistema.
1.2. Alcance
Los casos de uso se presentan de una manera más detallada para así concluir cuales van
a ser las directrices de cada uno. Esto facilita el desarrollo del sistema, ya que se tienen
bien claros los objetivos y las características del mismo. Así que el alcance de este
documento está limitado hasta la fecha de entrega del producto. Por otro lado tenemos
que se plasmará lo que es el diagrama de casos de uso del sistema, el cual es el corazón
del desarrollo del sistema.
1.3. Definiciones, Acrónimos y Abreviaturas
Compiere: es una aplicación para negocios de tipo código abierto, ERP y CRM destinada
para las empresas de pequeño y mediano tamaño.
ERE: diagrama de Entidad-Relación Extendido.
ERP: Sistema de Planificación de Recursos Empresariales que integra y maneja gran
parte de los negocios asociados con la producción de una empresa.
Java: es un lenguaje de programación orientado a objetos desarrollado por Sun
Microsystems.
1.4. Referencias
Documento de Lista de Requerimientos.
1.5. Vista Previa
En lo que resta de documento se presentarán los cursos normales y alternos de los
casos. También se hablarán de otras características de éstos como lo son la frecuencia
de uso, los actores principales, las precondiciones, las postcondiciones, los
requerimientos especiales y la tecnología a utilizar. Cuando se esté hablando de la
frecuencia de uso de los casos de uso o funcionalidades tendremos la siguiente
clasificación:
Escaso: se usa muy poco.
Poco frecuente: el caso de uso se usa ocasionalmente.
Frecuente: se debe a que la operación se realiza de manera periódica.
Muy frecuente: sucede cuando se utiliza la operación regularmente.
Confidencial
Page 3 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
1.6. Resumen de Usuarios
Los usuarios son todos aquellos actores que van a interactuar con el sistema de manera
directa, y son los que van a ejecutar toda funcionalidad que se relacione con un Caso de
Uso específico. A continuación se presenta una síntesis de las características y
responsabilidades que poseen cada uno de estos usuarios.
Actor
Descripción
Responsabilidades
Empleado
del
departamento
Se encarga de realizar las
actividades
referidas
a
las
importaciones requeridas por la
empresa
Encargado
del
Departamento
Se encarga de supervisar
actividades realizadas por
empleados del departamento.
Administrador del
Sistema
Forma parte del equipo de
desarrollo del sistema, o personal
de mantenimiento
y soporte
adiestrado
para
dar
soporte
Compiere.
Tiene como responsabilidades la puesta de
solicitud
de importaciones, órdenes de
compra y el seguimiento de la mercancía.
Debe poder decir el estado de una
importación realizada por la empresa.
Tiene las mismas responsabilidades que los
empleados, más la responsabilidad de
manejar los productos y su creación,
modificación y eliminación. Esto con el fin de
que haya consistencia en los productos y no
hayan duplicados o faltantes.
Dar soporte a la usuarios del Departamento
con el manejo de sus cuentas de usuario,
perfiles y roles. A su vez otorgan los
premisos al usuario dependiendo de su
grado de responsabilidad en Empleado de
Departamento
o
Encargado
de
Departamento
las
los
Confidencial
Page 4 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
2. Vista de Casos de Uso
A continuación se presentan los casos de usos, así como el diagrama de CU:
Confidencial
Page 5 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
2.1 Resumen de Casos de Uso y Actores:
Caso de Uso
Actor
Requerimiento Funcional
Asociado
Entrar al Sistema
Empleado del Departamento /
Encargado del Departamento
R1
Salir del Sistema
Empleado del Departamento /
Encargado del Departamento
R2
Gestionar Proveedor
Empleado del Departamento /
Encargado del Departamento
Agregar Proveedor
Empleado del Departamento /
Encargado del Departamento
R3
Importar Proveedor
Empleado del Departamento /
Encargado del Departamento
R4
Modificar Proveedor
Empleado del Departamento /
Encargado del Departamento
R5
Consultar Proveedor
Empleado del Departamento /
Encargado del Departamento
R6
Eliminar Proveedor
Empleado del Departamento /
Encargado del Departamento
R7
Gestionar Usuario
Administrador del Sistema
Crear Usuario
Administrador del Sistema
R8
Modificar Usuario
Administrador del Sistema
R9
Consultar Usuario
Administrador del Sistema
R10
Eliminar Usuario
Administrador del Sistema
R11
Crear Perfil de Usuario
Administrador del Sistema
R12
Modificar Perfil de Usuario
Administrador del Sistema
R13
Eliminar Perfil de Usuario
Administrador del Sistema
R14
Modificar Contraseña
Empleado del Departamento /
Encargado del Departamento
R15
Gestionar Producto
Encargado del Departamento
Agregar Producto
Encargado del Departamento
R16
Importar Producto
Encargado del Departamento
R17
Modificar Producto
Encargado del Departamento
R18
Eliminar Producto
Empleado del Departamento
R19
Consultar Producto
Empleado del Departamento /
Encargado del Departamento
R20
Confidencial
Page 6 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
Gestionar Importación
Empleado del Departamento /
Encargado del Departamento
Generar Solicitud de Importación
Empleado del Departamento /
Encargado del Departamento
R21
Imprimir Solicitud de Importación
Empleado del Departamento /
Encargado del Departamento
R22
Agregar Producto a Solicitud de
Importación
Empleado del Departamento /
Encargado del Departamento
R23
Generar Orden de Compra
Internacional
Empleado del Departamento /
Encargado del Departamento
R24
Imprimir Orden de Compra
Internacional
Empleado del Departamento /
Encargado del Departamento
R25
Agregar Producto a la Orden de
Compra Internacional
Empleado del Departamento /
Encargado del Departamento
R26
Gestionar Factura Comercial
Empleado del Departamento /
Encargado del Departamento
Registrar Factura Comercial
Empleado del Departamento /
Encargado del Departamento
R27
Imprimir Factura Comercial
Empleado del Departamento /
Encargado del Departamento
R28
Registrar Seguimiento de Importación
Empleado del Departamento /
Encargado del Departamento
R29
Registrar Requerimientos de
Importación
Empleado del Departamento /
Encargado del Departamento
R30
Confidencial
Page 7 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
2.2 Especificaciones de cada caso de uso
2.2.1 Entrar al Sistema
Caso de uso: Entrar al Sistema
Descripción: Este caso de uso permite al usuario del sistema iniciar sesión para trabajar en el
módulo.
Requerimiento Asociado: R1
Precondición:
Debe estar registrado.
FLUJO BASICO:
ACTOR
SISTEMA
1. El usuario selecciona la opción de <Entrar al
sistema>
2. El sistema muestra la ventana solicitando
usuario y contraseña.
3. El usuario introduce su nombre de usuario y
contraseña.
4. El sistema verifica y autentifica el nombre
de usuario y contraseña con la base de
datos.
5. El usuario entra de forma exitosa al sistema.
FLUJOS ALTERNOS:
ACTOR
SISTEMA
Flujo 1
4a. El sistema puede señalar que el nombre
de usuario no se encuentra en la base de
datos y se cancela la operación.
4b. Retornar al punto 3.
Flujo 2
4a. El sistema autentica el nombre de usuario
pero la clave no concuerda con éste, entonces
el sistema cancela la operación.
4b. Retornar al punto 3.
Postcondición:
El usuario entra de manera exitosa al sistema y se cargan todos los permisos que tiene
asignado.
Frecuencia:
Muy Frecuente
Confidencial
Page 8 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
2.2.2 Salir del Sistema
Caso de uso: Salir del Sistema
Descripción: Este Caso de Uso permite al usuario salir del sistema de manera segura
Requerimiento asociado: R2
Precondición:
El usuario ha iniciado sesión
FLUJO BASICO:
ACTOR
SISTEMA
1. El usuario selecciona la opción de <Salir del
sistema>.
2. El sistema saca al usuario del sistema y
vuelve a la página de inicio. Y finaliza la
operación.
FLUJOS ALTERNOS:
Ninguno
Postcondición:
El usuario sale de manera exitosa del sistema.
Frecuencia:
Muy Frecuente
2.2.3 Gestionar Proveedor
Caso de uso: Gestionar Proveedor
Descripción: Permite al usuario realizar ciertas operaciones con los proveedores
Requerimiento asociado:
Precondición:
Debe haber iniciado sesión.
FLUJO BASICO:
ACTOR
SISTEMA
1. El usuario entra en la sección de gestión de
proveedores.
2. El sistema muestra los nombres de todos
los proveedores para que puedan ser
sometidos a modificaciones, a ser eliminados
o consultados. También queda abierta la
opción de agregar un proveedor más.
3. El usuario se decide por seleccionar una de
las opciones que puede aplicar sobre cada
proveedor.
4. El sistema carga una de las opciones
Confidencial
Page 9 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
seleccionadas y termina la operación.
FLUJOS ALTERNOS:
ACTOR
SISTEMA
Flujo 1
3a. El usuario no elige ninguna opción y
decide realizar otra actividad en el sistema.
Postcondición:
Gestión de los usuarios del sistema, se puede seleccionar crear, modificar, eliminar o consultar
un usuario.
Frecuencia:
Poco frecuente
2.2.4 Agregar Proveedor
Caso de uso: Agregar Proveedor
Descripción: Este caso de uso permite agregar un proveedor al sistema
Requerimiento asociado: R3
Precondición:
Tiene que estar autenticado el usuario y el proveedor no existe en el sistema
FLUJO BASICO:
ACTOR
1. El usuario
<Proveedor>
SISTEMA
selecciona
la
opción
de
2.
El
sistema
solicita
los
datos
correspondientes del nuevo Proveedor.
3. El usuario introduce los datos solicitados por
el sistema.
4. El sistema guarda todo la información del
nuevo proveedor en la base de datos y
finaliza la operación.
FLUJOS ALTERNOS:
ACTOR
SISTEMA
Flujo 1
3ª.El usuario podría abandonar el proceso de
creación del proveedor, ya que decidió realizar
otra operación en el sistema. Por lo que no se
almacena ningún dato.
Postcondición:
Se crea un nuevo proveedor en la base de datos del sistema.
Frecuencia:
Poco frecuente
Confidencial
Page 10 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
2.2.5 Importar Proveedor
Caso de uso: Importar Proveedor
Descripción: Este Caso de Uso permite importar más de un proveedor por vez. Sirve para
ahorrar tiempo y automatizar el proceso de carga de datos.
Requerimiento Asociado: R4
Precondición:
Debe haber iniciado sesión.
FLUJO BASICO:
ACTOR
SISTEMA
1. El usuario selecciona la opción de <Importar
Proveedor>.
2. El sistema solicita que se especifique el
formato de importación.
3. El usuario introduce específica el formato.
4. Luego de haber sido escogido el formato,
realiza la carga del archivo con los
proveedores.
FLUJOS ALTERNOS:
ACTOR
SISTEMA
Flujo 1.
3a. El usuario puede cancelar la creación del
proveedor y no se almacena ningún dato.
3b. Retorna a paso 1.
Postcondición:
Se importan al sistema el maestro de proveedores de la empresa.
Frecuencia:
Poco frecuente
2.2.6 Modificar Proveedor
Caso de uso: Modificar Proveedor
Descripción: Este caso de uso permite modificar los datos de un proveedor ya ingresado en
el sistema.
Requerimiento asociado: R5
Precondición:
Tiene que estar autenticado el usuario. Tiene que haber por lo menos un proveedor en la Base
de Datos
FLUJO BASICO:
ACTOR
SISTEMA
1. El usuario selecciona la opción de <Modificar
Proveedor>.
Confidencial
Page 11 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
2. El sistema muestra la ventana con la
información actual del Proveedor, la cuál va a
poder modificar.
3. El usuario sustituye la información que
estaba incorrecta y procede a modificar el
Proveedor.
4. El sistema carga la nueva información del
Proveedor y termina la operación.
FLUJOS ALTERNOS:
ACTOR
Flujo 1.
SISTEMA
2a. Hay algún problema a la hora de recuperar
los datos de la Base de Datos y se extrae
incorrectamente.
2b. Retorna a 1.
Postcondición:
Se modifica o actualiza la información correspondiente a un Proveedor
Frecuencia:
Muy frecuente
2.2.7 Consultar Proveedor
Caso de uso: Consultar Proveedor
Descripción: Este Caso de Uso permite hacer una revisión de los datos de un proveedor
Requerimiento asociado: R6
Precondición:
Debe haber al menos un proveedor
FLUJO BASICO:
ACTOR
1. El usuario selecciona
<Consultar Proveedor>.
SISTEMA
la
opción
de
2. El sistema solicita que se escoja un
proveedor.
3. El usuario selecciona un proveedor
4. El sistema busca la información del
proveedor en la base de datos y se la
muestra al usuario.
5. El usuario observa los datos y obtiene la
información requerida
FLUJOS ALTERNOS:
Confidencial
Page 12 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
Ninguno
Postcondición:
Se obtiene la información requerida de un proveedor.
Frecuencia:
Muy frecuente
2.2.8 Eliminar Proveedor
Caso de uso: Eliminar Proveedor
Precondición:
Tiene que estar autenticado el administrador del sistema. Tiene que existir al menos un
usuario aparte del administrador del sistema.
FLUJO BASICO:
ACTOR
SISTEMA
1. El usuario selecciona la opción de <Eliminar
proveedor>.
2. El sistema realiza una pregunta para que
el usuario ratifique su decisión de querer
eliminar el proveedor elegido.
3. El administrador responde de manera
afirmativa a la pregunta.
4. El sistema borra todo la información
relacionada con el proveedor y finaliza la
operación.
FLUJOS ALTERNOS:
ACTOR
Flujo 1.
3a. El administrador puede cancelar
eliminación del prooveedor respondiendo
forma
negativa
a
la
pregunta
comprobación. Por lo tanto se finaliza
operación.
Flujo 2.
SISTEMA
la
de
de
la
4a. El sistema puede que no elimine de forma
correcta al proveedor deseado, sí se presenta
un problema al intentar acceder a la base de
datos para borrarlo, por lo que la operación se
cancela.
Postcondición:
Se elimina correctamente el proveedor.
Frecuencia:
Poco frecuente
Confidencial
Page 13 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
2.2.9 Gestionar Usuario
Caso de uso: Gestionar Usuario
Descripción: Permite al usuario realizar ciertas operaciones con los usuarios
Requerimiento asociado:
Precondición:
Debe haber iniciado sesión y ser administrador del sistema
FLUJO BASICO:
ACTOR
SISTEMA
1. El usuario entra en la sección de gestión de
usuarios.
2. El sistema carga los nombres de todos los
usuarios para que puedan ser sometidos a
modificaciones,
a
ser
eliminados
o
consultados. También queda abierta la
opción de agregar un usuario más.
3. El usuario decide por seleccionar una de las
opciones que puede aplicar sobre cada
usuario.
4. El sistema carga una de las opciones
seleccionadas y termina la operación.
FLUJOS ALTERNOS:
ACTOR
SISTEMA
Flujo 1
3a. El usuario no elige ninguna opción y
decide realizar otra actividad en el sistema.
Postcondición:
Gestión de los usuarios del sistema, se puede seleccionar crear, modificar, eliminar o consultar
un usuario.
Frecuencia:
Poco frecuente
2.2.10 Crear Usuario
Caso de uso: Crear Usuario
Descripción: Este Caso de Uso permite crear un nuevo usuario del sistema
Requerimiento asociado: R8
Confidencial
Page 14 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
Precondición:
Tiene que estar autenticado el administrador del sistema y que el usuario a crear no esté ya en
el sistema
FLUJO BASICO:
ACTOR
SISTEMA
1. El usuario selecciona la opción de <Crear
usuario>.
2.
El
sistema
solicita
los
correspondientes del nuevo usuario.
datos
3. El usuario introduce los datos solicitados por
el sistema.
4. Luego de haber completado la parte de
rellenar los datos generales el usuario, el
sistema le solicita agregar los permisos del
usuario.
5. El administrador agrega el permiso de
usuario.
6. El sistema guarda todo la información del
nuevo usuario en la base de datos y finaliza
la operación.
FLUJOS ALTERNOS:
ACTOR
SISTEMA
Flujo 1.
3a. El administrador puede cancelar la
creación del usuario y no se almacena ningún
dato.
Flujo 2.
3ª. El usuario podría abandonar el proceso de
creación del usuario, ya que decidió realizar
otra operación en el sistema. Por lo que no se
almacena ningún dato.
Flujo 3.
5ª. El usuario podría abandonar el proceso de
creación del usuario, ya que decidió realizar
otra operación en el sistema. Por lo que no se
almacena ningún dato.
Flujo 4
Confidencial
Page 15 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
6b. Puede que el usuario ya exista en el
sistema, entonces se tiene que volver al paso
2.
Postcondición:
Se crea un nuevo usuario en la base de datos del sistema con sus respectivos permisos
dentro del mismo.
Frecuencia:
Poco frecuente
2.2.11 Modificar Usuario
Caso de uso: Modificar Usuario
Descripción: Este caso de uso permite realizar cambios en los datos a un usuario del sistema
Requerimiento asociado: R9
Precondición:
Tiene que estar autenticado el administrador del sistema.
FLUJO BASICO:
ACTOR
SISTEMA
1. El usuario selecciona la opción de <Modificar
Usuario>.
2. El sistema abre la ventana con las todos
los usuarios.
3. El usuario selecciona uno de los usuarios y
realiza las modificaciones
4. El sistema guarda las modificaciones y
guarda el usuario
FLUJOS ALTERNOS:
Ninguno
Postcondición:
Se modificó al usuario en el sistema
Frecuencia:
Poco frecuente
Confidencial
Page 16 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
2.2.12 Consultar Usuario
Caso de uso: Consultar Usuario
Descripción: Este Caso de Uso permite revisar la información de un usuario del sistema.
Requerimiento asociado: R10
Precondición:
Tiene que estar autenticado el administrador del sistema.
FLUJO BASICO:
ACTOR
1. El usuario selecciona
<Consultar usuario>.
SISTEMA
la
opción
de
2. El sistema busca la información del
usuario en la base de datos y se la muestra
al administrador del sistema.
3. El administrador observa los datos, examina
el permiso del usuario, y luego finaliza la
operación.
FLUJOS ALTERNOS:
Ninguno
Postcondición:
Se consulta la información del usuario del sistema.
Frecuencia:
Poco frecuente
2.2.13 Eliminar Usuario
Caso de uso: Eliminar Usuario
Descripción: Este caso de uso permite borrar de la base de datos a un usuario de tal manera
que no pueda ingresar al sistema nuevamente
Requerimiento asociado: R11
Precondición:
Tiene que estar autenticado el administrador del sistema. Tiene que existir al menos un
usuario aparte del administrador del sistema.
Confidencial
Page 17 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
FLUJO BASICO:
ACTOR
SISTEMA
1. El usuario selecciona la opción de <Eliminar
usuario>.
2. El sistema realiza una pregunta para que
el usuario ratifique su decisión de querer
eliminar el usuario elegido.
3. El administrador responde de manera
afirmativa a la pregunta.
4. El sistema borra todo la información
relacionada con el usuario, es decir, la
persona asignada ha dicho usuario no podrá
volver a entrar al sistema. Y finaliza la
operación.
FLUJOS ALTERNOS:
ACTOR
SISTEMA
Flujo 1
4a. El sistema puede que no elimine de forma
correcta al usuario deseado, sí se presenta un
problema al intentar acceder a la base de
datos para borrarlo, por lo que la operación se
cancela
Postcondición:
Se elimina el usuario del sistema.
Frecuencia:
Poco frecuente
2.2.14 Crear Perfil de Usuario
Caso de uso: Crear Perfil de Usuario
Descripción: Este caso de uso permite crear un perfil de usuario, esto quiere decir que le crea
un grupo de permisología que se asocia a ciertos usuarios.
Requrimiento asociado: R12
Precondición:
Tiene que estar autenticado el administrador del sistema.
FLUJO BASICO:
Confidencial
Page 18 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
ACTOR
1. El usuario selecciona la opción de <Perfil>.
Versión:
1.3
Fecha: 06/02/2012
SISTEMA
2. El sistema abre la ventana con las
opciones de perfil
3. El usuario selecciona nuevo perfil
4. El sistema abre una nueva ventana con
sus campos en blanco. Indica con cuales son
obligatorios.
5. El usuario asigna un nombre al perfil y
rellena todos los campos obligatorios y
opcionales y le da a la opción Guardar.
6. El sistema guarda todo la información del
nuevo perfil en la base de datos y finaliza la
operación.
FLUJOS ALTERNOS:
ACTOR
SISTEMA
Flujo 1.
5b. El usuario selecciona un nombre de perfil
que ya está dentro del sistema. El sistema
avisa al usuario y debe introducir uno nuevo
Postcondición:
Se crea un nuevo perfil de usuario en el sistema
Frecuencia:
Poco frecuente
2.2.15 Modificar Perfil de Usuario
Caso de uso: Modificar Perfil de Usuario
Descripción: Este Caso de uso permite realizar cambios a un perfil de usuario ya existente.
Requerimiento asociado: R13
Precondición:
Tiene que estar autenticado el administrador del sistema.
FLUJO BASICO:
ACTOR
SISTEMA
1. El usuario selecciona la opción de <Perfil>.
2. El sistema abre la ventana con las
opciones de perfil
3. El usuario selecciona el perfil a modificar
4. El sistema abre una nueva ventana del
Confidencial
Page 19 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
perfil seleccionado.
5. El usuario realiza las modificaciones y le da
a la opción Guardar.
6. El sistema guarda todo la información del
perfil modificado en la base de datos y
finaliza la operación.
FLUJOS ALTERNOS:
ACTOR
SISTEMA
Flujo 1.
5a. El usuario guarda sin haber escrito un
campo obligatorio. El sistema no deja realizar
el cambio.
5b. Repite paso 5.
Postcondición:
Se modificó un perfil de usuario en el sistema
Frecuencia:
Poco frecuente
2.2.16 Eliminar Perfil de Usuario
Caso de uso: Eliminar Perfil de Usuario
Descripción: Este Caso de Uso permite eliminar un perfil creado con el fin de asignarlo a un o
a un grupo de usuarios
Requerimiento asociado: R14
Precondición:
Tiene que estar autenticado el administrador del sistema.
FLUJO BASICO:
ACTOR
SISTEMA
1. El usuario selecciona la opción de <Perfil>.
2. El sistema abre la ventana con las
opciones de perfil
3. El usuario selecciona el perfil a eliminar
4. El sistema abre una nueva ventana del
perfil seleccionado.
Confidencial
Page 20 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
5. El usuario seleccionar la opción eliminar
6. El sistema elimina todo la información del
perfil borrado en la base de datos y finaliza la
operación.
FLUJOS ALTERNOS:
Ninguno
Postcondición:
Se eliminó un perfil de usuario en el sistema
Frecuencia:
Poco frecuente
2.2.17 Modificar Contraseña
Caso de uso: Modificar Contraseña.
Descripción:
Permite a un usuario cambiar su contraseña.
Requerimiento asociado: R15
Precondición:
El usuario debe haber iniciado sesión.
FLUJO BASICO:
ACTOR
SISTEMA
1 - El actor selecciona la opción de modificar
contraseña.
2 - El sistema redirige al usuario a la ventana
donde podrá cambiar su contraseña.
3 - El usuario ingresa su contraseña actual y la
nueva.
4 - El sistema realiza el cambio en la base de
datos y redirige al usuario a la ventana
principal.
FLUJOS ALTERNOS:
ACTOR
SISTEMA
Flujo 1.
4a. Problema de comunicación con la Base de Datos y se produce un error.
4b. Retorna Paso 1.
Postcondición:
El usuario cambió su contraseña.
Confidencial
Page 21 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
2.2.18 Gestionar Producto
Caso de uso: Gestionar Productos
Descripción: Permite al usuario realizar ciertas operaciones con los productos
Requerimiento asociado:
Precondición:
Tiene que estar autenticado el Encargado el Departamento.
FLUJO BASICO:
ACTOR
SISTEMA
1. El usuario entra en la sección de gestión de
productos
2. El sistema carga los nombres de todos los
productos para que puedan ser sometidos a
modificaciones,
a
ser
eliminados
o
consultados. También queda abierta la
opción de agregar un producto más.
3. El usuario decide por seleccionar una de las
opciones que puede aplicar sobre cada
producto.
4. El sistema carga una de las opciones
seleccionadas y termina la operación.
FLUJOS ALTERNOS:
ACTOR
SISTEMA
Flujo 1.
3a. El usuario no elige ninguna opción y decide realizar otra actividad en el sistema.
Postcondición:
Gestión de los productos del sistema, se puede seleccionar crear, modificar, eliminar o
consultar un producto.
Frecuencia:
Poco frecuente
Confidencial
Page 22 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
2.2.19 Agregar Producto
Caso de uso: Agregar Producto
Descripción: Este Caso de Uso permite agregar un producto al sistema.
Requerimiento asociado: R16
Precondición:
El usuario tiene que estar autenticado en el sistema como Administrador de sistema
FLUJO BASICO:
ACTOR
SISTEMA
1. El usuario selecciona la opción de <Añadir
producto>.
2. El sistema solicita los datos relacionados
al producto.
3. El usuario introduce
correspondiente al producto.
la
información
4.
El
sistema
correspondiente
carga
el
producto
FLUJOS ALTERNOS:
ACTOR
SISTEMA
Flujo1
3a. El usuario podría cancelar la operación.
Postcondición:
Se añade un producto al sistema.
Frecuencia:
Muy frecuente
2.2.20 Importar Producto
Caso de uso: Importar Producto
Descripción: Este Caso de Uso permite importar más de un producto por vez. Sirve para
ahorrar tiempo y automatizar el proceso de carga de datos.
Confidencial
Page 23 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
Requerimiento Asociado: R17
Precondición:
Debe haber iniciado sesión un encargado de departamento.
FLUJO BASICO:
ACTOR
SISTEMA
1. El usuario selecciona la opción de <Importar
Producto>.
2. El sistema solicita que se especifique el
formato de importación.
3. El usuario introduce específica el formato.
4. Luego de haber sido escogido el formato,
realiza la carga del archivo con los productos.
FLUJOS ALTERNOS:
ACTOR
SISTEMA
Flujo 1.
3a. El usuario puede cancelar la creación del
producto y no se almacena ningún dato.
3b. Retorna a paso 1.
Postcondición:
Se importan al sistema el maestro de producto de la empresa.
Frecuencia:
Poco frecuente
2.2.21 Modificar Producto
Caso de uso: Modificar Producto
Descripción: Este Caso de Uso permite realizar cambios en un producto de la base de datos.
Requerimiento asociado: R18
Precondición:
Tiene que estar autenticado en el Encargado del Departamento. Tiene que haber por lo menos
un producto añadido.
FLUJO BASICO:
ACTOR
SISTEMA
1. El usuario selecciona la opción de <Modificar
Producto>.
El sistema muestra la ventana con la
información actual del producto, la cuál va a
poder modificar.
3. El usuario sustituye la información que
estaba incorrecta y procede a modificar el
producto.
4. El sistema carga la nueva información del
Confidencial
Page 24 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
producto y termina la operación.
FLUJOS ALTERNOS:
ACTOR
Flujo
3a. El usuario decide cancelar la operación.
SISTEMA
Postcondición:
Se modifica o actualiza la información correspondiente a un producto
Frecuencia:
Muy frecuente
2.2.22 Eliminar Producto
Caso de uso: Eliminar Producto
Descripción: Este caso de uso permite borrar de la base de datos un producto que esta
incorrecto o que no se va a usar más.
Requerimiento asociado: R19
Precondición:
El usuario tiene que estar autenticado en el sistema. Tiene que haber al menos un producto
FLUJO BASICO:
ACTOR
SISTEMA
1. El usuario selecciona la opción de <Eliminar
producto>
2. El sistema procede a realizar una pregunta
de verificación, ya que toda la información
será perdida.
3. El usuario responde que está seguro de
querer eliminar el producto.
4. El sistema elimina el producto del sistema
y culmina la operación.
FLUJOS ALTERNOS:
ACTOR
SISTEMA
Flujo 1.
3a. El usuario puede responder de manera
negativa, lo que evita la eliminación del
producto.
Postcondición:
Se elimina el producto del sistema
Frecuencia:
Poco frecuente
Confidencial
Page 25 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
2.2.23 Consultar Producto
Caso de uso: Consultar Producto
Descripción: Este Caso de Uso permite revisar los datos de un producto almacenado en el
sistema
Requerimiento asociado: R20
Precondición:
El usuario tiene que estar autenticado en el sistema. Tiene que haber al menos un producto
FLUJO BASICO:
ACTOR
1. El usuario selecciona
<Consultar producto>
SISTEMA
la
opción
de
2. El sistema busca la información
correspondiente al producto que se quiere
consultar y se la muestra al usuario.
3. El usuario revisa la información y culmina la
operación.
FLUJOS ALTERNOS:
Ninguno
Postcondición:
Se consultan los datos correspondientes a un producto.
Frecuencia:
Muy frecuente
2.2.24 Gestionar Importación
Caso de uso: Gestionar Importación
Descripción: Permite al usuario realizar ciertas operaciones con de importación como crear
Solicitud de Importación o la generación de una Orden de Compra Internacional
Requerimiento asociado:
Precondición:
Tiene que estar autenticado el usuario (Empleado o Encargado Departamento).
FLUJO BASICO:
Confidencial
Page 26 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
ACTOR
SISTEMA
1. El usuario entra en la sección de gestión de
importación.
2. El sistema muestra los nombres de las
acciones referentes a las importaciones:
Generar Orden de Compra, Generar Solicitud
de Importación, Hacer Seguimiento de
Importación, Definir Requerimientos de
Importación y Realizar Factura Comercial.
3. El usuario decide por seleccionar una de las
opciones que puede aplicar.
4. El sistema carga una de las opciones
seleccionadas y termina la operación.
FLUJOS ALTERNOS:
Ninguno
Postcondición:
Gestión de Importaciones, se realiza correctamente una de las siguiente acciones: Generar
Orden de Compra, Generar Solicitud de Importación, Registrar Seguimiento de Importación,
Definir Requerimientos de Importación y Registrar Factura Comercial.
Frecuencia:
Muy frecuente
2.2.25 Generar Solicitud de Importación
Caso de uso: Generar Solicitud de Importación
Descripción: Este Caso de Uso permite a un usuario generar una Solicitud de Importación
Requerimiento asociado: R21
Precondición:
Tiene que estar autenticado el usuario.
FLUJO BASICO:
ACTOR
SISTEMA
1. El usuario selecciona la opción de <Solicitud
de Importación>.
2.
El
sistema
solicita
los
datos
correspondientes a una solicitud de
importación.
3. El usuario introduce los datos solicitados por
el sistema.
4. Luego de haber completado la parte de
rellenar los datos generales de la solicitud, el
sistema guarda todo la información en la
base de datos y finaliza la operación.
FLUJOS ALTERNOS:
Confidencial
Page 27 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
ACTOR
SISTEMA
Flujo 1.
3a. El usuario puede cancelar la creación de la
solicitud y no se almacena ningún dato.
Flujo 2.
3b. El usuario podría abandonar el proceso de
creación, ya que decidió realizar otra
operación en el sistema. Por lo que no se
almacena ningún dato.
Postcondición:
Se genera una Solicitud de Importación
Frecuencia:
Muy frecuente
2.2.26 Imprimir Solicitud de Importación
Caso de uso: Imprimir Solicitud de Importación
Descripción: Este Caso de Uso permite al usuario imprimir una Solicitud de Importación
desde la ventana del sistema.
Requerimiento asociado: R22
Precondición:
Tiene que estar autenticado el usuario y una solicitud de orden activa.
FLUJO BASICO:
ACTOR
SISTEMA
1. El usuario selecciona una <Solicitud de
Importación>.
2.
El
sistema
muestra
los
datos
correspondientes a esa solicitud
3. El usuario selecciona Imprimir Solicitud de
Importación
4. El sistema muestra en pantalla, la solicitud
de la Importación.
FLUJOS ALTERNOS:
ACTOR
SISTEMA
Flujo 1
3a. El usuario podría abandonar el proceso de
creación, ya que decidió realizar otra
operación en el sistema. Por lo que no se
imprime la solicitud.
Postcondición:
Se genera una Solicitud de Importación
Frecuencia:
Muy frecuente
Confidencial
Page 28 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
2.2.27 Agregar Producto a Solicitud de Importación
Caso de uso: Agregar Producto a Solicitud de Importación
Descripción: Este Caso de Uso permite agregar productos a una solicitud de importación
activa
Requerimiento asociado: R23
Precondición:
Tiene que estar autenticado el usuario y tiene que haber una solicitud de importación activa.
FLUJO BASICO:
ACTOR
1. El usuario selecciona una
Importación>.
SISTEMA
<Solicitud de
2.
El
sistema
muestra
los
correspondientes a esa solicitud
datos
3. El usuario selecciona Agregar Producto a
Solicitud.
4 El sistema
disponibles
muestra
los
productos
5. El usuario selecciona el producto
6. El sistema agrega el producto a la Solicitud
FLUJOS ALTERNOS:
ACTOR
SISTEMA
Flujo 1.
3a. El usuario podría abandonar el proceso de
creación, ya que decidió realizar otra
operación en el sistema. Por lo que no se
almacena ningún producto en la solicitud.
Flujo 2.
6a. El producto ya se encuentra en la solicitud
6b. Ir a punto 5.
Postcondición:
Se agregó un nuevo producto a una Solicitud de Importación
Frecuencia:
Muy frecuente
2.2.28 Generar Orden de Compra Internacional
Caso de uso: Generar Orden de Compra Internacional
Confidencial
Page 29 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
Descripción: Este Caso de Uso permite a un usuario generar una Orden de Compra
Requerimiento asociado: R24
Precondición:
Tiene que estar autenticado el usuario.
FLUJO BASICO:
ACTOR
SISTEMA
1. El usuario selecciona la opción de <Orden de
Compra Internacional>.
2.
El
sistema
solicita
los
datos
correspondientes a una Orden de Compra
Internacional.
3. El usuario introduce los datos solicitados por
el sistema.
4. Luego de haber completado la parte de
rellenar los datos generales de la Orden, el
sistema guarda todo la información en la
base de datos y finaliza la operación.
FLUJOS ALTERNOS:
ACTOR
SISTEMA
Flujo 1.
3a. El usuario puede cancelar la creación de la
Orden y no se almacena ningún dato.
Flujo 2.
3b. El usuario podría abandonar el proceso de
creación, ya que decidió realizar otra
operación en el sistema. Por lo que no se
almacena ningún dato.
Postcondición:
Se genera una Orden de Compra Internacional
Frecuencia:
Muy frecuente
2.2.29 Imprimir Orden de Compra Internacional
Caso de uso: Imprimir Orden de Compra Internacional
Descripción: Este Caso de Uso permite al usuario imprimir una Orden de Compra
Internacional desde la ventana del sistema.
Requerimiento asociado: R25
Precondición:
Tiene que estar autenticado el usuario y haber por lo menos una orden de compra activa.
FLUJO BASICO:
ACTOR
SISTEMA
Confidencial
Page 30 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
1. El usuario selecciona una <Orden de
Compra Internacional>.
2.
El
sistema
muestra
correspondientes a esa Orden
los
datos
3. El usuario selecciona Imprimir Orden de
Compra Internacional
4. El sistema muestra en pantalla, la Orden
de Compra Internacional.
FLUJOS ALTERNOS:
ACTOR
SISTEMA
Flujo 1
3a. El usuario podría abandonar el proceso de
impresión, ya que decidió realizar otra
operación en el sistema. Por lo que no se
imprime la orden.
Postcondición:
Se genera una Orden de Compra Internacional.
Frecuencia:
Muy frecuente
2.2.30 Agregar Producto a la Orden de Compra Internacional
Caso de uso: Agregar Producto a la Orden de Compra Internacional
Descripción: Este Caso de Uso permite agregar productos a una Orden de Compra activa
Requerimiento asociado: R26
Precondición:
Tiene que estar autenticado el usuario y tiene que haber una solicitud Orden de Compra
Activa.
FLUJO BASICO:
ACTOR
1. El usuario selecciona una
Compra Internacional>.
SISTEMA
<Orden de
2.
El
sistema
muestra
correspondientes a esa Orden
los
datos
3. El usuario selecciona Agregar Producto a
Orden
4 El sistema
disponibles
muestra
los
productos
5. El usuario selecciona el producto
6. El sistema agrega el producto a la Orden
de Compra
FLUJOS ALTERNOS:
Confidencial
Page 31 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
ACTOR
SISTEMA
Flujo 1.
3a. El usuario podría abandonar el proceso de
creación, ya que decidió realizar otra
operación en el sistema. Por lo que no se
almacena ningún producto en la Orden.
Flujo 2.
6a. El producto ya se encuentra en la Orden
6b. Ir a punto 5.
Postcondición:
Se agregó un nuevo producto a una Orden de Compra Internacional
Frecuencia:
Muy frecuente
2.2.31 Gestionar Factura Comercial
Caso de uso: Gestionar Factura Comercial
Descripción: Permite al usuario realizar ciertas operaciones de la Factura Comercial como
Registrar o Imprimir Factura Comercial
Requerimiento asociado:
Precondición:
Tiene que estar autenticado el usuario (Empleado o Encargado Departamento).
FLUJO BASICO:
ACTOR
SISTEMA
1. El usuario entra en la sección de gestión de
de Factura Comercial
2. El sistema muestra los nombres de las
acciones referentes a las Factura Comercial
3. El usuario decide por seleccionar una de las
opciones que puede aplicar.
4. El sistema carga una de las opciones
seleccionadas y termina la operación.
FLUJOS ALTERNOS:
Ninguno
Postcondición:
Gestión de Factura Comercial se realiza correctamente una de las siguiente acciones:
Registrar Factura Comercial e Imprimir Factura Comercial
Frecuencia:
Muy frecuente
Confidencial
Page 32 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
2.2.32 Registrar Factura Comercial
Caso de uso: Registrar Factura Comercial
Descripción: Permite registrar los datos de una factura comercial emitida por un proveedor
internacional.
Requerimiento asociado: R27
Precondición:
Tiene que estar autenticado el usuario.
FLUJO BASICO:
ACTOR
SISTEMA
1. El usuario selecciona la opción de < Factura
Comercial >.
2.
El
sistema
solicita
los
datos
correspondientes a Factura Comercial.
3. El usuario introduce los datos solicitados por
el sistema.
4. Luego de haber completado la parte de
rellenar los datos generales de la factura, el
sistema guarda todo la información en la
base de datos y finaliza la operación.
FLUJOS ALTERNOS:
ACTOR
SISTEMA
Flujo 1.
3a. El usuario puede cancelar la creación del
seguimiento y no se almacena ningún dato.
Flujo 2.
3b. El usuario podría abandonar el proceso de
creación, ya que decidió realizar otra
operación en el sistema. Por lo que no se
almacena ningún dato.
Postcondición:
Se crean una factura comercial de la Importación
Frecuencia:
Muy frecuente
2.2.33 Imprimir Factura Comercial
Caso de uso: Imprimir Factura Comercial
Descripción: Este Caso de Uso permite al usuario imprimir una Factura Comercial desde la
ventana del sistema.
Confidencial
Page 33 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
Requerimiento asociado: R28
Precondición:
Tiene que estar autenticado el usuario y haber por lo menos una Factura activa.
FLUJO BASICO:
ACTOR
1. El usuario
Comercial>.
SISTEMA
selecciona
una
<Factura
2.
El
sistema
muestra
los
correspondientes a esa Factura
datos
3. El usuario selecciona Imprimir Factura
Comercial
4. El sistema muestra en pantalla, la Factura
Comercial
FLUJOS ALTERNOS:
ACTOR
SISTEMA
Flujo 1
3a. El usuario podría abandonar el proceso de
impresión, ya que decidió realizar otra
operación en el sistema. Por lo que no se
imprime la factura.
Postcondición:
Se imprimé una Factura Comercial
Frecuencia:
Muy frecuente
2.2.34 Registrar Seguimiento de Importación
Caso de uso: Registrar Seguimiento de Importación
Descripción: Este Caso de Uso permite a un usuario Registrar un Seguimiento de
Importación
Requerimiento asociado: R29
Precondición:
Tiene que estar autenticado el usuario y haber una Orden de Compra activa a la cual realizarle
el registro de seguimiento.
FLUJO BASICO:
ACTOR
1. El usuario selecciona la
<Seguimiento de Importación >.
SISTEMA
opción
de
2.
El
sistema
solicita
los
datos
correspondientes
al
seguimiento
de
importación.
3. El usuario introduce los datos solicitados por
el sistema.
4. Luego de haber completado la parte de
Confidencial
Page 34 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
rellenar los datos generales del seguimiento,
el sistema guarda todo la información en la
base de datos y finaliza la operación.
FLUJOS ALTERNOS:
ACTOR
SISTEMA
Flujo 1.
3a. El usuario puede cancelar la creación del
seguimiento y no se almacena ningún dato.
Flujo 2.
3b. El usuario podría abandonar el proceso de
creación, ya que decidió realizar otra
operación en el sistema. Por lo que no se
almacena ningún dato.
Postcondición:
Se crea un seguimiento de importación
Frecuencia:
Muy frecuente
2.2.35 Registrar Requerimientos de Importación
Caso de uso: Registrar Requerimientos de Importación
Descripción: Este Caso de Uso permite a un usuario Registrar los Requerimientos
Importación
Requerimiento asociado: R30
de
Precondición:
Tiene que estar autenticado el usuario y orden de compra activa a la cual hacerle el registro de
los requerimientos
FLUJO BASICO:
ACTOR
1. El usuario selecciona la opción
<Requerimientos de Importación >.
SISTEMA
de
2.
El
sistema
solicita
los
datos
correspondiente
a
requerimientos
de
importación.
3. El usuario introduce los datos solicitados por
el sistema.
4. Luego de haber completado la parte de
rellenar
los
datos
generales
de
requerimientos, el sistema guarda todo la
información en la base de datos y finaliza la
operación.
FLUJOS ALTERNOS:
ACTOR
SISTEMA
Confidencial
Page 35 of 36
<Company Name>, 2012
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Casos de Uso
Versión:
1.3
Fecha: 06/02/2012
Flujo 1.
3a. El usuario puede cancelar la creación del
seguimiento y no se almacena ningún dato.
Flujo 2.
3b. El usuario podría abandonar el proceso de
creación, ya que decidió realizar otra
operación en el sistema. Por lo que no se
almacena ningún dato.
Postcondición:
Se crean los requerimientos de importación
Frecuencia:
Muy frecuente
Confidencial
Page 36 of 36
<Company Name>, 2012
SUMINDU, S.A
Implementación del Módulo de
Compras Internacionales en el Sistema
Compiere ERP
Modelo de Interfaz
Versión 1.0
Implementación del Módulo de Compras Internacionales Versión: 1.0
en el Sistema Compiere ERP
Modelo de Interfaz
Fecha: 29/12/2011
Historia de Revisión
Fecha
Versión
18/12/2011 1.0
Descripción
Primera Versión
Autor
Jorge Duque
2
Implementación del Módulo de Compras Internacionales Versión: 1.0
en el Sistema Compiere ERP
Modelo de Interfaz
Fecha: 29/12/2011
Índice
1. Introducción
1.1. Propósito
1.2. Alcance
1.3. Definiciones, Acrónimos y Abreviaciones
1.4. Referencias
1.5. Vista Previa
2. Diagrama Entidad-Relación-Extendido
2.1. Diagrama ERE
3. Diccionario de Datos
3.1. Entidades
3.2. Interrelaciones
4. Modelo de Interfaz basado en la estructura de los datos
4
4
4
4
4
4
5
5
6
6
12
14
3
Implementación del Módulo de Compras Internacionales Versión: 1.0
en el Sistema Compiere ERP
Modelo de Interfaz
Fecha: 29/12/2011
Documento Modelo de Interfaz
1. Introducción
1.1. Propósito
Este documento tiene la particularidad de ser un artefacto que no entra dentro de lo
que es la metodología cascada, ya que la descripción de la interfaz de un sistema se
hace mediante diagramas WAE. Como el módulo de Compras Internacionales va a
ser desarrollado como parte del ERP Compiere, es importante que quede claro el
proceso de construcción de la interfaz del sistema. Todo esto se debe a que
Compiere utiliza un modelo basado en la estructura de los datos.
1.2. Alcance
La información que se explica estará vigente a lo largo de todo el desarrollo de
proyecto, ya que es muy importante tener en claro como es el funcionamiento de la
generación de pantallas y prototipos de las mismas. Como el código de Compiere es
abierto, se podrá profundizar en la estructura de datos utilizada por el ERP para
crear la interfaz de los módulos.
1.3. Definiciones, Acrónimos y Abreviaciones
AD: Application Dictionary (Diccionario aplicativo), es el nombre que se le da al
conjunto de tablas de la base de datos que componen a Compiere.
AS/400: Es un equipo de IBM de gama media y alta, para todo tipo de empresas y
grandes departamentos.
Compiere: es una aplicación para negocios de tipo código abierto, ERP y CRM
destinada para las empresas de pequeño y mediano tamaño.
CRM: La gestión de la relación con los clientes, es un modelo de gestión de toda la
organización, basada en la orientación al cliente, es decir, servicio al cliente.
ERP: Sistema de Planificación de Recursos Empresariales que integra y maneja
gran parte de los negocios asociados con la producción de una empresa.
1.4. Referencias
Código fuente de Compiere, a nivel de base de datos.
Documentos de Compiere.
1.5. Vista Previa
Lo que resta de documento va a contener la presentación del diagrama entidad
relación referente a la estructura de base de datos que posee Compiere para
generar y almacenar las pantallas del sistema. También se cuenta con una
4
Implementación del Módulo de Compras Internacionales Versión: 1.0
en el Sistema Compiere ERP
Modelo de Interfaz
Fecha: 29/12/2011
descripción de los componentes que conforman a cada una de las entidades del
diagrama de base de datos, es decir, un diccionario de datos para el diagrama
correspondiente.
2. Diagrama Entidad-Relación-Extendido
2.1. Diagrama ERE
5
Implementación del Módulo de Compras Internacionales Versión: 1.0
en el Sistema Compiere ERP
Modelo de Interfaz
Fecha: 29/12/2011
3. Diccionario de Datos
3.1. Entidades
Entidad
Descripción
Atributos
Descripción de
Atributo
Tipo
Atributo
AD_WINDOW_ID
Identificador de la
ventana o
pantalla de
Compiere.
CREATED
Fecha en que se
creó la ventana.
CREATEDBY
Usuario que creó
la ventana.










Almacenado
Clave
Monovaluado
Simple
Almacenado
Monovaluado
Simple
Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple









Almacenado
Monovaluado
Simple
Almacenado
Monovaluado
Simple
Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple
DESCRIPTION
HELP
ISACTIVE
AD_WINDOW
Es la tabla que
contiene la
información para
crear las ventanas
que se van a
desplegar en
Compiere, o las
ventanas para
permitir la entrada de
datos.
Descripción breve
de las
características de
la ventana.
Es un pequeño
comentario,
ayuda o tip.
Significa que la
ventana se
encuentra activa
en el sistema.
ISBETAFUNCTIONALITY
ISCUSTOMDEFAULT
La ventana está
personalizada por
defecto.
ISDEFAULT
Tiene un valor por
defecto.
NAME
PROCESSING
UPDATED
UPDATEDBY
WINDOWTYPE
Identificador
alfanumérico de
la entidad
Ventana.
No está lista la
construcción de la
ventana.
Fecha en que se
actualizó o
modificó la
ventana.
Usuario que se
dispuso a
modificar la
ventana.
Tipo de Ventana.
Puede ser de
mantenimiento,
de transacción o
de consulta.
de
6
Implementación del Módulo de Compras Internacionales Versión: 1.0
en el Sistema Compiere ERP
Modelo de Interfaz
Fecha: 29/12/2011
WINHEIGHT
Alto de la
ventana.
WINWIDTH
Ancho de la
ventana.
AD_TAB_ID
COMMITWARNING
AD_TAB
Es la tabla que
contiene las pestañas
que se muestran
dentro de una
ventana que se
despliega de
Compiere. En la
pestañas se pueden
insertar datos. En
pocas palabras,
tenemos que la
funcionalidad de la
ventana está
representada por la
de las pestañas. Sólo
aquellas que son de
consulta o de entrada
de datos.
Identificador de la
pestaña
perteneciente a
una ventana.
Es un mensaje
que se despliega
en pantalla
cuando se salva
un registro.
CREATED
Fecha en que se
creó la pestaña.
CREATEDBY
Usuario que creó
la pestaña.
DESCRIPTION
DISPLAYLOGIC
HASTREE
HELP
IMPORTFIELDS
INCLUDED_TAB_ID
ISACTIVE
ISADVANCEDTAB
ISDISPLAYED
ISINFOTAB
Descripción breve
de las
características de
la pestaña.
Es una condición
que determina el
mostrar o no la
pestaña.
Si la ventana a la
cual pertenece la
pestaña posee un
grafo.
Es un pequeño
comentario,
ayuda o tip.
Se crean campos
que provienen de
otras tablas.
Identificador de
otra pestaña que
está incluida en la
misma.
Significa que la
ventana se
encuentra activa
en el sistema.
La pestaña posee
funcionalidades
avanzadas.
Determina si el
campo ha sido
desplegado o
mostrado.
Significa que la
pestaña contiene










Almacenado
Monovaluado
Simple
Almacenado
Monovaluado
Simple
Almacenado
Clave
Monovaluado
Simple



Almacenado
Monovaluado
Simple






Almacenado
Monovaluado
Simple
Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple






Almacenado
Monovaluado
Simple
Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple


Almacenado
Monovaluado
7
Implementación del Módulo de Compras Internacionales Versión: 1.0
en el Sistema Compiere ERP
Modelo de Interfaz
Fecha: 29/12/2011
ISINSERTRECORD
ISREADONLY
ISSINGLEROW
ISSORTTAB
ISTRANSLATIONTAB
NAME
ORDERBYCLAUSE
PROCESSING
READONLYLOGIC
información de
contabilidad.
El usuario puede
o no introducir un
nuevo registro.
El campo es de
sólo lectura.
Define si la
pestaña contiene
una o varias filas.
La pestaña
determina el
orden de los
campos.
La pestaña
contiene
información
traducida.
Identificador
alfanumérico de
la pestaña.
La pestaña se
encuentra
ordenada por
alguna cláusula.
No está lista la
construcción de la
pestaña.
Si posee una
lógica para
determinar si un
campo es de sólo
lectura.

Simple









Almacenado
Monovaluado
Simple
Almacenado
Monovaluado
Simple
Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple
REFERENCED_TAB_ID
Pestaña de
referencia.



Almacenado
Monovaluado
Simple
SEQNO
Método para
ordenar los
elementos de la
pestaña.



Almacenado
Monovaluado
Simple
TABLEVEL
Nivel jerárquico
de la pestaña.



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple




Almacenado
Monovaluado
Simple
Almacenado
UPDATED
UPDATEDBY
Fecha en que se
actualizó o
modificó la
pestaña.
Usuario que se
dispuso a
modificar la
pestaña.
WHERECLAUSE
Sentencia SQL
WHERE.
AD_FIELD_ID
Identificar del
8
Implementación del Módulo de Compras Internacionales Versión: 1.0
en el Sistema Compiere ERP
Modelo de Interfaz
Fecha: 29/12/2011
CREATED
CREATEDBY
DEFAULTVALUE
AD_FIELD
Es la tabla que
contiene los campos
que conforman parte
de una pestaña, que
a su vez pertenece a
una ventana de
Compiere. Estos
campos son los que
muestran datos y
permiten la entrada
de los mismos al
sistema.
DESCRIPTION
DISPLAYLENGTH
HELP
ISACTIVE
ISCENTRALLYMAINTAINED
ISDEFAULTFOCUS
ISDISPLAYED
ISENCRYPTED
ISFIELDONLY
ISHEADING
ISMANDATORY
campo
perteneciente a
una pestaña.
Fecha de
creación del
campo.
Usuario que creó
el campo.
Valor por defecto
que se le coloca
al campo.
Breve descripción
de las
características o
aspectos del
campo.
Tamaño del
campo en
pantalla en
caracteres.
Es un pequeño
comentario,
ayuda o tip.
Significa que la
ventana se
encuentra activa
en el sistema.
Información del
elemento que se
queda fija en el
sistema.
El campo recibe
un enfoque por
defecto.
Determina si el
campo ha sido
desplegado o
mostrado.
Se refiere a si el
elemento a
mostrar en el
campo está
encriptado o no.
La etiqueta del
campo no es
mostrada.
Campo sin
columna
asociada, sólo se
muestra la
etiqueta del
campo.
Determina si el
campo es
obligatorio o no.












Clave
Monovaluado
Simple
Almacenado
Monovaluado
Simple
Almacenado
Monovaluado
Simple
Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple
9
Implementación del Módulo de Compras Internacionales Versión: 1.0
en el Sistema Compiere ERP
Modelo de Interfaz
Fecha: 29/12/2011
ISREADONLY
ISSAMELINE
MAXHEIGHT
MAXWIDTH
MRSEQNO
NAME
OBSCURETYPE
SEQNO
SORTNO
UPDATED
UPDATEDBY
AD_COLOR
AD_CTXAREA
Es la tabla que
contiene los colores
que se pueden utilizar
para colocarle a los
fondos de las
pantallas de
Compiere y a la
representación de los
indicadores del
sistema.
Es el área de
Negocio a la Cual
pertenecen las
pestañas o ventanas
AD_COLOR_ID
AD_CTXAREA_ID
Determina si el
campo es de sólo
lectura.
Determina si el
campo va a estar
o no en la misma
línea que otro
campo.
Altura máxima del
campo donde se
va a introducir la
información.
Ancho máximo
del campo donde
se va a introducir
la información.
Método para
ordenar los
campos en varias
filas.
Identificador
alfanumérico del
campo.
Como va a ser
mostrado o
ocultado el
campo.
Método para
ordenar los
campos.
Determina el
orden en el cuál
va a ser mostrado
el campo.
Fecha en que se
actualizó o
modificó el
campo.
Usuario que se
dispuso a
modificar el
campo.



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple



Almacenado
Monovaluado
Simple
Identificador del
color para fondos
de pantalla o para
los indicadores de
Compiere.




Almacenado
Clave
Monovaluado
Simple
Identificador de la
terminología
utilizada para un
área de dominio




Almacenado
Clave
Monovaluado
Simple
10
Implementación del Módulo de Compras Internacionales Versión: 1.0
en el Sistema Compiere ERP
Modelo de Interfaz
Fecha: 29/12/2011
AD_IMAGE
AD_PROCESS
AD_TABLE
AD_COLUMN
AD_REFERENCE
AD_FIELDGROUP
AD_ORG
AD_CLIENT
AD_ENTITYTYPE
de Compiere.
Es la tabla que
contiene imágenes
que se encuentra
dentro del sistema
asociada a una
pestaña o ventana.
Almacena un proceso
o reporte dentro de la
lógica de Compiere.
Tabla donde se
almacenan las demás
tablas del sistema.
También se incluye
ella misma.
Son el conjunto de
columnas que forman
parte de las tablas de
la base de datos del
sistema.
Contiene las
referencias que se
hacen a los campos
de las pestañas que
hacen validaciones
de los datos.
Tabla que contiene
los grupos de
atributos del sistema.
Conjunto de
organizaciones que
existen dentro de la
compañía de un
Cliente.
Conjunto de Clientes
que forman parte o
existen en la
plataforma de
Compiere.
Esta tabla contiene
las aplicaciones que
componen al sistema,
como el diccionario
aplicativo, las
extensiones que se le
agregan al sistema,
entre otras.
de un negocio.
AD_IMAGE_ID
Identificador de la
imagen o icono.




Almacenado
Clave
Monovaluado
Simple
AD_PROCESS_ID
Identificador de
un proceso o
reporte.




Almacenado
Clave
Monovaluado
Simple
AD_TABLE_ID
Identificador de la
tabla
perteneciente a la
base de datos.




Almacenado
Clave
Monovaluado
Simple
Identificador de la
columna
perteneciente a
una tabla de la
base de datos.
Identificador de la
referencia o
validación que se
aplica sobre
tablas del
sistema.
Identificador de la
agrupación de
campos
determinada.




Almacenado
Clave
Monovaluado
Simple




Almacenado
Clave
Monovaluado
Simple




Almacenado
Clave
Monovaluado
Simple
AD_ORG_ID
Identificador de la
organización
perteneciente a
un cliente.




Almacenado
Clave
Monovaluado
Simple
AD_CLIENT_ID
Identificador del
cliente o
compañía que
pertenece a
Compiere.




Almacenado
Clave
Monovaluado
Simple




Almacenado
Clave
Monovaluado
Simple
AD_COLUMN_ID
AD_REFERENCE_ID
AD_FIELDGROUP_ID
ENTITYTYPE
11
Implementación del Módulo de Compras Internacionales Versión: 1.0
en el Sistema Compiere ERP
Modelo de Interfaz
Fecha: 29/12/2011
3.2. Interrelaciones
Interrelación
contiene
es_de
hace_referencia_a
pertenece_a
pertenece_a_2
pertenece_a_3
pertenece_a_4
pertenece_a_5
Descripción
Una pestaña
contiene varios
campos, es decir,
una AD_TAB
contiene varios
AD_FIELD.
Una ventana de
Compiere puede
es de un color
determinado. En
otras palabras,
una AD_WINDOW
tiene asociado un
AD_COLOR.
Un campo
perteneciente a
una pestaña
puede hacer
referencia a una
validación del
mismo.
Una pestaña
pertenece o está
relacionada a una
organización del
Cliente creado en
Compiere.
Un campo que se
encuentra dentro
de una pestaña
pertenece a una
organización del
Cliente creado en
Compiere.
Una pestaña
pertenece a una
cierta área del
negocio.
Una ventana de
Compiere
pertenece a una
cierta área del
negocio del
Cliente.
Una ventana de
Compiere
pertenece a una
organización de
un Cliente de
Compiere.
Atributos
Descripción de
Atributo
Tipo de
Atributo
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
12
Implementación del Módulo de Compras Internacionales Versión: 1.0
en el Sistema Compiere ERP
Modelo de Interfaz
Fecha: 29/12/2011
posee
se_asocia_a
se_asocia_a_2
se_encuentra_en
se_relaciona
se_relaciona_2
se_relaciona_3
se_relaciona_con
se_relaciona_con
_2
se_relaciona_con
_3
se_relaciona_con
_4
se_transforma_en
tiene
Un campo posee
una referencia a
un grupo de
campos.
Una pestaña
puede tener
asociada una
imagen.
Una imagen se
asocia a una
ventana de
Compiere.
La tabla que
contiene las
demás tablas del
sistema se
encuentra incluida
dentro de ella
misma.
Una pestaña se
relaciona a un tipo
de entidad.
Un campo se
relaciona a un tipo
de entidad.
Una ventana de
Compiere se
relaciona a un tipo
de entidad.
Una pestaña se
relaciona con un
cliente creado en
Compiere.
Una pestaña
puede estar
relacionada con
un proceso.
Un campo se
relaciona con un
cliente creado en
Compiere.
Una ventana se
relaciona con un
cliente
perteneciente a
Compiere.
Una tabla de la
base de datos se
transforma en una
pestaña.
Una ventana tiene
un conjunto de
pestañas
asociadas, es
decir,
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
13
Implementación del Módulo de Compras Internacionales Versión: 1.0
en el Sistema Compiere ERP
Modelo de Interfaz
Fecha: 29/12/2011
tiene_2
tiene_3
AD_WINDOW
posee varios
AD_TAB.
Un campo tiene
relacionado un
conjunto de
columnas.
Una pestaña tiene
relacionado un
conjunto de
columnas.
N/A
N/A
N/A
N/A
N/A
N/A
4. Modelo de Interfaz basado en la estructura de los datos
La arquitectura del ERP Compiere está dirigida por modelos, es decir, es una MDA
(Model-Driven Architecture). Uno de los modelos que se encuentran dentro de la
base de datos de Compiere, es el que se utiliza para poder generar la interfaz con la
cual el usuario del sistema interactúa. A parte de éste modelo hay muchos otros que
el motor transaccional de Compiere usa para realizar diversas operaciones. Esta
estructura de datos que contiene el conjunto de modelos se bautizó con el nombre
de Diccionario Aplicativo de Compiere.
En el párrafo anterior se mencionó el motor transaccional, esto no es más que un
interpretador que se encarga de ejecutar todos aquellos procesos internos del
sistema, siguiendo la estructura de los modelos que están implementados en la base
de datos ó Diccionario Aplicativo. Este procesador de datos tiene como objetivo
generar las pantallas del sistema para que el usuario pueda realizar sus actividades
dentro de la empresa. Cada vez que se desea mostrar una pantalla diferente, el
motor transaccional tiene que traducir los datos almacenados en el modelo de datos
para dicha pantalla, y finalmente ésta es generada de manera satisfactoria.
En el caso del modelo de datos de la interfaz se tienen tres tablas que son clave
para poder elaborar una pantalla del sistema de manera dinámica. La primera es la
tabla para crear lo que es la ventana de manera global, en otras palabras, un
registro de la tabla Ventana representa una pantalla del sistema. En el caso del
proyecto tenemos un registro dedicado para la pantalla de Compras Internacionales.
Una vez que se tiene creada la ventana se le empiezan a asociar lo que son las
pestañas. Éstas ya están asociadas directamente con una tabla de la base de datos
transaccional, es decir, la que tiene los datos de la empresa. Un ejemplo de una
pestaña, sería la de Orden de Compra, donde se muestran los datos referentes a
una orden de compra internacional, y estos a su vez están almacenados en la base
de datos transaccional. Dos aspectos importantes a resaltar sobre las pestañas
serían, primero es el hecho de que una ventana no puede existir sino tiene asociada
al menos una pestaña, o una tabla a nivel de base de dato transaccional, y segundo,
que se puede subordinar una pestaña a otra para modelar las relaciones N:N que
hay entre tablas a nivel de base de datos del módulo que se quiere agregar. Por
último tenemos la tabla de Campos de las pestañas, que no es más que la tabla que
contiene la información de cada uno de los campos que representan las columnas
de una tabla que se encuentra en la base de datos transaccional. Para entender esto
de forma más clara usaremos la pestaña Orden de Compra que se mencionó
14
Implementación del Módulo de Compras Internacionales Versión: 1.0
en el Sistema Compiere ERP
Modelo de Interfaz
Fecha: 29/12/2011
anteriormente. Los campos que se muestran en dicha pestaña como Titular y
Número de Documento están asociados de manera directa con las columnas titular y
número de documento de la tabla Orden de Compra que se encuentra en la base de
datos transaccional, o donde se almacenan los datos internos de la empresa. Estos
datos son los que se muestran por registro en la pestaña Orden de Compra.
Para concluir, tenemos que el motor transaccional de Compiere interpreta un registro
de la tabla Ventana del diccionario aplicativo, luego interpreta cuál es la tabla
asociada con la pestaña que se quiere visualizar, por último muestra los campos de
dicha tabla en pantalla y los datos relacionados a cada uno de sus registros en el
orden en que se hayan configurado en la pantalla. Un ejemplo del resultado de dicha
interpretación realizada por parte del motor transaccional sobre el modelo que se
encuentra dentro del diccionario aplicativo, se muestra en la siguiente figura
relacionada a la ventana de Compras Internacionales.
Ventana
Pestaña
Campo
La relación entre los nombres que están resaltados en naranja con los nombres de
las entidades que muestran en el diagrama entidad relación del modelo de interfaz,
es la que se explica a continuación. La Ventana representa la traducción de la tabla
AD_Window, la Pestaña es la traducción de la tabla AD_Tab, y por último tenemos
al Campo que es la interpretación de los registros que hay en la tabla AD_Field, que
a su vez están directamente relacionados con un registro de AD_Tab. Estas tablas
forman parte del tan mencionado Diccionario Aplicativo, que es el que contiene el
modelo de interfaz, así como otros modelos utilizados en el sistema por Compiere.
15
SUMINDU, S.A
IMPLEMENTACIÓN DEL M
MÓDULO
ÓDULO DE COMPRAS
INTERNACIONALES EN E
EL
L SISTEMA COMPIERE
ERP
Documento de Arquitectura de Software
Versión 1.3
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Historial de Revisiones
Fecha
Versión
Versión:
23/01/2012
Descripción
1.3
Autor
18/12/2011
1.0
Primera versión Documento
Arquitectura de Software.
02/01/2012
1.1
Segunda versión Documento de Jorge Duque
Arquitectura de Software.
21/01/2012
1.2
Tercera versión Documento
Arquitectura de Software.
de Jorge Duque
21/02/2012
1.3
Cuarta versión Documento
Arquitectura de Software.
de Jorge Duque
Confidencial
<Company Name>, 2012
de Jorge Duque
Page 2 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
Documento de Arquitectura del Software
1 Introducción
1.1 Propósito
Este documento se realiza para dar una visión clara de los aspectos más relevantes del
sistema. Esto se logra haciendo un análisis minucioso de las vistas que se cubren en éste
documento, estas son: Vista de Casos de Uso, Vista Lógica y Vista de Datos. En la Vista
de Casos de Uso se presentan un diagrama de los casos de uso, un lista de ellos y los
actores participantes, luego en la Vista Lógica se proporciona el Modelo Conceptual y
Diagrama de Clases y por último, en la Vista de Datos se presentan los diagramas ER
que modelan la Base de Datos y su Diccionario de Datos.
1.2 Alcance
El radio de este documento abarca todo el desarrollo del proyecto. Los distintos
diagramas que se presentan dentro de este artefacto permiten concretar la estructura
interna del sistema, es decir, hacer la correcta implementación tanto de las
funcionalidades, base de datos y la interfaz. Además se va a mostrar cómo van a estar
distribuidos los distintos componentes que hacen posible el funcionamiento del sistema.
Como se dijo anteriormente, se pretende que con este material se logre establecer una
línea guía para el equipo de la gerencia de sistemas.
1.3 Definiciones
Compiere: es una aplicación para negocios de tipo código abierto, ERP y CRM destinada
para las empresas de pequeño y mediano tamaño.
ERE: diagrama de Entidad-Relación Extendido.
ERP: Sistema de Planificación de Recursos Empresariales que integra y maneja gran
parte de los negocios asociados con la producción de una empresa.
Java: es un lenguaje de programación orientado a objetos desarrollado por Sun
Microsystems.
1.4 Vista global
A continuación se presentarán las vistas de forma expandida, se mostrarán los diagramas
pertinentes a cada tipo de vista y se argumentará sobre puntos relevantes como la
representación arquitectónica y las metas y restricciones.
Confidencial
<Company Name>, 2012
Page 3 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
2. Representación Arquitectónica
El sistema está constituido por tres componentes o vistas:
2.1 Vista Lógica: usa como herramienta de lenguaje visual el Diagrama de Clases, donde
se describen los elementos del dominio, en el caso del módulo, que usuarios han creado
las Órdenes de Compra, a que proveedores se les ha hecho las compras, entre otros.
2.2. Vista de Implementación: más orientada hacia el desarrollo que a la comprensión del
sistema en sí, muestra las relaciones entre los archivos y demás elementos de software a
través del diagrama de componentes.
2.3. Vista de Casos de Uso: presenta los escenarios posibles del sistema, muestra las
funcionalidades conjuntamente con los actores que hacen uso de éstas y además ofrece
una noción acerca del flujo que siguen las mismas.
2.4 Vista de Implantación: Describe los métodos de comunicación entre los entes
involucrados en el sistema. Ubica al software dentro del hardware. La interacción consta
de un cliente basado en Java instalado en la computadora del usuario final y de una
conexión de red interna con un servidor Blade IBM, donde se encuentra la base de datos
Oracle que contiene tanto los proveedores, productos y registros de importación, como las
transacciones hechas en el sistema y el usuario que las realizó. La conexión entre el
sistema y la base de datos se realiza con JDBC, que es un API para Java cuyo fin es
permitir el acceso a bases de datos relacionales.
3. Metas
La meta que se plantea con el desarrollo de este proyecto está en sistematizar de la
manera más eficiente para el usuario el proceso de importaciones en Sumindu, S.A, en
todo lo que engloba este proceso, como es, optimizar los productos, proveedores,
usuarios, las solicitudes y las órdenes de compra.
4 Vista de Casos de uso
A continuación se presentan los casos de usos de la implementación del módulo de
compras internacionales, indicando quienes son los actores, su diagrama y una lista de
ellos.
4.1 Resumen de Actores
Los actores son todos aquellos que van a interactuar con el sistema de manera directa, y
son los que van a ejecutar toda funcionalidad que se relacione con un Caso de Uso
específico. A continuación se presenta una síntesis de las características y
responsabilidades que poseen cada uno de estos usuarios.
Confidencial
<Company Name>, 2012
Page 4 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
Actor
Descripción
Responsabilidades
Empleado
del
departamento
Se encarga de realizar las
actividades
referidas
a
las
importaciones requeridas por la
empresa
Encargado
del
Departamento
Se encarga de supervisar
actividades realizadas por
empleados del departamento.
Administrador del
Sistema
Forma parte del equipo de
desarrollo del sistema, o personal
de mantenimiento
y soporte
adiestrado
para
dar
soporte
Compiere.
Tiene como responsabilidades la puesta de
solicitud
de importaciones, órdenes de
compra y el seguimiento de la mercancía.
Debe poder decir el estado de una
importación realizada por la empresa.
Tiene las mismas responsabilidades que los
empleados, más la responsabilidad de
manejar los productos y su creación,
modificación y eliminación. Esto con el fin de
que haya consistencia en los productos y no
hayan duplicados o faltantes.
Dar soporte a la usuarios del Departamento
con el manejo de sus cuentas de usuario,
perfiles y roles. A su vez otorgan los
premisos al usuario dependiendo de su
grado de responsabilidad en Empleado de
Departamento
o
Encargado
de
Departamento
Confidencial
las
los
<Company Name>, 2012
Page 5 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
A continuación se presentan los casos de usos, así como el diagrama de CU:
4.2 Diagrama de Casos de Uso
Confidencial
<Company Name>, 2012
Page 6 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
A continuación una lista de Casos de Uso, Actores y requerimiento funcional asociado:
4.3 Lista de Casos de Uso
Caso de Uso
Actor
Requerimiento Funcional
Asociado
Entrar al Sistema
Empleado del Departamento /
Encargado del Departamento
R1
Salir del Sistema
Empleado del Departamento /
Encargado del Departamento
R2
Gestionar Proveedor
Empleado del Departamento /
Encargado del Departamento
Agregar Proveedor
Empleado del Departamento /
Encargado del Departamento
R3
Importar Proveedor
Empleado del Departamento /
Encargado del Departamento
R4
Modificar Proveedor
Empleado del Departamento /
Encargado del Departamento
R5
Consultar Proveedor
Empleado del Departamento /
Encargado del Departamento
R6
Eliminar Proveedor
Empleado del Departamento /
Encargado del Departamento
R7
Gestionar Usuario
Administrador del Sistema
Crear Usuario
Administrador del Sistema
R8
Modificar Usuario
Administrador del Sistema
R9
Consultar Usuario
Administrador del Sistema
R10
Eliminar Usuario
Administrador del Sistema
R11
Crear Perfil de Usuario
Administrador del Sistema
R12
Modificar Perfil de Usuario
Administrador del Sistema
R13
Eliminar Perfil de Usuario
Administrador del Sistema
R14
Modificar Contraseña
Empleado del Departamento /
Encargado del Departamento
R15
Gestionar Producto
Encargado del Departamento
Agregar Producto
Encargado del Departamento
R16
Importar Producto
Encargado del Departamento
R17
Modificar Producto
Encargado del Departamento
R18
Eliminar Producto
Empleado del Departamento
R19
Consultar Producto
Empleado del Departamento /
Encargado del Departamento
R20
Confidencial
<Company Name>, 2012
Page 7 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
Gestionar Importación
Empleado del Departamento /
Encargado del Departamento
Generar Solicitud de Importación
Empleado del Departamento /
Encargado del Departamento
R21
Imprimir Solicitud de Importación
Empleado del Departamento /
Encargado del Departamento
R22
Agregar Producto a Solicitud de
Importación
Empleado del Departamento /
Encargado del Departamento
R23
Generar Orden de Compra
Internacional
Empleado del Departamento /
Encargado del Departamento
R24
Imprimir Orden de Compra
Internacional
Empleado del Departamento /
Encargado del Departamento
R25
Agregar Producto a la Orden de
Compra Internacional
Empleado del Departamento /
Encargado del Departamento
R26
Gestionar Factura Comercial
Empleado del Departamento /
Encargado del Departamento
Registrar Factura Comercial
Empleado del Departamento /
Encargado del Departamento
R27
Imprimir Factura Comercial
Empleado del Departamento /
Encargado del Departamento
R28
Registrar Seguimiento de Importación
Empleado del Departamento /
Encargado del Departamento
R29
Registrar Requerimientos de
Importación
Empleado del Departamento /
Encargado del Departamento
R30
1.3
5 Vista Lógica
En ésta vista se presentarán las partes del modelo de diseño que son significativas en la
arquitectura del sistema. A continuación se analizará las vistas de clases, funciones y
desarrollo de actividades.
5.1 Vista general
A continuación se presentarán los paquetes de diseño significativos donde se muestra un
modelo conceptual el cual representa una abstracción de alto nivel de los objetos que se
implementaron. Luego se presentará un diagrama de clases con las funciones contenidas
en las distintas clases del sistema y por último los diagramas de secuencia de cada Caso
de Uso.
Confidencial
<Company Name>, 2012
Page 8 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2 Paquetes de diseño significativos arquitectónicamente
5.2.1 Modelo conceptual
Confidencial
<Company Name>, 2012
Page 9 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.2 Diagrama de clases
Confidencial
<Company Name>, 2012
Page 10 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3 Diagramas de secuencia
5.2.3.1 Entrar al Sistema
5.2.3.2 Salir del Sistema
Confidencial
<Company Name>, 2012
Page 11 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.3 Gestionar Proveedor
Confidencial
<Company Name>, 2012
Page 12 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.4 Agregar Proveedor
Confidencial
<Company Name>, 2012
Page 13 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.5 Importar Proveedor
Confidencial
<Company Name>, 2012
Page 14 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.6 Modificar Proveedor
Confidencial
<Company Name>, 2012
Page 15 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.7 Consultar Proveedor
Confidencial
<Company Name>, 2012
Page 16 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.8 Eliminar Proveedor
Confidencial
<Company Name>, 2012
Page 17 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.9 Gestionar Usuario
Confidencial
<Company Name>, 2012
Page 18 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.10 Crear Usuario
Confidencial
<Company Name>, 2012
Page 19 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.11 Modificar Usuario
Confidencial
<Company Name>, 2012
Page 20 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.12 Consultar Usuario
Confidencial
<Company Name>, 2012
Page 21 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.13 Eliminar Usuario
Confidencial
<Company Name>, 2012
Page 22 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.14 Crear Perfil de Usuario
Confidencial
<Company Name>, 2012
Page 23 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.15 Modificar perfil de Usuario
Confidencial
<Company Name>, 2012
Page 24 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.16 Eliminar Perfil de Usuario
Confidencial
<Company Name>, 2012
Page 25 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.17 Modificar Contraseña
Confidencial
<Company Name>, 2012
Page 26 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.18 Gestionar Producto
Confidencial
<Company Name>, 2012
Page 27 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.19 Agregar Producto
Confidencial
<Company Name>, 2012
Page 28 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.20 Importar Producto
Confidencial
<Company Name>, 2012
Page 29 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.21 Modificar Producto
Confidencial
<Company Name>, 2012
Page 30 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.22 Eliminar Producto
Confidencial
<Company Name>, 2012
Page 31 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.23 Consultar Producto
Confidencial
<Company Name>, 2012
Page 32 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.24 Gestionar Importación
Confidencial
<Company Name>, 2012
Page 33 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.25 Generar Solicitud de Importación
Confidencial
<Company Name>, 2012
Page 34 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.26 Imprimir Solicitud de Importación
Confidencial
<Company Name>, 2012
Page 35 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.27 Agregar Producto a Solicitud de Importación
Confidencial
<Company Name>, 2012
Page 36 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.28 Generar Orden de Compra
Confidencial
<Company Name>, 2012
Page 37 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.29 Imprimir Orden de Compra Internacional
Confidencial
<Company Name>, 2012
Page 38 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.30 Agregar Producto a la Orden de Compra Internacional
Confidencial
<Company Name>, 2012
Page 39 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.31 Gestionar Factura Comercial
Confidencial
<Company Name>, 2012
Page 40 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.32 Registrar Factura Comercial
Confidencial
<Company Name>, 2012
Page 41 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.33 Imprimir Factura Comercial
Confidencial
<Company Name>, 2012
Page 42 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.34 Registrar Seguimiento de Importación
Confidencial
<Company Name>, 2012
Page 43 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
5.2.3.35 Registrar Requerimiento de Importación
Confidencial
<Company Name>, 2012
Page 44 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
6. Vista de Datos
A continuación se presenta un diagrama ER que representa un modelo de la base de
datos del módulo de compras Internacionales.
Modelo ER-E. Fuente: Elaboración Propia
Confidencial
<Company Name>, 2012
Page 45 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
6.1 Diccionario de Datos
6.1.1 Entidades:
1. Producto: Describe los productos que maneja el departamento de Compras.
2. Familia Producto: Clase sumaria que engloba a los productos.
3. Detalle: Esta entidad tiene los productos de cada línea de la solicitud y de la orden
de compra.
4. Importación: Es la generalización de la Solicitud de Importación y la Orden de
Compra
5. Usuario: Representa a los usuarios del sistema, es decir los empleados del
Departamento de Compras Internacionales.
6. Orden de compra: Esta entidad representa a los documentos base de la
importación. Contiene todos los datos de la Orden de Compra.
7. Solicitud de importación: Esta entidad representa a los documentos que pueden
crear otros usuarios requiriendo mercancía al departamento con alguna solicitud
particular para cubrir stock o para venta directa
8. Proveedor: Principal socio del negocio en el proceso de Importación. Son los
distribuidores de mercancía a la empresa.
9. Proceso: Generalización de los procesos asociados a la Orden de Compra:
Factura Comercial, Seguimiento de Importación y Requerimientos.
10. Factura comercial: Factura que emite el proveedor y que se registra en la base de
datos para mayor trazabilidad.
11. Seguimiento importación: Esta entidad llevan un registro del avance de la
mercancía luego que sale desde el proveedor hasta que llega a los almacenes de
la empresa
12. Requerimientos: Son los acuerdos a los que llegan el proveedor y la empresa con
respecto a cómo va a ser el envío, tales como puerto de llegada, forma de pago,
entre otros.
6.1.2 Interrelaciones:
1. Pertenece: Esta interrelación asocia a un producto con su familia. Una familia
puede tener muchos productos pero un producto solo una familia.
2. Tiene: Asocia el detalle de la línea de la Solicitud o de la Orden con con los
productos que en hay en cada una de ellas.
3. Contiene: Asocia a la generalización Importación a las líneas de productos que
hay en ellas.
4. Inicia: Asocia la importación al usuario que la creó, de tal manera se tiene un
control de quien genera cada documento del sistema.
5. Genera: Asocia a la Orden de Compra con los procesos que se originan una vez
que una compra es completada.
6. Compra a: Asocia a la Orden de Compra con el proveedor que les esta brindado el
servicio de suministrar la mercancía necesaria.
Confidencial
<Company Name>, 2012
Page 46 of 47
Sumindu S.A.
Módulo de Compras Internacionales para el Sistema Compiere ERP
Documento de Arquitectura del Software
Versión:
23/01/2012
1.3
7 Vista de Implementación
7.1 Diagrama de Componentes
Confidencial
<Company Name>, 2012
Page 47 of 47
PANTALLAS DE MÓDULO DE
COMPRAS INTERNACIONALES EN
COMPIERE ERP
Pantalla Orden de Compra Internacional:
Pantalla Detalle de Orden de Compra
Pantalla Socio de Negocio
Pantalla de Producto
Pantalla de Solicitud de Importación
Pantalla de Seguimiento de Importación
PANTALLAS DE MÓDULO DE
COMPRAS NACIONALES
EN COMPIERE ERP
Pantalla Solicitud de Compra Nacional:
Pantalla de Orden de Compra