software para la gestiÓn de inventarios …
TRANSCRIPT
1
SOFTWARE PARA LA GESTIÓN DE INVENTARIOS DESARROLLADO CON
APEX (ORACLE APPLICATION EXPRESS)
JUAN DAVID PATIÑO PARRA
ANGIE KATERINE ACOSTA QUINTERO
JORGE ANDRÉS RAMÍREZ MORALES
UNIVERSIDAD COOPERATIVA DE COLOMBIA – SEDE IBAGUÉ
MARZO
2017
2 Esta obra está bajo una licencia de Creative
Commons Reconocimiento-NoComercial-CompartirIgual 4.0 Internacional.
SOFTWARE PARA LA GESTIÓN DE INVENTARIOS DESARROLLADO CON
APEX (ORACLE APPLICATION EXPRESS)
JUAN DAVID PATIÑO PARRA
ANGIE KATERINE ACOSTA QUINTERO
JORGE ANDRÉS RAMÍREZ MORALES
Trabajo de grado para optar al título de Ingeniero en Sistemas
ASESORES:
Ing. Carlos Alberto Méndez Reyes
Ing. Jorge Manuel Pacheco Casadiego
Ing. Oscar Camilo Valderrama Riveros
UNIVERSIDAD COOPERATIVA DE COLOMBIA – SEDE IBAGUÉ
MARZO
2017
3
ÍNDICE ÍNDICE ................................................................................................................................... 3
RESUMEN ............................................................................................................................. 5
INTRODUCCIÓN .................................................................................................................. 6
OBJETIVOS ........................................................................................................................... 7
OBJETIVO GENERAL ...................................................................................................... 7
OBJETIVOS ESPECÍFICOS ............................................................................................. 7
MARCO TEÓRICO Y ANÁLISIS DEL MARCO ................................................................ 8
DESARROLLO .................................................................................................................... 10
REQUISITOS ESPECÍFICOS ......................................................................................... 10
Requisitos comunes de las interfaces ............................................................................ 10
REQUERIMIENTOS FUNCIONALES ........................................................................... 11
Requerimientos de actores: ........................................................................................... 11
Requisitos de interfaz: ................................................................................................... 13
REQUERIMIENTOS NO FUNCIONALES .................................................................... 15
Requerimientos de rendimiento: ................................................................................... 15
Seguridad:...................................................................................................................... 15
MODELO CONCEPTUAL ................................................................................................... 16
MODELO FÍSICO ................................................................................................................ 16
INTERFAZ ........................................................................................................................... 19
CONCLUSIONES ................................................................................................................ 25
TRABAJO FUTURO ........................................................................................................... 25
REFERENCIAS ................................................................................................................... 26
4
ÍNDICE DE TABLAS E IMÁGENES
Tabla 1. Requerimiento funcional 1 ..................................................................................... 11
Tabla 2. Requerimiento funcional 2 ..................................................................................... 11
Tabla 3. Requerimiento funcional 3 ..................................................................................... 12
Tabla 4. Requerimiento funcional 4 ..................................................................................... 12
Tabla 5. Requerimiento funcional 5 ..................................................................................... 12
Tabla 6. Requerimiento funcional 6 ..................................................................................... 13
Tabla 7. Requerimiento funcional 7 ..................................................................................... 13
Tabla 8. Requerimiento funcional 8 ..................................................................................... 13
Tabla 9. Requerimiento funcional 9 ..................................................................................... 14
Tabla 10. Requerimiento funcional 10 ................................................................................. 14
Tabla 11. Requerimiento no funcional 1 .............................................................................. 15
Tabla 12. Requerimiento no funcional 2 .............................................................................. 15
Tabla 13. Requerimiento no funcional 3 .............................................................................. 15
Imagen 1. Modelo conceptual .............................................................................................. 17
Imagen 2. Modelo físico ....................................................................................................... 18
Imagen 3. Interfaz de login. .................................................................................................. 19
Imagen 4. Interfaz de entradas de inventario. ....................................................................... 20
Imagen 5. Interfaz de salidas de inventario. ......................................................................... 21
Imagen 6. Interfaz de productos. .......................................................................................... 22
Imagen 7. Interfaz de informe de inventarios. ...................................................................... 23
Imagen 8. Interfaz de bodega. .............................................................................................. 24
5
RESUMEN
El desarrollo de un software amigable que facilite el control y la gestión de los inventarios
de los pequeños establecimientos de la ciudad de Ibagué.
Ha sido desarrollado tras recibir un seminario en administración de bases de datos Oracle
en la Universidad Cooperativa de Colombia – Sede Ibagué.
Está basado a unos modelos de tablas relacionales (Figura 1), de las cuales se genera un
script (conjunto de instrucciones), el cual es nuestro punto de partida para el desarrollo
usando la herramienta APEX (Oracle Application Express).
6
INTRODUCCIÓN
Es el desarrollo un software sencillo, pero funcional, el cual está dirigido a facilitar el
manejo de inventarios de cualquier tipo de negocio. En un principio está planteado para el
manejo de bodegas de un local de comidas, pero su adaptabilidad a los cambios favorece su
uso en distintos enfoques.
Este desarrollo se emprendió a raíz de las falencias observadas en el manejo de los
inventarios en pequeñas empresas de la ciudad de Ibagué – Tolima. Por esta razón se
desarrolla esta propuesta, la cual busca poner fin al uso excesivo de papel, migrar a una forma
más ordenada y segura de almacenar la información y que, con las condiciones globales
actuales, sea amigable con el medio ambiente.
La misma se desarrolla con base a unos modelos de tablas relacionales (Figura 1), de las
cuales se genera un script (conjunto de instrucciones), el cual es nuestro punto de partida para
el desarrollo usando la herramienta APEX (Oracle Application Express). Esta, nos permite
realizar aplicaciones rápidas y funcionales mediante el uso de programación PL/SQL y una
interfaz gráfica bastante amigable.
7
OBJETIVOS
OBJETIVO GENERAL
• Diseñar, desarrollar y proponer una solución alternativa para la gestión de inventarios
en pequeñas empresas de la ciudad de Ibagué- Tolima.
OBJETIVOS ESPECÍFICOS
• Analizar las falencias presentes en la gestión de inventarios de los diferentes negocios
que cuentan con una o más bodegas.
• Operacionalizar una solución de software basada en desarrollos APEX para mejorar
de esta forma la gestión de inventarios de los negocios y pequeñas empresas de la
ciudad de Ibagué.
8
MARCO TEÓRICO Y ANÁLISIS DEL MARCO
En la ciudad de Ibagué encontramos diferentes locales nuevos, habitualmente pequeñas
empresas a las cuales les sería de gran utilidad un software que les permita gestionar sus
inventarios pero que no sea tan robusto ni complejo, sino que, por el contrario, sea simple y
funcional. Es a raíz de este problema (poca capacidad de inversión en software especializado
ya sea por temor al fracaso del negocio o al querer llevar todo de una forma tradicional) que
decidimos ofrecer esta solución más accesible, económica y práctica.
Nuestro software es software de libre uso por cualquier persona la cual cuente con la base de
datos instalada y con la aplicación corriendo. Está disponible para Windows y Linux.
Se trabajó con APEX (Oracle Application Express) y con bloques anónimos en lenguaje
PL/SQL.
Desde un punto de vista más formal se puede definir como stocks a todo conjunto de recursos
útiles que se encuentran en espera de una demanda para su uso. Se dice que son útiles porque
son capaces de satisfacer una necesidad, bien sea una necesidad productiva cuando se refiere
a las materias primas, materiales y productos en proceso, o satisfacer la necesidad del
consumidor cuando se refiere a productos terminados.
En [1] se denomina al inventario como: “El conjunto de recursos o mercancías en buen
estado, que se encuentran almacenados con el objetivo de ser utilizados en un futuro. Estos
recursos pueden ser materiales, equipos, dinero, etcétera”.
En [2] se define a los inventarios como: “Acumulaciones de materias primas, provisiones,
componentes, trabajo en proceso y productos terminados que aparecen en numerosos puntos
a lo largo del canal de producción y de logística de una empresa.
La bibliografía consultada permite establecer una definición generalizada del inventario
como el conjunto de existencias disponibles con el objetivo de satisfacer el proceso
productivo o la demanda de un cliente.
Hasta el momento, en la ciudad de Ibagué, el software más utilizado para la gestión de
inventarios y demás es Syscafe [3], un software desarrollado en la ciudad de Ibagué el cual
cuenta con muchas funcionalidades, entre ellas la gestión de inventarios, sin embargo, hacen
de él un software bastante robusto que solo le permite ser adquirido por grandes empresas en
la ciudad más no por parte de pequeñas empresas (Pymes) y negocios locales.
Existen otros softwares especializados en la gestión de inventarios, desarrollados por casas
de software los cuales son bastante robustos y dado ello, de elevados costos para pequeñas
empresas. Entre ellos encontramos un software desarrollado por NCH Software [4], una casa
desarrolladora con sede en Australia. Ellos ofrecen un software licenciado llamado
“Inventoria”, el cual es habitualmente empleado por medianas y grandes empresas, con
capacidad y necesidad de un software robusto [5].
9
La idea surge a raíz de las múltiples falencias observadas en lo que respecta a llevar un control
y gestión adecuada de los inventarios en las pequeñas empresas (Pymes) y demás locales
pequeños de la ciudad de Ibagué. Por esta razón se decidió diseñar y desarrollar una solución
informática económica, simple y funcional que, mediante una interfaz intuitiva, les permita
a nuestros clientes tener un control actualizado en todo momento, además podrá ser
consultado en cualquier momento por el administrador del sistema.
Ahora bien, hay que ser conscientes de que actualmente en el mercado de software,
específicamente en la gestión de inventarios, se presenta una alta competencia con empresas
con años de experiencia y múltiples casos de éxito. Si comparásemos en este momento a
Syscafe, en su aplicativo de Gestión de Inventarios, nos damos cuenta que estamos en una
gran desventaja en lo que respecta al manejo de inventarios en las grandes empresas en la
ciudad de Ibagué, sin embargo, como nuestro software va dirigido a los pequeños
empresarios y negocios pequeños, tenemos la oportunidad de ingresar al mercado y así,
adquirir experiencia en pro de mejorar y brindar a nuestros clientes mejores versiones del
software, claro está, sin perder lo que nos caracteriza: economía y funcionalidad.
10
DESARROLLO
REQUISITOS ESPECÍFICOS
Requisitos comunes de las interfaces
Interfaces del administrador, developer y usuario:
La interfaz del administrador, developer y usuario consiste en una interfaz plana compuesta
de pestañas, controles de acceso a las diferentes opciones de usuario, listas, reportes y cuadros
de texto. La construcción de la interfaz está destinada y orientada a ser ejecutada de manera
simple e intuitiva.
Interfaces de Hardware:
Se necesita disponer para la ejecución del software un computador con características
mínimas de experiencia optimas de integración. Hoy en día estos parámetros están sujetos a
las exigencias de consumo de recursos de cada lenguaje.
Entre tales características similares tenemos:
Mínimo
o SO: Microsoft Windows 7 / 8 / 10
o Procesador: Quad Core 2.4GHz
o Memoria: 1 GB de RAM
o Gráficos: NVidia GTX 360 o Radeon HD 5970
o DirectX: Versión 11
o Almacenamiento: 2 GB de espacio disponible
o Tarjeta de sonido: DirectX 11 compatible Tarjeta de sonido
Recomendados
o SO: Microsoft Windows 7 / 8 / 10
o Procesador: Intel i3-3220 o AMD FX-6300
o Memoria: 2 GB de RAM
o Gráficos: NVidia GTX 950 ó Radeon RX 460
o DirectX: Versión 11
o Almacenamiento: 2 GB de espacio disponible
o Tarjeta de sonido: DirectX 11 compatible Tarjeta de sonido
11
REQUERIMIENTOS FUNCIONALES
Requerimientos de actores:
Requerimiento Funcional 1
En la tabla 1 se observa el Sistema de identificación de usuarios, administradores o
developers del software.
Tabla 1. Requerimiento funcional 1
Número del requerimiento Rq01
Nombre del requerimiento Identificar de usuario, admin o dev.
Características El usuario deberá estar registrado en la base
de datos para poder acceder al sistema.
Previa clasificación de usuarios tendrá
permisos específicos.
Descripción del requerimiento El sistema confirmará si el usuario está
registrado, en su defecto, el administrador
del sistema deberá dar de alta una nueva
cuenta para el usuario.
Prioridad del requerimiento Alta
Requerimiento Funcional 2
En la tabla 2 se observa el Sistema de validación de usuarios, administradores o developers
del software.
Tabla 2. Requerimiento funcional 2
Número del requerimiento Rq02
Nombre del requerimiento Validar usuario, admin o dev.
Características El sistema valida que el usuario esté
registrado en la base de datos.
Descripción del requerimiento El usuario ingresa sus datos para realizar el
login, el sistema determina si el usuario
existe y es válido en la base de datos.
Prioridad del requerimiento Alta
12
Requerimiento Funcional 3
En la tabla 3 se observa el registro de datos básicos de cada usuario, admin o dev.
Tabla 3. Requerimiento funcional 3
Número del requerimiento Rq03
Nombre del requerimiento Registrar datos básicos de usuarios
Características Registro de datos e información general de
los usuarios del sistema.
Descripción del requerimiento Permite registrar la información básica de
los datos personales de cada usuario.
Prioridad del requerimiento Alta
Requerimiento Funcional 4
En la tabla 4 se observa el registro de productos.
Tabla 4. Requerimiento funcional 4
Número del requerimiento Rq04
Nombre del requerimiento Registro de un nuevo producto en la B. D
Características Creación de un nuevo producto en la B. D
Descripción del requerimiento Permite la creación (registro) de un nuevo
producto, con sus características y
cantidades actuales en stock.
Prioridad del requerimiento Alta
Requerimiento Funcional 5
En la tabla 5 se observa el registro productos y la actualización de los mismos.
Tabla 5. Requerimiento funcional 5
Número del requerimiento Rq05
Nombre del requerimiento Registro de una actualización de un
producto en stock en la B. D
Características Actualización del producto en la B. D
Descripción del requerimiento Permite la actualización de la cantidad en
stock de un producto.
Prioridad del requerimiento Alta
13
Requerimiento Funcional 6
En la tabla 6 se observa el requerimiento asociado al olvido de la contraseña por parte de un
usuario.
Tabla 6. Requerimiento funcional 6
Número del requerimiento Rq06
Nombre del requerimiento Recordar contraseña
Características Renovación de la clave de acceso
Descripción del requerimiento El sistema se encarga de validar datos del
usuario para así asignarle una nueva clave
de acceso. Proceso únicamente realizado
por un administrador.
Prioridad del requerimiento Media
Requerimiento Funcional 7
En la tabla 7 se observa el requerimiento asociado al registro de una nueva bodega.
Tabla 7. Requerimiento funcional 7
Número del requerimiento Rq07
Nombre del requerimiento Registro de una nueva bodega en la B. D
Características Creación de una nueva bodega en la B. D
Descripción del requerimiento Permite la creación (registro) de una nueva
bodega con sus características específicas.
Prioridad del requerimiento Alta
Requisitos de interfaz:
Requerimiento Funcional 8
En la tabla 8 se observan los módulos de la interfaz.
Tabla 8. Requerimiento funcional 8
Número del requerimiento Rq08
Nombre del requerimiento Módulos interfaz
Características Visualización de los módulos
correspondientes.
Descripción del requerimiento Los módulos de la interfaz serán mostrados
u ocultados según el tipo de usuario que
ingrese al sistema.
Prioridad del requerimiento Media
14
Requerimiento Funcional 9
En la tabla 9 se observa el requerimiento asociado a listar los productos existentes en stock.
Tabla 9. Requerimiento funcional 9
Número del requerimiento Rq09
Nombre del requerimiento Listado (reporte) productos en stock
Características Genera un reporte de los productos en stock.
Descripción del requerimiento Visualizar el reporte de los productos
actualmente en stock, con la cantidad del
mismo y la última fecha de modificación.
Prioridad del requerimiento Alta
Requerimiento Funcional 10
En la tabla 10 se observa el requerimiento asociado a la interacción usuario-sistema.
Tabla 10. Requerimiento funcional 10
Número del requerimiento Rq10
Nombre del requerimiento Interacción
Características El usuario deberá interactuar con el sistema
por medio de periféricos de entrada de datos
tales como teclado y mouse.
Descripción del requerimiento Permitir la interacción de los diferentes
actores a través de los periféricos teclado y
mouse del ordenador.
Prioridad del requerimiento Alta
15
REQUERIMIENTOS NO FUNCIONALES
Requerimientos de rendimiento:
En la tabla 11 se observa el requerimiento asociado a la agilidad e integridad en las consultas.
Tabla 11. Requerimiento no funcional 1
Número del requerimiento Rnq01
Nombre del requerimiento Demora en consulta a la B. D
Características ----
Descripción del requerimiento Garantizar que las consultas u otro proceso
no afecten el desempeño en ejecución de la
B.D en interacción con el aplicativo.
Prioridad del requerimiento Alta
Seguridad:
En la tabla 12 se observa el requerimiento de garantizar seguridad de la información en el
sistema.
Tabla 12. Requerimiento no funcional 2
Número del requerimiento Rnq02
Nombre del requerimiento Garantizar integridad de la información en
el sistema.
Características Seguridad e integridad de la información.
Descripción del requerimiento Gestionar la seguridad, encriptación y
mantenimiento de la información mediante
técnicas de seguridad y validación de
usuarios.
Prioridad del requerimiento Alta
En la tabla 13 se observa el requerimiento asociado a los permisos para acceder a la
información.
Tabla 13. Requerimiento no funcional 3
Número del requerimiento Rnq03
Nombre del requerimiento Permisos de acceso a la información.
Características Acceso a los diferentes módulos del
sistema.
Descripción del requerimiento Control de los accesos de los diferentes
usuarios del sistema a las secciones
autorizadas según los roles.
Prioridad del requerimiento Alta
16
MODELO CONCEPTUAL
En la imagen 1 se observa el modelo conceptual de datos, el cual es un diagrama entidad –
relación y su objetivo está orientado a la descripción de las estructuras de datos y a las
restricciones de integridad. En él nos centramos en analizar el problema dado (falencias en
la gestión de inventarios) y, con ellas nos orientamos para representar los elementos que
intervienen en el problema, así como las relaciones entre elementos (entidades).
Este modelo especifica la existencia de 6 entidades (Bodega, producto, unidad de medida,
entrada, salida y mes) y 2 detalles (detalle entrada, detalle salida) y una entidad extra que
cumple la función de evitar la relación muchos a muchos (inventario). La bodega, por
ejemplo, puede almacenar uno o muchos productos en el inventario, pero debe existir como
mínimo 1 bodega donde almacenar y como mínimo 1 producto que almacenar. A su vez
vemos que un producto debe tener como mínimo 1 unidad de medida, pero las unidades de
medida pueden ser asignadas a muchos o a ningún producto. Ahora bien, vemos que la tabla
bodega puede tener 0 o muchas entradas/salidas, pero cada entrada y cada salida debe estar
asignada a una sola bodega. Por ultimo vemos las tablas de detalles, las cuales son
dependientes de la tabla entrada/salida correspondiente.
MODELO FÍSICO
En la imagen 2 se observa el modelo físico de datos, es una estructura de bajo nivel
implementada dentro del propio SGBD (Sistema de Gestión de Bases de Datos) el cual nos
muestra que tabla está relacionada con cual, los atributos y el tipo de dato de cada atributo
en cada entidad, las llaves primarias (ID) y las llaves foráneas.
Es a partir de este modelo que se genera el script con los comandos SQL que serán
cargados en la base de datos para proceder al desarrollo de la aplicación por medio de
APEX.
17
Imagen 1. Modelo conceptual
18
Imagen 2. Modelo físico
19
INTERFAZ
En la imagen 3 encontramos con la interfaz de “Login”, en ella el usuario (admin, developer o user) se conectará al sistema con sus
debidas credenciales.
Imagen 3. Interfaz de login.
20
En la imagen 4 encontramos la pestaña en la que se le permite al usuario seleccionar uno de los múltiples productos que estén
registrados en la base de datos (pueden existir productos con 0 unidades en stock) e indicar la cantidad de producto que ingresa al
negocio (números enteros).
Imagen 4. Interfaz de entradas de inventario.
21
En la imagen 5 encontramos la pestaña en la que se permite al usuario seleccionar uno de los múltiples productos que estén registrados
en la base de datos que ya tengan existencias e indicar la cantidad de producto que sale (gasta o vende) del negocio (números enteros).
Imagen 5. Interfaz de salidas de inventario.
22
En la imagen 6 encontramos la pestaña en la que se permite al usuario ingresar a la base de datos un nuevo producto (en un principio
este tendrá una existencia en stock igual a 0. Para añadir una cantidad respectiva de unidades nos dirigimos a la pestaña “Entradas de
Inventario”). Aquí se selecciona la bodega en la cual se va a almacenar, seguidamente la unidad de medida con la cual entra el
producto, el nombre del mismo, una breve descripción (si lo requiere) y el valor por unidad. Una vez llenos los datos seleccionamos la
opción grabar y el artículo en cuestión se verá reflejado en el reporte de la parte inferior.
Imagen 6. Interfaz de productos.
23
En la imagen 7 nos encontramos con la pestaña en la cual el usuario podrá consultar el reporte actual de existencias en el inventario, en
él, se puede apreciar el nombre del producto, la descripción del mismo, el valor por unidad, la bodega en la cual se encuentra y su
dirección, la cantidad de producto actualmente en inventario y la fecha en la que se modificó la información.
Imagen 7. Interfaz de informe de inventarios.
24
En la imagen 8 encontramos la pestaña en la cual se le permite al usuario gestionar las bodegas con las que cuenta el negocio/empresa.
Aquí puede añadir una nueva bodega y visualizar su correcta adición a la base de datos.
Imagen 8. Interfaz de bodega.
25
CONCLUSIONES
Con base al proceso que llevó el desarrollo de este software para empresas pequeñas, se
puede concluir que:
• Existen otros softwares más robustos, pero de costos más elevados, solo accesibles
a empresas grandes en la ciudad.
• El software requiere actualizaciones a futuro dado que, según el estudio al mercado,
nos encontramos en una gran desventaja frente a softwares más robustos y de más
tiempo en el mercado.
• El software es atractivo para clientes pequeños que estén empezando a llevar el
control de su inventario de una forma sistematizada más no para empresas que
necesiten más funcionalidades de las aquí descritas.
• Los requerimientos de software y hardware mínimos para correr este programa
pueden ser elevados como para ser accesibles a clientes pequeños.
• Una vez realizadas unas pruebas de implementación en locales pequeños de la
comuna 2 de Ibagué, se tiene como conclusión que la interfaz es intuitiva y por ende
simple de manejar.
TRABAJO FUTURO
• A futuro se implementará el software y se harán pruebas de funcionalidad.
• Se colocará la base de datos en un servidor en línea.
• Añadir un registro de actividades, en donde se pueda ver quién y a qué hora realizo
cambios en la base de datos.
• Generar la opción de imprimir informes generales y/o específicos de los
movimientos de la base de datos.
26
REFERENCIAS
• [1] M. BV Álvarez. Modelos económicos matemáticos II. La Habana: Editorial
Félix Varela., 2006, pp.15.
• [2] D Sipper y R Jr. Bulfin. Planeación y control de la producción. México:
McGraw – Hill., 2003, pp. 124.
• [3] Syscafe. (2017, enero) Syscafe. [En línea]. Disponible en:
http://www.syscafe.com.co/
• [4] NCH Software. (2014, abril). Inventoria. [En línea]. Disponible en:
http://www.nchsoftware.com/es/index.htm
• [5] R. V. Alarcón, A. C. Stay & E. G. T. Saybay. (2016, enero). Software libre en
las empresas. [En línea]. Disponible en:
http://www.eumed.net/rev/caribe/2016/01/negocio.html