SGAR : sistema de control de almacenes por radiofrecuencia

SGAR - SISTEMA DE GESTIÓN DE ALMACENES POR RADIOFRECUENCIA Memòria del projecte d'Enginyeria Tècnica en Informàtica de Sistemes realitzat per Valeriano de las Morenas Becerro i dirigit per Marc Talló Sendra Escola Universitària d'Informàtica Sabadell, Juliol de 2009 El/la sotasignant, Marc Talló Sendra, professor/a de l'Escola Universitària d'Informàtica de la UAB, CERTIFICA: Que el treball al que correspon la present memòria ha estat realitzat sota la seva direcció per en Valeriano de las Morenas Becerro I per a que consti firma la present. Sabadell, Juliol de 2009 ------------------------------ Signat: Marc Talló Sendra Resumen Con la crisis mundial por la que estamos pasando, las empresas buscan reducir costes lo máximo posible. Esta reducción, supone en alguno de los casos, seguir utilizando procesos de gestión de almacenes rudimentarios, como por ejemplo los listados impresos en papel, los cuales ofrecen poca fiabilidad y rapidez, y en consecuencia un mal servicio al cliente que se traduce en un declive de las ventas. Por ello es necesario crear un software específico, el cual tenga un coste de desarrollo ínfimo y con el que podamos gestionar perfectamente un almacén. Gracias a este bajo coste de desarrollo del software, podemos invertir más dinero en la implantación de un sistema de radiofrecuencia de mayor prestación, con lo que tenemos un punto más a nuestro favor respecto a otras aplicaciones similares. Además de todos estos aspectos, también se implantará un nuevo sistema de trabajo mediante el uso de etiquetas de bulto y ubicación que constan de un código de barras que será legible mediante los dispositivos móviles. En resumen, este proyecto consiste en el análisis, diseño e implementación de un aplicativo web para gestionar, de una forma rápida y fiable, los procesos que se realizan sobre diversos materiales en un almacén, todo ello bajo un sistema LAMP (Linux, Apache, MySql y Php), el cual ofrece un sinfín de prestaciones y una alta configurabilidad a un coste de adquisición nulo. A continuación, encontraremos el documento donde se refleja todo el desarrollo llevado a cabo para diseñar e implementar la aplicación SGAR. Índice de contenidos 1. Introducción Pág. 1.1 Introducción ........................................................................................... 1 1.2 Descripción del problema ....................................................................... 1 1.3 Objetivos ................................................................................................ 2 1.4 Estado del Arte ...................................................................................... 4 1.5 Motivaciones personales........................................................................ 4 1.6 Organización del documento ................................................................. 5 2. Estudio de Viabilidad 2.1 Introducción ........................................................................................... 6 2.2 Objeto .................................................................................................... 6 2.3 Sistema a realizar .................................................................................. 8 2.4 Planificación del proyecto ...................................................................... 12 2.5 Conclusiones ......................................................................................... 15 3. Marco teórico 3.1 Introducción ........................................................................................... 16 3.2 Lenguajes de programación Web .......................................................... 16 3.3 Servidor Web ......................................................................................... 18 3.4 Bases de datos ...................................................................................... 20 3.5 Sistema de transmisión de datos mediante Radiofrecuencia ................. 22 4. Análisis 4.1 Análisis de requerimientos ..................................................................... 25 4.2 Módulos de la aplicación ........................................................................ 31 4.3 LOPD ..................................................................................................... 37 4.4 Tareas previas al diseño de la aplicación .............................................. 38 5. Diseño 5.1 Arquitectura ............................................................................................ 39 5.2 Estructura de datos ................................................................................ 40 5.3 Consideraciones previas ........................................................................ 46 5.4 Diseño de la interfaz .............................................................................. 48 5.5 Elementos de la interfaz ........................................................................ 50 6. Implementación Pág. 6.1 Conexión a la base de datos .................................................................. 68 6.2 Autentificación y sesiones de usuarios en el sistema ............................ 69 6.3 Estructura base de las páginas .............................................................. 70 6.4 Informes ................................................................................................. 72 6.5 Validación de formularios mediante Javascript ...................................... 74 6.6 Mensajes de ayuda mediante Ajax ........................................................ 75 6.7 Generación de códigos de barras .......................................................... 77 6.8 Hojas de estilo para la impresión ........................................................... 78 7. Pruebas de funcionamiento y testeo 7.1 Pruebas efectuadas ............................................................................... 79 7.2 Posibles ampliaciones ........................................................................... 80 8. Conclusiones 8.1 Conclusiones finales .............................................................................. 82 9. Bibliografía 9.1 Relación de libros consultados .............................................................. 83 9.2 Relación de páginas Web consultadas .................................................. 83 10. Apéndice 10.1 Índice de figuras ................................................................................... 85 Capítulo 1: Introducción SGAR Capítulo 1: Introducción 1.1 Presentación El principal objetivo de este proyecto es el de desarrollar una aplicación para gestionar, de una forma más eficiente, un almacén de dimensiones reducidas. Dicha gestión se divide en 3 partes: entrada de material, salida de material y mantenimiento del almacén. Actualmente, la gran mayoría de empresas, utiliza aplicaciones informáticas para la gestión de su almacén, pero estas no soportan trabajar con radiofrecuencia, lo que implica que los operarios tengan que trabajar con otros soportes, como pueden ser simples hojas de papel. Esto puede provocar errores en los diferentes procedimientos que se realizan, ya que al utilizar este tipo de soporte, al operario no se le impone ningún procedimiento estándar a seguir. Con la aplicación SGAR, esto quedara solventado, ya que se especificaran una serie de procedimientos estándar, que si no se siguen, no se podrá acabar el trabajo asignado. La principal filosofía de esta aplicación es el de etiquetar todos los artículos con códigos de barras y utilizar unos dispositivos portátiles equipados con lectores de códigos de barras que nos aseguren de que realmente estamos tratando con el material correcto. Gracias a este método de trabajo, se ganara en rapidez y fiabilidad, dos aspectos muy importantes para una empresa hoy en día. Todo esto se realizara mediante una aplicación Web, lo que implica que tengamos todos los datos guardados de una forma segura en una base de datos y que podamos gestionar toda esta información de forma clara, ordenada y sencilla. 1.2 Descripción del problema 1.2.1 Estado Actual Los procedimientos que se llevan a cabo actualmente se realizan de la siguiente manera: el encargado de almacén extrae una serie de listados donde se específica el material que entra (en el caso de entrada de material), el que sale (preparación de pedidos) y la relación de materiales a inventariar (mantenimiento almacén). Estos listados se imprimen en papel y se entregan a los diferentes operarios. Los procedimientos son distintos según el tipo de tarea que se realice, tal y como se puede ver a continuación: Entrada de material El operario, con su respectivo listado de material que entra, se desplaza a la zona donde se deposita el material que entra en el almacén (lugar que denominaremos playa de entrada) y va seleccionando materiales y comprobando que estén en el listado. Si el material se encuentra en este listado, se cuenta para comprobar que la cantidad sea la correcta y se ubica en un lugar del almacén que este libre. Una vez realizado esto, se devuelve este listado a otro operario para que introduzca la cantidad y la ubicación de dicho material y así quede registrado en el sistema. Universitat Autònoma de Barcelona 1 Capítulo 1: Introducción SGAR Salida de material El operario, con su respectivo listado de material que se tiene que preparar para su expedición, selecciona un número de pedido y lo comienza a preparar. En dicha preparación, por cada uno de los materiales, se desplaza hasta la ubicación indicada en el listado, coge el material y lo coloca en un/a caja/palet. Una vez preparada la mercancía se le pega una etiqueta que indica los datos del cliente, la dirección de envío y el número de pedido para más tarde depositarlo en la playa de salidas (lugar donde se prepara todos los pedidos para su posterior transporte). Por último el operario responsable de la preparación del pedido, le devuelve el listado a otro operario para que valide la preparación y pueda sacar el albarán de cliente. Mantenimiento de Almacén El operario, con su respectivo listado de material a inventariar, se desplaza a las diferentes ubicaciones indicadas en el listado y recuenta el material que hay en dicha ubicación. Una vez recontado, compara el stock teórico del listado con el stock real e indica la diferencia. Si el operario encuentra cualquier incidencia (como por ejemplo, la ubicación no contiene el material indicado en el listado, no hay nada en dicha ubicación, etc.) lo especifica en el listado para que pueda ser tratada. Cuando acaba, le devuelve el listado a otro operario para que arregle los stocks en el sistema y trate las posibles incidencias. 1.2.2 Diagnóstico Como podemos ver, por cada uno de los procedimientos que se realizan, se necesitan dos operarios, uno que trata con el material y otro para que refleje dichas acciones en el sistema informático. Esto implica que para un único procedimiento se tengan que aplicar el doble de tiempo y de recursos. Además no podemos asegurar que el material tratado sea correcto porque no hay ningún mecanismo que pueda verificarlo, únicamente tenemos la confianza en que el operario que lo haya preparado bien. Esto claramente supone que el sistema es poco fiable, ineficiente, lento, costoso, en definitiva, una relación de malos adjetivos que implican una mala imagen para la empresa. 1.3 Objetivos El principal objetivo de SGAR es principalmente que: se solventen las deficiencias que existen y que se apliquen nuevos procedimientos más eficaces además de optimizar el sistema de trabajo para que con ello reduzcamos considerablemente la cantidad de reclamaciones de clientes y así podamos ofrecer un servicio de mejor calidad. Con estas premisas, implantaremos un sistema basado en radiofrecuencia, una gestión de material mediante códigos de barras y el concepto de “bulto” como unidad de recuento. Universitat Autònoma de Barcelona 2 Capítulo 1: Introducción SGAR Para ello se deberán realizar las siguientes tareas: • Definir nuevos procedimientos de trabajo, utilizando el nuevo concepto de código de bulto + código de barras para cada uno de los artículos existentes en el almacén. • Simplificar el sistema de trabajo de tal forma que un único operario realice todos los procedimientos, evitando así que otro operario tenga que realizar las tareas de introducción de datos en el sistema informático. • Asignar tareas a operarios remotamente, permitiendo el traspaso a otro operario de dicha tarea si el operario inicial no puede acabarla. • Asignar prioridades a las tareas en la asignación a los diferentes operarios. • Realizar un estudio de cobertura inalámbrica lo mas eficiente posible, para utilizar los mínimos dispositivos obteniendo la máxima cobertura. • Realizar una correcta elección de los dispositivos inalámbricos, dispositivos móviles e impresoras de etiquetas de acuerdo con las necesidades que se tengan, optimizando de esta manera el coste total. • Incluir nuevas opciones en las tareas de mantenimiento de almacén, como pueden ser, mover bulto de ubicación, recontar bulto, desmontar bulto e inventario. • Registrar toda la información importante en el tratamiento de un bulto. • Gestionar parámetros básicos del sistema (alta/baja operarios, alta/baja artículos, alta/baja de ubicaciones, etc.) Y como objetivos específicos tenemos: • Diseñar dos interfaces graficas diferentes, una que se utilizara en los dispositivos móviles y la otra en PC’s comunes. • Crear una aplicación sencilla y amigable, con menús de acceso rápido para facilitar la navegación, y con esto conseguir que el aprendizaje de los operarios se reduzca y así el impacto de la implantación sea mínimo. • Alta fiabilidad en la preparación de pedidos, ya que el sistema solicita código de bulto a preparar, lo que nos asegura de que estamos tratando con el material correcto. • Optimización de la aplicación para no sobrecargar los dispositivos móviles, PC’s y servidores. • Describir correctamente los errores generados por el programa para que el operario sepa que debe hacer a continuación. Se especificaran las posibles causas que han generado dicho error y su correspondiente solución. • Aprender a gestionar un sistema que esta implementado bajo las tecnologías PHP, MySql, Apache, Ajax, etc. sobre un servidor con sistema operativo Linux. • Aplicar todos los conocimientos adquiridos a lo largo de la carrera. Universitat Autònoma de Barcelona 3 Capítulo 1: Introducción SGAR 1.4 Estado del Arte Actualmente existen varias aplicaciones que trabajan con radiofrecuencia, pero estas tienen un coste muy elevado que no todas las empresas pueden cubrir. Además si le sumamos que al implantar este tipo de sistema, debemos de formar a todo los usuarios para que se adapten lo más rápido posible, el coste se eleva aun mas. Programas como UBICA, IBS o SISLOG, reconocidos mundialmente, son programas muy eficaces y capaces de trabajar con almacenes de grandes dimensiones, pero incorporan muchas funcionalidades que en un almacén de menor envergadura no se le sacaría todo el rendimiento que ofrecen, además del gasto que supone implantar un sistema de estas características. También cabe destacar que cuando se compra un tipo de programa como este, te comprometes al mantenimiento de este con sus actualizaciones, posibles errores, mantenimiento de hardware, etc., lo que supone un gasto excesivo y una dependencia total de la empresa que nos ofrece el software. Por ello la necesidad de crear un programa más económico y con prestaciones adecuadas a estos almacenes de menor envergadura, sin que aspectos como la fiabilidad o la estabilidad del sistema se vean perjudicados. 1.5 Motivaciones personales La creación de esta aplicación es debido a que, en la empresa donde yo trabajo, existen todas estas deficiencias que implican que no se ofrezca un servicio de calidad y que la reputación de la empresa no sea buena. Debido a esta problemática existente, veo muy interesante realizar un estudio sobre en el campo de la radiofrecuencia y los dispositivos móviles y así poder diseñar una buena aplicación para poder mejor el servicio que se presta. A parte de todo esto, siempre me ha gustado mucho el tema de las páginas Web y la verdad es que nunca me había puesto enserio a diseñar una, exceptuando en las practicas de algunas asignaturas de la carrera, y que mejor oportunidad que en el proyecto de fin de carrera. Además veo como valor añadido el realizar dicha aplicación sobre tecnologías que desconozco, como php, JavaScript, Flash, css, Apache, Ajax y Mysql sobre un sistema operativo que empecé a utilizar hace poco tiempo, Linux. La selección de estas tecnologías viene vinculada a la elección del sistema operativo que he escogido. He podido comprobar personalmente las ventajas y desventajas que ofrece dicho sistema operativo y para mi parecer supera con creces la que me ofrecen otros sistemas. Además de ser un sistema muy estable, más seguro (de momento no se han diseñado virus), mas rápido, lo que supone unos aspecto muy atractivos, es completamente gratuito lo que reduce mucho el coste total del proyecto. Estas son los principales aspectos que me han impulsado a utilizar estas tecnologías sobre este sistema operativo, y si además le añadimos que llevo tiempo haciendo cursos relacionados con esto, que mejor momento para practicar lo aprendido. Universitat Autònoma de Barcelona 4 Capítulo 2: Estudio de Viabilidad SGAR Servidor 1 1195 € 1195 € PC 1 585 € 585 € Dispositivo Motorola MC9090S 5 1232 € 6160 € Antena AP-5131 Motorola 5 426 € 2130 € WS2000 Wireless Switch 1 590 € 590 € Impresora C.B. Zebra Zm400 1 652 € 652 € Material montaje Radiofrecuencia 1 250 € 250 € SUBTOTAL 11.912 € Suma de los costes de software, hardware y margen de beneficio: Coste de desarrollo de la aplicación 4.144 € Coste de hardware utilizado en desarrollo aplic. + Radiofrecuencia 11.912 € SUBTOTAL 16.056 € Margen beneficio 25 % 3.939 € TOTAL 20.070 € 2.3.5 Detalle del presupuesto Aplicación de gestión de almacenes por Radiofrecuencia (SGAR) • Gestión de procedimientos mediante dispositivos móviles. • Asignación de tareas remotamente y mediante cola de prioridad. • Control total sobre actividad de operarios. • Actualización de procedimientos para aumentar rendimiento y efectividad. • Formación a usuarios. Material necesario para la implantación del sistema de Radiofrecuencia • 5 ud dispositivo movil Motorola MC9090S. • 5 ud antena AP-5131 Motorola. • 1 ud WS2000 Wireless Switch. • 1 ud impresora C.B. Zebra Zm400. TOTAL 20.070 € Los precios no incluyen el 16% de IVA Los precios tienen una vigencia de 60 días. Universitat Autònoma de Barcelona 11 Capítulo 2: Estudio de Viabilidad SGAR 2.3.6 Evaluación de riesgos Al ser un proyecto primerizo y de no grandes dimensiones, los principales riesgos que pueden surgir durante el desarrollo de este pueden ser: • El tiempo estimado en que se va a realizar el proyecto no corresponde con el tiempo real en que se ha finalizado. Esto puede ser debido a una mala programación de las fases del proyecto que conllevan un retraso en el desarrollo del sistema. Por tanto, se tendría que dar más margen en las fechas programas para resolver posibles problemas que puedan surgir. • Una vez comience la programación de los módulos sobre un lenguaje no conocido con anterioridad, nos damos cuenta de que este lenguaje seleccionado no proporciona las herramientas necesarias para la realización de este proyecto. Para ello nos aseguraremos de que dicho lenguaje implementa toda la funcionalidad que necesitamos. • Ya que el programa está basado en una aplicación Web, es necesario contemplar la compatibilidad entre los navegadores que se utilizaran. • Otro aspecto importante son los problemas que puedan surgir en la comunicación por radiofrecuencia entre los dispositivos y el servidor. Para ello se deberá estudiar minuciosamente como estructurar esta red para minimizar lo máximo posible estos problemas de transmisión de datos. • Por último, se ha de contemplar la posibilidad de que exista una ampliación del sistema y se aumente el número de terminales móviles conectados, por tanto el sistema tiene que estar preparado para poder acoger más dispositivos sin ningún tipo de problema. 2.3.7 Alternativas Actualmente existen varios programas similares a SGAR, pero todos ellos utilizan unos lenguajes de programación bajo licencia, lo que supone un incremento considerable en el precio final del programa. Esto también supone una total dependencia de la empresa responsable del programa a la hora de realizar cualquier modificación o ampliación de este, y en consecuencia el importe sobre dicha modificación que la empresa cree oportuno. Además, todas estas empresas te obligan a firmar un contrato de mantenimiento, debido a que utilizan hardware específico para su programa. El conjunto de estos parámetros a tener en cuenta a la hora de comprar un tipo de software de estas características, crea la necesidad de desarrollar un software que posea las funcionalidades necesarias para desarrollar el mismo trabajo que los demás programas pero a un precio de mercado más asequible. 2.4 Planificación del proyecto 2.4.1 Duración estimada de las fases del proyecto A continuación se especifica las diferentes fases en que se ha divido el proyecto y el total de horas necesarias para desarrollar cada una de estas: Universitat Autònoma de Barcelona 12 Capítulo 2: Estudio de Viabilidad SGAR Universitat Autònoma de Barcelona 13 Nº Descripción de la fase Duración (h) 1 Estudio de Viabilidad 8 2 Análisis 12 3 Entrevista con los diferentes usuarios 16 4 Aprendizaje de los lenguajes no conocidos 40 5 Diseño de la interface grafica 8 6 Diseño e implementación de la BBDD 8 7 Programación del modulo de entrada de material 24 8 Programación del modulo de salida de material 24 9 Programación del modulo de mantenimiento almacén 24 10 Programación del modulo de informes 24 11 Programación del modulo de parámetros del sistema 24 12 Programación de las interfaces web 16 13 Implantación de módulos sobre las interfaces web 16 14 Pruebas de testeo 8 15 Estudio de cobertura* 16 16 Instalación del sistema 32 17 Pruebas sobre el sistema montado en red 8 18 Corrección de posibles errores 8 19 Elaboración de documentación 24 20 Curso de formación a usuarios 16 TOTAL 356 h *Nota: el estudio de cobertura depende de las dimensiones de cada almacén. El número de horas indicado es estimado. Dicho estudio lo llevara a cabo la empresa que realizara la instalación. Capítulo 2: Estudio de Viabilidad SGAR 2.4.1 Diagrama de Gantt Universitat Autònoma de Barcelona 14 Capítulo 2: Estudio de Viabilidad SGAR 2.5 Conclusiones Al implantar este sistema se obtienen las siguientes mejoras: • Optimización de procedimientos de manipulación de materiales. • Completa organización del almacén mediante la utilización de códigos de barras para producto y para ubicaciones. • Gran simplicidad a la hora de realizar inventarios de artículos. • Efectividad en la recepción/salida de materiales y mantenimiento del almacén debido al control efectuado por el programa. • Asignación remota de tareas a usuarios. • Organización y control sobre los datos almacenados, ya que se encuentran en una base de datos alojada en un servidor, con lo que accedemos de forma inmediata. • Resolución inmediata de posibles incidencias, ya que queda registrado todas las acciones realizadas por un operario en cada manipulación de material. • Formación sobre un método de trabajo más efectivo, rápido y fiable. Universitat Autònoma de Barcelona 15 Capítulo 3: Marco Teórico SGAR Capítulo 3: Marco Teórico 3.1 Introducción A continuación se exponen una serie de conceptos teóricos sobre los cuales se desarrolla este proyecto, los cuales hemos de tener una pequeña noción para poder entender de una forma más concisa, algunos puntos de la memoria. 3.2 Lenguajes de programación Web Actualmente existen diferentes lenguajes de programación para desarrollar páginas Web, estos han ido surgiendo debido a las tendencias y necesidades de las distintas plataformas que existen. A continuación se exponen la relación de lenguajes utilizados en el desarrollo del proyecto, de los cuales se muestran sus ventajas y desventajas. 3.2.1 Lenguaje HTML Desde la expansión de Internet, han sido muchísimos los sitios Web publicados gracias al lenguaje HTML. Es un lenguaje estático para el desarrollo de sitios web (acrónimo en inglés de HyperText Markup Language, en español Lenguaje de Marcas Hipertextuales). Fue desarrollado por el World Wide Web Consortium (W3C). Por convención, los archivos de formato HTML usan la extensión .htm o .html. Ventajas • Se programa mediante marcas de hipertexto, lo que permite Hipervínculos. • El código se presenta de forma clara y estructurada. • Crea archivos de pequeño tamaño, lo que permite una carga rápida. • Lenguaje de aprendizaje fácil. • Lo admiten todos los exploradores. Desventajas • Lenguaje estático. • La interpretación de cada navegador puede ser diferente. • Guarda muchas etiquetas que pueden convertirse en “basura” y dificultan la corrección. • El diseño es más lento. • Las etiquetas son muy limitadas. 3.2.2 Lenguaje JavaScript Se trata de un lenguaje interpretado, con lo que no requiere compilación. Fue creado por Brendan Eich en la empresa Netscape Communications. Se utiliza principalmente en páginas Web. Al igual que Java, JavaScript es un lenguaje orientado a objetos propiamente dicho, ya que dispone de Herencia, si bien esta Universitat Autònoma de Barcelona 16 Capítulo 3: Marco Teórico SGAR se realiza siguiendo el paradigma de programación basada en prototipos, ya que las nuevas clases se generan clonando las clases base (prototipos) y extendiendo su funcionalidad. Actualmente, todos los navegadores interpretan el código JavaScript integrado dentro de las páginas web. Para interactuar con una página web se provee al lenguaje JavaScript de una implementación del DOM (en inglés Document Object Model, en español Modelo de Objetos del Documento). Ventajas • Lenguaje de scripting seguro y fiable. • Los script tienen capacidades limitadas, por razones de seguridad. • El código JavaScript se ejecuta en el cliente. Desventajas • Código visible por cualquier usuario. • El código debe descargarse completamente. • Puede poner en riesgo la seguridad del sitio Web, con el actual problema llamado XSS (significa en inglés Cross Site Scripting renombrado a XSS por su similitud con las hojas de estilo CSS). 3.2.3 Lenguaje PHP Es el lenguaje de programación más utilizado actualmente para la creación de sitios web dinámicos. PHP es un acrónimo recursivo que significa PHP Hypertext Pre-processor, (inicialmente se llamó Personal Home Page). Surgió en 1995, desarrollado por PHP Group. Generalmente se ejecuta en el servidor web, tomando el código en PHP como su entrada y creando páginas web como salida. PHP no necesita ser compilado para ejecutarse además de que puede ser incrustado dentro de código HTML. Para su funcionamiento se necesita tener instalado Apache o IIS con las librerías de PHP. La mayor parte de su sintaxis ha sido tomada de C, Java y Perl con algunas características específicas. Por convención, los archivos en formato PHP usan la extensión .php. Ventajas: • Muy fácil de aprender. • Se caracteriza por ser un lenguaje muy rápido. • Soporta en cierta medida el lenguaje orientado a objetos (clases y herencia). • Es un lenguaje multiplataforma: Linux, Windows, etc. • Capacidad de conexión con la mayoría de los gestores de base de datos: MySql, PostgreSql, Oracle, MS SQL Server, etc. • Capacidad de expandir su potencial utilizando módulos. • Posee de infinidad de documentación detallada. Universitat Autònoma de Barcelona 17 Capítulo 3: Marco Teórico SGAR • Es de código abierto, lo que rebaja los costes de desarrollo. • Incluye gran cantidad de funciones. • No requiere definición de tipos de variables ni manejo detallado del bajo nivel. Desventajas: • Se necesita instalar un servidor Web. • Todo el trabajo lo realiza el servidor y no delega en el cliente. Por lo tanto, puede ser más ineficiente a medida que las solicitudes aumenten en número. • La legibilidad del código puede verse afectada al mezclar sentencias HTML y PHP. • La programación orientada a objetos es aún muy deficiente para aplicaciones grandes. • Dificulta la modularización. • Dificulta la organización por capas de la aplicación. También hemos de comentar que existen otros lenguajes alternativos a este, como puede ser ASP.net, pero al tratarse de un lenguaje privativo y con un alto coste de implantación, nos obligo a descartarlo ya que no cumplía con una de las políticas del programa SGAR, un desarrollo e implantación de bajo coste frente al software de la competencia. 3.3 Servidor Web Un servidor web es un programa que sirve para atender y responder a las diferentes peticiones de los navegadores, proporcionando los recursos que soliciten usando el protocolo HTTP o el protocolo HTTPS (la versión cifrada y autenticada). Un servidor web básico cuenta con un esquema de funcionamiento muy simple, basado en ejecutar infinitamente el siguiente bucle: 1. Espera peticiones en el puerto TCP indicado (el estándar por defecto para HTTP es el 80). 2. Recibe una petición. 3. Busca el recurso. 4. Envía el recurso utilizando la misma conexión por la que recibió petición. 5. Vuelve al segundo punto. Un servidor web que siga el esquema anterior cumplirá todos los requisitos básicos de los servidores HTTP, aunque sólo podrá servir ficheros estáticos. Pero el aspecto que más nos interesa del servidor web, es el nivel de soporte que ofrece para servir contenido dinámico. Puesto que la mayor parte del contenido web que se sirve no viene de páginas estáticas, sino que se genera de forma dinámica, y esta tendencia se mueve claramente al alza, el soporte para contenido de tipo dinámico que ofrece un servidor web es uno de los puntos críticos en la elección. Universitat Autònoma de Barcelona 18 Capítulo 3: Marco Teórico SGAR La mayor parte de los servidores web ofrecen soporte para CGI (se debe recordar que los CGI son el método más antiguo y sencillo para generar contenido dinámico). Otros muchos ofrecen soporte para algunos lenguajes de programación (normalmente lenguajes interpretados) como PHP, JSP, ASP, etc. Es muy recomendable que el servidor web que se utilice proporcione soporte para algunos de estos lenguajes, especialmente PHP, sin tener en cuenta JSP, que normalmente requerirá un software externo para funcionar (como un contenedor de Servlets). Un servidor que ofrece soporte a este tipo de lenguajes es Apache. A continuación se especifican una serie de ventajas que ofrece un servidor Apache: • Apache es una tecnología gratuita de código fuente libre. El hecho de ser gratuita es importante pero no tanto como que se trate de código fuente abierto. • Corre en una multitud plataformas, lo que lo hace prácticamente universal. • Apache es un servidor altamente configurable de diseño modular. Es muy sencillo ampliar las capacidades del servidor. Actualmente existen muchos módulos para Apache que son adaptables a este. Otra cosa importante es que cualquier persona que posea una experiencia en programación de C o Perl puede escribir un modulo para realizar una función determinada. • Apache trabaja con lenguajes Perl, PHP y otros lenguajes de script, como Java y páginas Jsp. Teniendo todo el soporte que se necesita para tener páginas dinámicas. • Apache te permite personalizar la respuesta ante los posibles errores que se puedan dar en el servidor. Es posible configurar Apache para que ejecute un determinado script cuando ocurra un error en concreto. • Tiene una alta configurabilidad en la creación y gestión de logs. Apache permite la creación de ficheros de log a medida del administrador, de este modo se puede tener un mayor control sobre lo que sucede en el servidor. Pero también se ha de comentar que existe una alternativa a dicho servidor, esta alternativa es Microsoft IIS. Dicho servidor nos ofrece las siguientes ventajas e inconvenientes: Ventajas • Fácil de usar • ASP preparado en la instalación por defecto • Soporte ODBC integrado • Configuración gráfica y en línea de comandos Desventajas • Multitud de fallos de seguridad • La mayoría de funcionalidad extra debe ser comprada separadamente • Sólo funciona en Windows NT/2000. Universitat Autònoma de Barcelona 19 Capítulo 3: Marco Teórico SGAR Otro punto a tener en cuenta, es el grado de utilización de cada uno de los servidores a la hora de servir páginas web en Internet. Como podemos observar en el siguiente grafico, apache es el servidor web mas utilizado en el mundo. Un motivo, que nos impulsa a escoger dicho servidor. Fig. 1 - Grado de utilización de servidores web en Internet Dicho grafico se obtenido de un estudio realizado sobre 80 millones de dominios de Internet, dato bastante significativo como para tenerlo en cuenta. En resumen, teniendo en cuanta las ventajas y desventajas que nos ofrecen ambos servidores, la popularidad de cada uno de ellos, que supone una mayor documentación, y también el lenguaje en que programaremos, está claro que el mas óptimo para llevar a cabo este proyecto es Apache. 3.4 Bases de datos Una base de datos es un sistema formado por un conjunto de datos almacenados en discos que permiten el acceso directo a ellos y un conjunto de programas que manipulen ese conjunto de datos. Actualmente, el modelo más utilizado en el diseño de bases de datos es el modelo relacional, el cual se basa en ordenar, de forma lógica, en filas y columnas toda la información almacenada. Entre las principales características de los sistemas de base de datos podemos mencionar: • Independencia lógica y física de los datos. • Redundancia mínima. • Acceso concurrente por parte de múltiples usuarios. • Integridad de los datos. • Consultas complejas optimizadas. • Seguridad de acceso y auditoria. • Respaldo y recuperación. • Acceso a través de lenguajes de programación estándar. Para poder gestionar toda esta información almacenada, se utilizan los Sistemas de gestión de base de datos (en inglés DataBase Management System) que son un tipo de software muy específico, dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan. Se compone de un lenguaje de Universitat Autònoma de Barcelona 20 Capítulo 4: Análisis SGAR Podrá ejercer las siguientes funcionalidades: - Gestión completa de tareas, entrada y salida de material. - Gestión de almacén mediante modulo de mantenimiento de almacén. 4.1.3 Requerimientos no funcionales Tal como hemos definido anteriormente, los requerimientos no funcionales son aquellos que no están vinculados con la funcionalidad interna del sistema. En nuestro caso son: • Interfaz adecuada a cada dispositivo Al trabajar con dispositivos móviles, deberemos adecuar la resolución a dichos dispositivos para una correcta visualización. Además de diseñara con colores suaves para contrarrestar el cansancio visual. Para el ordenador de control se utilizara una resolución de 1024x768 para que la información sea pueda leer de forma rápida ya que si implementamos una resolución mayor, nos tendremos que fijar mas y esto puede agudizar el cansancio visual. • Navegación rápida y clara El programa debe ser fácil de utilizar, ya que si complicamos mucha la navegación, el impacto de implantación para los operarios seria más costoso. Para ello, en el menú principal de operario tan solo se pondrán los accesos que más se utilizaran, y mediante el uso de iconos facilitaremos la interpretación de los diferentes módulos. Deberemos mostrar también, de una forma clara y explícita, cada uno de los errores que se generen para una correcta interpretación. • Estabilidad de la radiofrecuencia Para minimizar el tiempo de recepción de material, preparación de pedidos y mantenimiento de materiales, deberemos de implementar una red de radiofrecuencia con un tiempo de respuesta muy bajo, ya que esto nos ayudara a rebajar el tiempo que emplea cada operario en realizar una operación. Para ello deberos realizar un estudio de cobertura optimo, asegurándonos de que tengamos un nivel de señal optimo en cada rincón del almacén. • Escalabilidad del sistema Debemos de tener en cuenta que la empresa pueda tener un periodo de trabajo mayor de lo habitual y esto nos provoca un incremento en el numero de terminales trabajando con radiofrecuencia y el programa. • Desarrollo en módulos Al programar en módulos independientes, nos facilita la incorporación o modificación de nuevos parámetros o nuevos módulos, minimizando el coste de implantación, además de que si se produce un fallo en uno de ellos, no afectara a los demás módulos. Universitat Autònoma de Barcelona 27 Capítulo 4: Análisis SGAR • Máxima velocidad en el acceso a los datos El acceso de los operarios al programa se realizara mediante una sesión de cliente remoto contra el servidor para minimizar la transferencia de datos entre el dispositivo y el servidor. Con esto conseguimos simplificar muchísimo la configuración de los dispositivos, ya que con un simple programa de Terminal Server pueden trabajar. 4.1.4 Tecnologías seleccionadas para el desarrollo de la aplicación Para el desarrollo de este proyecto, se ha decido utilizar lenguaje HTML y JavaScript para la programación de la Web, php como lenguaje de acceso a la BBDD, MySql como gestor de dicha BBDD y un servidor web basado en Apache. En lo que se refiere a sistemas operativos, se utilizara un sistema Linux Ubuntu LTS para el servidor principal, Windows XP para el ordenador del responsable de almacén y Windows Mobile para los dispositivos móviles. La decisión de utilizar estas tecnologías se basa en el mero hecho de intentar reducir lo máximo posibles los costes globales del desarrollo. El simple hecho de reducir costes, no supone reducir las prestaciones ya que estas tecnologías ofrecen un sinfín de características que nada tienen que envidiar a las tecnologías de pago. 4.1.4.1 Lenguajes de programación Uno de los principales objetivos de este proyecto es, como ya se ha comentado anteriormente, la de desarrollar un software de bajo coste sin perder prestaciones como la estabilidad, velocidad de ejecución, escalabilidad, entre otros. Esto lo conseguimos mediante la implementación de lenguajes como Html en combinación con php, JavaScript y Ajax. Podemos decir que php es el lenguaje que cumple con todas nuestras necesidades. Además este lenguaje nos proporciona, respecto a otros lenguajes similares como puede ser ASP.net, las siguientes ventajas: • Se trata de un lenguaje multiplataforma, con lo que puede trabajar sobre la gran mayoría de sistemas operativos. • Gran compatibilidad con la mayoría de gestores de BBDD actuales. • Posee una gran documentación. • Se trata de software libre, con lo que reducimos costes. • Permite técnicas de programación orienta a objetos. • Permite ampliar su potencial mediante la implementación de módulos externos (extensiones). • Fácil aprendizaje. Como podemos ver, el abanico de ventajas que nos ofrece este lenguaje cumple con las necesidades que se nos presentan, lo que indica que se trata del lenguaje ideal para el desarrollo del proyecto. Universitat Autònoma de Barcelona 28 Capítulo 4: Análisis SGAR Como desventajas podemos decir que php tiene muy pocas, pero cabe destacar que php consume más recursos que otros lenguajes, lo que provoca un lentitud en el acceso a los datos mediante las llamadas y ejecución de funciones. Esto normalmente se agrava sobretodo en paginas colgadas en Internet, pero en nuestro caso será casi inapreciable, ya que se trata de una web alojada en un servidor web de una red interna. 4.1.4.2 Base de datos y Servidor Web La elección del programa gestor de la BBDD va muy ligado con la elección del lenguaje de programación, php, ya que se intenta que la compatibilidad entre ambos sea la mayor posible. El gestor con una mayor compatibilidad con dicho lenguaje, en estos momentos, es sin duda MySql. Pero también hemos de tener en cuenta la compatibilidad entre el programa gestor de la base de datos y el servidor web, ya que mediante la web accederemos a los datos almacenados en la base de datos. Para obtener una máxima compatibilidad utilizaremos un servidor web Apache. La implantación, en un único servidor, de MySql y Apache nos garantiza una máxima compenetración entre ambos, que sin duda notaremos a la hora de trabajar con el programa. La versión que utilizaremos para cada uno de los programas es: - MySql versión 5.0.51 - Apache versión 2.2.8 También se ha tenido en cuenta, la posibilidad de utilizar otro programa gestor de bases de datos como Microsoft SQL Server 2005, PostgreSQL 8, InterBase SMP 2009, entre otros, pero el incremento del coste total que implica la instalación de estos gestores no es compatible con intención de reducir costes del programa SGAR. Se estudio, por último, la posible implantación de Oracle Database 10g Express Edition, ya que al tratarse un gestor gratuito cumple con la condición ya comentada anteriormente, pero las limitaciones que imponen a la hora de gestionar grandes volúmenes de datos, nos obligo a descartarla. En lo que se refiere a las alternativas de servidores web, se miro la posibilidad de instalar un servidor Microsoft IIS 6.0, ya que es gratuito al igual que Apache, pero al no ofrecer las misma prestaciones que Apache se descarto. Apache es mucho más potente y configurable que IIS y además posee un sinfín de información. 4.1.4.3 Sistemas Operativos En lo que se refiere a los sistemas operativos, utilizaremos la distribución Ubuntu 8.04 LTS (nombre en clave “Hardy Heron”) para el servidor, el sistema operativo Microsoft Windows XP Profesional para el ordenador de gestión de tareas y por ultimo Windows Mobile 5 para los dispositivos móviles. Universitat Autònoma de Barcelona 29 Capítulo 4: Análisis SGAR La elección de la versión 8.04 de Ubuntu, viene determinada por la compatibilidad que ofrece este sistema operativo con los programas MySql y Apache. De hecho, con un solo comando podemos instalar los dos programas, ya que esta versión contiene los paquetes para la instalación de dichos programas. Además, se ha de decir, que al implantar un servidor basado en Linux, además de aprender nuevas tecnologías, conseguimos una alta fiabilidad ya que diariamente se revisan y actualizan paquetes que pueden ocasionar algún tipo de problema. Por último se ha de decir que se trata de una versión LTS (Long Term Support), en la que se da soporte durante 3 años y con lo que nos aseguramos una versión suficientemente estable y actualizada como para instalarla en un servidor. Al elegir Windows XP Professional para el ordenador de gestión de tareas, se pensó en que si se instalaba una versión Linux, el usuario tendría una dificultad añadida ya que al no conocer cómo funciona el sistema operativo, debería dedicar un tiempo al aprendizaje de este, lo que supone un incremento del coste total para la empresa y un retraso en la implantación del sistema. Por último, en la elección del sistema operativo para los dispositivos móviles, podemos decir que Windows Mobile 5 es el sistema operativo que llevan todos los dispositivos, o casi todos. De hecho, el dispositivo que se adquirirá para los operarios, lleva instalado Windows Mobile 5, con lo cual no podemos cambiarlo y se tendrá que utilizar este. Podemos decir también que actualmente no hay una gran variedad de sistemas operativos para dispositivos móviles, y las alternativas que hay a Windows Mobile no ofrecen el soporte que ofrece este. Universitat Autònoma de Barcelona 30 Capítulo 4: Análisis SGAR 4.2 Módulos de la aplicación En el siguiente diagrama se muestra el proceso que sigue un material desde que entra al almacén hasta que sale: Entrada material Fig. 2 - Diagrama de flujo de los procesos efectuados sobre los materiales ¿Material correcto? Asignación a operario Devolución a proveedor ¿Material Stock? Ubicar en zona de Stock Ubicación en zona de p edidos ¿Pedido tiene más material? Asignación a operario (salidas) Preparar pedido Generar e imprimir albarán Asignar tarea a operario Asignación a operario ¿Transporte nuestros medios? Preparar cargas Cargar en vehículo Salida material Ubicar en zona de Cargas Asignar tarea a operario Generar e imprimir albarán SI NO NO SI SI NO SI NO Universitat Autònoma de Barcelona 31 Capítulo 4: Análisis SGAR A continuación, se muestra un diagrama con los posibles estados en que pueden encontrarse los materiales: Fig. 3 – Estados posibles de un material 4.2.1 Módulo de entrada de material 1. Asignación de tarea a operario Una vez se hayan introducido los albaranes de compra en el sistema, mediante el programa especifico de la empresa, el encargado de almacén podrá asignar a un usuario determinado una serie de materiales a recontar según la prioridad que crea oportuna. Al entrar a dicha opción, se genera un listado de material a recontar que mediante un check, iremos marcando los material que queremos asignar. Una vez marcados todos los que se quieren, seleccionaremos el operario que realizara la tarea y le asignaremos una prioridad. Una vez asignada la tarea, será visible solamente por el usuario asignado y solo se podrá acceder mediante su sesión. Las tareas se ordenaran según la prioridad de mayor a menor. 2. Recuento de material de entrada Para realizar el recuento de material de entrada, accederemos a dicha opción, y se nos mostrara, mediante un listado, los materiales asignados a nuestro usuario. Estos se mostraran por orden de prioridad y accederemos al recuento de cada uno de ellos mediante la opción de “Ubicar”. Cuando se haya seleccionado uno, aparecerá otra pantalla donde se pide introducir los siguientes datos: - Proveedor y número de albarán del material de entrada. - Descripción de dicho material. - Cantidad teórica, según albarán de entrada, y cantidad física real. - Numero de bulto, si ya existe más material, el sistema rellenara este campo con el numero de bulto correspondiente. - Ubicación donde hay más material y ubicación donde realmente se ubicara el material. - Opción para marcar si la ubicación donde hemos ubicado el material ya no se puede ubicar nada más porque está completa. Preparado Confirmado Ubicado Recepción Universitat Autònoma de Barcelona 32 Capítulo 4: Análisis SGAR Al introducir estos datos y validarlos, se nos ubicara el material y ya estará disponible como stock en el almacén. Una vez ubicado, el material ya no será visible, ni el listado de asignación de tareas ni en el de reasignación. 3. Reasignación de tarea a operario Existe la posibilidad de repartir la carga de trabajo de un operario a otro. Si se observa que la cola de trabajo de un operario no disminuye, por cualquier motivo, mediante la opción de reasignación, podremos traspasar esa tarea a otro operario para que la lleve a cabo. Esta opción es muy similar a la de asignación de tareas, con la diferencia de que se nos muestra el usuario que tiene esa tarea asignada y la prioridad de esta. Una vez seleccionada las tareas a reasignar, indicaremos el nuevo usuario que las llevara a cabo y la prioridad. 4.2.2 Módulo de salida de material 1. Asignación de tarea a operario Una vez se hayan introducido los pedidos de clientes, se mostrara mediante un listado, la relación de pedidos a preparar. El funcionamiento de dicho listado, es muy similar al de asignación de entradas de material con la diferencia de que se muestran materiales que se han de preparar para pedidos. Una vez marcados los pedidos a preparar, mediante el check de “Preparar”, seleccionaremos el operario que realizara la tarea y la prioridad de esta. 2. Preparar pedido Una vez asignados los pedidos a preparar, cada usuario podrá visualizar los que se le han asignado mediante la validación de su sesión. Una vez validada, podrá acceder a la opción de preparar pedido, donde se le mostrara un listado con los pedidos que se le han asignado y en cada uno de ellos el material a preparar. Al lado de cada línea de material le aparecerá un botón “Preparar” y al hacer clic en él, nos remitirá a otra pantalla donde se nos muestra la siguiente información: - Nº de pedido y proveedor del material. - Descripción del material y cantidad a preparar. - Ubicación del material en el almacén y stock disponible. - Numero de bulto del material de stock. - Una casilla donde introduciremos la cantidad que hemos preparado. - Otra casilla donde indicaremos la ubicación donde hemos depositado el material. - Por último, una casilla donde introduciremos el número de bulto del pedido. Una vez introducidos los campos necesarios y que ya hayan sido validados, dicha línea de material pasara a estado de “Preparado”. Hasta que no hayamos acabado todas la líneas de material del pedido asignado, el pedido no estará listo Universitat Autònoma de Barcelona 33 Capítulo 4: Análisis SGAR para que sea recogido o enviado al o por el cliente. Por último, dicho pedido desaparecerá del listado de asignación y reasignación de tareas. 3. Reasignación de tarea a operario Como en el modulo de entradas, también existe la posibilidad de reasignar una tarea de preparación de pedido desde un operario a otro. Para ello, accederemos a dicha opción, donde se nos mostrara un listado con los pedidos asignados a todos los operarios en el cual marcaremos los pedidos a reasignar e indicaremos el nuevo operario y la prioridad. 4.2.3 Módulo de mantenimiento del almacén 1. Recuento de bulto Para poder visualizar el contenido de un bulto, accederemos a esta funcionalidad desde el menú principal e introduciremos el número de bulto el formulario inicial. Una vez introducido y validado en el sistema, nos aparecerá un listado con el contenido de dicho bulto indicándonos si se trata de un bulto de stock o de pedido. En el informe nos aparecerá la siguiente información: - Numero de albarán de entrada o de pedido, según la finalidad del material. - Descripción del material. - Cantidad. - Ubicación. 2. Regulación de stock Teniendo en cuenta de la necesidad de realizar como mínimo una vez al año, un inventario general de almacén, existe la opción de realizar regulaciones de stock de materiales que componen un bulto. Se ha de comentar, que las regulaciones de stock tan solo se pueden realizar sobre material de stock ya que no tendría sentido realizarlo sobre pedidos, ya que ese material no cuenta como stock. Para ello, introduciremos el número de bulto, y nos aparecerá la relación de material que posee dicho bulto. A continuación introduciremos la cantidad real existente para cada línea de material y regularemos uno por uno. 3. Mover bulto Si tenemos la necesidad de mover un bulto de una ubicación a otra, existe la posibilidad de realizarlo mediante la funcionalidad de mover bulto que ofrece el programa. Para ello, deberemos introducir el número de bulto a mover junto con la antigua ubicación y la nueva ubicación y aceptamos para que quede reflejado el movimiento en el sistema. Universitat Autònoma de Barcelona 34 Capítulo 4: Análisis SGAR 4.2.4 Modulo de informes 1. Informe de ubicaciones El primer informe que encontramos, es el informe de ubicaciones. Dicho informe nos ofrece un listado del material que hay en las ubicaciones que hemos filtrado en la selección. Para ello, realizaremos en una pantalla previa al visor de informes una selección de las ubicaciones que queremos filtrar y marcaremos si queremos la opción de “Inventario”. Si marcamos dicha opción, no tendrá en cuenta los materiales que han sido preparados para algún pedido. A continuación nos aparecerá el visor de informes que nos mostrara la siguiente información: - Ubicación, nº de bulto, descripción del material, cantidad y nº de albarán. 2. Informe histórico Para obtener información sobre quién y cuándo un operario preparo o ubico un material, accederemos al informe histórico, en el cual, introduciremos un intervalo de fechas para acotar la selección. Tenemos también la opción de incluir en la consulta las salidas de material que se han realizado sobre esa fecha. Una vez introducida dicha información, el visor de informes nos mostrara la siguiente información: - Fecha en que se realizo la acción, nº de bulto del material, descripción de este, cantidad, ubicación donde se encontraba el material y operario que realizo la operación de entrada o salida dependiendo de si marcamos la opción anteriormente comentada. 3. Informe artículos Por último, podremos realizar una búsqueda por palabra clave de artículo. Al introducir el nombre del artículo, podremos marcar la opción de buscar también en las salidas de material. Una vez introducida la palabra clave, el sistema realizara una búsqueda y mostrara todos los artículos que contienen esa palabra, para más tarde mostrarlo en el visor de informes con la siguiente información: - Ubicación del material, nº de bulto de este, descripción, cantidad y fecha de entrada o de salida, teniendo en cuenta si hemos marcado la opción de tener en cuenta las salidas. 4.2.5 Modulo de parámetros del Sistema 1. Alta y modificación de usuarios El sistema permite crear nuevos usuarios y modificar ciertos parámetros de los ya existentes. Dicha acción tan solo la podrá realizar el encargado de almacén, que será el responsable de gestionar a los usuarios. A la hora de realizar el alta de un usuario se deberán introducir los siguientes datos: Universitat Autònoma de Barcelona 35 Capítulo 4: Análisis SGAR - Nombre y apellidos del operario. - Nombre de usuario para validar la sesión y acceso al programa. - Password de acceso a este. - Cargo que ocupara en la empresa. Por último, a la hora de modificar algún parámetro de usuario, podremos cambiar los campos anteriormente comentados o incluso si se desea dar de baja al usuario de forma indefinida. 2. Alta y modificación de ubicaciones Otro parámetro que podrá modificar o crear el encargado de almacén, son las ubicaciones. Al igual que con los usuarios, se podrán modificar varios parámetros o incluso eliminar la ubicación. A la hora de realizar el alta de una ubicación se deberán introducir los siguientes datos: - Calle, pila y altura de la nueva ubicación. - Familia de productos que almacenara. En cambio, a la hora de realizar alguna modificación, tan solo podremos modificar los campos Familia de productos y Ubicación completa, ya que no tendría sentido modificar la propia ubicación, si fue creada con dichos datos que cumplen un estándar de codificación de ubicaciones. 3. Generar e imprimir códigos de bulto Una de las funcionalidades más importantes del programa es la gestión de las etiquetas de bulto. Dichas etiquetas son uno de los fundamentos en que se basa este sistema de trabajo. Para ello se han diseñado dos funcionalidades que gestionan estas etiquetas. Con la opción de generar bulto, podemos ir generando, conforme vayamos necesitando, números de bultos para que puedan ser utilizados. En la pantalla de generación se muestra el ultimo bulto que se genero y el numero de bultos que queremos generar a partir de este, para que se siga un correcto orden y no se desorden los bultos en la base de datos. Una vez generado los números, podremos imprimir las etiquetas que irán pegadas en palets, ubicaciones, cajas, etc. Para ello, podremos imprimir un rango de etiquetas, desde un número inicial hasta uno final, o imprimir un número en concreto. Al generarse la vista previa, podremos imprimir dichas etiquetas mediante el icono de impresión, el cual nos abrirá el menú de impresión en el cual seleccionaremos la impresora de etiquetas correspondiente. Universitat Autònoma de Barcelona 36 Capítulo 5: Diseño SGAR ref_articulo varchar 10 - Sí Referencia del material de stock descripcion_art varchar 30 - Sí Descripción del material de stock cod_albaran varchar 10 - Sí Código del albarán de entrada codi_proveedor varchar 10 - Sí Código del proveedor del material cantidad decimal - - Sí Cantidad de material en stock tipo_unidad varchar 2 - Sí Tipo de unidad de artículo: UD, M2, LT, KG, etc. ubicacion varchar 10 - Sí Ubicación del material en el almacén usuario_ent varchar 10 - Sí Usuario que realizo la ubicación fecha varchar 10 - Sí Fecha en que se ubico el material hora varchar 5 - Sí Hora en que se ubico el material prioridad varchar 1 - Sí Prioridad asignada para ubicar material Nombre tabla: Pedidos Descripción: Relación de pedidos de clientes Relación con: Artículos, Salida_material y Clientes PK Nombre Tipo Long. Valor Null? Descripción X id integer 11 - No Numero identificador de pedido num_pedido varchar 10 - Sí Numero de pedido de cliente cod_cliente varchar 10 - Sí Código de cliente direccion_cliente varchar 35 - Sí Dirección de entrega al cliente poblacion_cliente varchar 35 - Sí Población de entrega provincia varchar 25 - Sí Provincia de la población pais varchar 25 - Sí País de la dirección de entrega telefono_cliente varchar 9 - Sí Teléfono de contacto ref_articulo varchar 10 - Sí Referencia del articulo deseado cantidad integer 11 - Sí Cantidad de articulo a preparar tipo_unidad varchar 2 - Sí Tipo de unidad de artículo: UD, M2, LT, KG, etc. Universitat Autònoma de Barcelona 43 Capítulo 5: Diseño SGAR fecha_entrega varchar 10 - Sí Fecha estimada de entrega estado varchar 1 0 Sí Indica el estado en que se encuentra el pedido. Valor 0 es pedido no asignado a operario, valor 1 es asignado pero no preparado y valor 2 es preparado. usuario_asig varchar 10 - Sí Usuario asignado a la preparación del pedido prior varchar 1 - Sí Prioridad de la tarea asignada Nombre tabla: Proveedores Descripción: Relación de proveedores de materiales Relación con: Albaranes y Entrada_material PK Nombre Tipo Long. Valor Null? Descripción X codigo varchar 5 - No Código identificador de proveedor nombre varchar 25 - Sí Nombre del proveedor direccion varchar 50 - Sí Dirección fiscal del proveedor poblacion varchar 30 - Sí Población de la dirección fiscal telefono varchar 9 - Sí Teléfono de contacto del proveedor Nombre tabla: Salida_material Descripción: Relación de materiales preparados para pedidos Relación con: Bultos, Usuarios, Ubicaciones, Pedidos y Clientes PK Nombre Tipo Long. Valor Null? Descripción X bulto varchar 10 - No Bulto que identifica el material ref_articulo varchar 10 - No Referencia del material pedido descripcion_art varchar 30 - Sí Descripción del material pedido cantidad integer 11 - Sí Cantidad de material a preparar tipo_unidad varchar 2 - Sí Tipo de unidad de artículo: UD, M2, LT, KG, etc. ubicacion varchar 10 - Sí Ubicación del pedido preparado en el almacén. Universitat Autònoma de Barcelona 44 Capítulo 5: Diseño SGAR cliente varchar 10 - Sí Nombre del cliente del pedido num_pedido varchar 10 - Sí Numero de pedido de cliente usuario_sal varchar 15 - Sí Usuario que realizo la preparación del pedido fecha varchar 10 - Sí Fecha en que se preparo el pedido hora varchar 5 - Sí Hora en que se preparo el pedido prioridad varchar 1 - Sí Prioridad asignada para realizar la tarea de preparar el pedido Nombre tabla: Ubicaciones Descripción: Relación de ubicaciones que existen en el almacén Relación con: Entrada_material y Salida_material PK Nombre Tipo Long. Valor Null? Descripción X calle varchar 4 - No Código de calle del almacén X pila varchar 3 - No Código de pila de la calle X altura varchar 1 - No Código de altura de la pila familia_prod varchar 10 - Sí Familia de productos: cerámica, sanitario, menaje, grifería, ferretería, cementos, etc. completo tinyint 1 - Sí Indica si la ubicación esta completa o no. Valor 0 indica que está vacía y valor 1 indica que esta completa Nombre tabla: Usuarios Descripción: Relación de usuarios dados de alta en la aplicación Relación con: Entrada_material y Salida_material PK Nombre Tipo Long. Valor Null? Descripción X user varchar 15 - No Nombre de usuario para validarse X pass varchar 9 - No Password de usuario para validarse nombre varchar 30 - Sí Nombre del operario o responsable apellidos varchar 30 - Sí Apellidos del operario o responsable cargo varchar 15 - Sí Cargo que ocupa: operario o responsable Universitat Autònoma de Barcelona 45 Capítulo 5: Diseño SGAR 5.3 Consideraciones previas Antes de volcarnos plenamente en el diseño deberemos de tomar un conjunto de decisiones tales como, el árbol de navegación, la estructura de las páginas del aplicativo y la accesibilidad de cada una de estas. A continuación se muestra el árbol de navegación principal para obtener una visión general de las opciones que ofrece el programa. Menú principal Recuento de entradas Ubicar material Reasignación de tareas Preparar pedido Asignación de tareas Preparar pedido ( Línea de material ) Reasignación de tareas Recuento de bulto Mover bulto Regulación de Stock Informe Ubicaciones Informe Histórico Informe Artículos Visor de Informes SGAR Alta usuario Modificar usuario Alta Ubicación Asignación de tareas Gestor correo SGAR Agenda SGAR Generar códigos Vista previa de impresión etiquetas Imprimir etiquetas Modificar Ubicación Fig. 6 - Árbol de navegación Universitat Autònoma de Barcelona 46 Capítulo 5: Diseño SGAR La estructura de las páginas del aplicativo es un punto muy importante ya que hemos de realizar una buena estructuración para poder acceder a cada módulo con el menor número posible de pasos. Para ello, se diseñará de forma que no tengamos que utilizar la barra de desplazamiento, de esta forma el acceso a las opciones será rápido. La estructura se basará en una página central que se distribuirá de la siguiente forma: • En la parte superior, se mostrará el logotipo de la aplicación junto con la fecha y hora actual, además del nombre del usuario que se ha validado y la opción de “cerrar sesión”. También se mostrará unos accesos directos al gestor de correo del programa, a un calendario y si no nos encontramos en la página principal se colocará un acceso a dicha página. Esta parte es común a todas las páginas de la aplicación. • La parte central será diferente en función de donde nos hallemos: o Si nos encontramos en la página principal encontraremos el menú que estará dividido en cinco módulos, estos son: entrada de material, salida de material, informes, parámetros del sistema y mantenimiento del almacén. o Si nos encontramos en cualquier otra página, se mostrará el formulario respectivo a cada opción. En cambio, en el visor de informes la estructura también se basa en una página principal pero en esta, la parte superior es diferente, ya que nos encontramos directamente el resultado del informe junto con las opciones de impresión y un enlace a la página anterior. Esta página está diseñada que para cuando realicemos un impresión tan solo muestre el resultado de la consulta y no se imprima tal y como esta visualizado en el navegador. Esto se consigue mediante la utilización de css específicos para la impresión, de tal forma que únicamente se utilicen en la vista previa del documento. Por otro lado, en la impresión de las etiquetas de bulto no utilizaremos la estructura de página central, ya que ha de seguir un formato en concreto para que la impresora de etiquetas la pueda imprimir correctamente. Se visualizará sobre una página en blanco sin ningún tipo de estructura. Para que la aplicación sea más accesible, deberemos de tener en cuenta que esta aplicación se visualizará en PC’s comunes y en dispositivos móviles. Para ello tendremos en cuenta cada resolución de los diferentes dispositivos donde se visualizará la aplicación: En el PC de gestión la resolución de la pantalla deberá de ser de 1024 x 768 con un mínimo de 16 millones de colores. En cambio, en los dispositivos móviles la resolución deberá de ser de 640 x 240 y 16 millones de colores. Por último, al tratarse de una aplicación que utiliza formularios validados con JavaScript deberemos de tener en cuenta que el navegador, en nuestro caso Mozilla firefox, tenga JavaScript habilitado. Universitat Autònoma de Barcelona 47 Capítulo 5: Diseño SGAR 5.4 Diseño de la interfaz 5.4.1 Estilo de las páginas Para seguir con la tendencia que existe actualmente en el diseño web, se utilizaran hojas de estilo (css) para la apariencia de las páginas de la aplicación. Mediante la utilización de estas hojas de estilo, podremos controlar todo el diseño de la web, parámetros tales como el tipo de fuente, las imágenes que se utilizan, el tamaño de las capas de diseño, el color de estas, la posición en la página web, entre muchísimos más parámetros. Las ventajas que nos ofrece este tipo de diseño son las siguientes: - Separación del contenido y presentación. - Flexibilidad. - Unificación del diseño de las páginas del sitio. - Optimización de los tiempos de carga y de tráfico en el servidor. - Precisión o elasticidad. - Accesibilidad y estructuración. - Limpieza del código fuente. - Compatibilidad y continuidad. - Estandarización frente a especificaciones propietarias. - Permite la diferenciación de estilos para imprimir / visualizar en pantalla. El principal inconveniente de este sistema es, que no todos los navegadores visualizan de la misma forma la hoja de estilo. Pero en nuestro caso no es un problema, ya que tan solo utilizaremos Mozilla Firefox, ya que en Linux no está disponible Internet Explorer. 5.4.2 Colores y fuentes utilizados Los colores y fuentes utilizados deben ofrecer una correcta visualización del contenido. Además nos abstendremos de utilizar colores estridentes para no provocar fatiga visual, ya que al tratarse de un programa que se utilizara durante bastantes horas, colores muy llamativos provocan cansancio visual que a su vez provocaría desconcentración y dolores de cabeza. En lo que se refiere a las fuentes, se decidió utilizar una fuente que fuese clara y lo mas legible posible para una mejor comprensión. Como en Linux existe la posibilidad de instalar fuentes Truetype, se decidió que una fuente que cumpliese estas características y que además fuese considerada fuente de web segura, era sin duda Arial. Otro tema relacionado con las fuentes, era la generación de los códigos de bulto. En principio se pensó en utilizar una fuente que generase códigos EAN13, pero este tipo de códigos a una cierta distancia no son legibles por un lector de código de barras. Para ello, se decidió escoger una fuente que generase un código de mayor tamaño, Code128, el cual sí que es legible a más distancia. Universitat Autònoma de Barcelona 48 Capítulo 5: Diseño SGAR En resumen, utilizaremos los siguientes colores y fuentes para la aplicación: Colores - Como fondo de la aplicación Æ #B0D1F0 - Para los bordes de la tabla del menú principal Æ #BEBEBE - Mensaje de error de validación o generación etiq. Æ #F84040 - Para el borde la opción cerrar sesión Æ #1DA4DB - Para la cabecera del visor de informes Æ #575252 - Para el fondo del visor de informes Æ #FFFFFF Fuentes - Para botones y títulos Æ Arial, 15px en negrita - Para contenido de formularios Æ Arial, 15px - Para accesorios directos del menú principal Æ Arial, 12px - Para contenido de informes Æ Arial, 13px - Para mostrar mensajes de error Æ Arial, 16px en color rojo - Códigos de barras Æ Code128 5.4.3 Imágenes e iconos En lo que se refiere a imágenes e icono deberemos tener las siguientes consideraciones: - Al tratarse de una página web, las imágenes deberán ocupar el mínimo espacio posible. Para ello, utilizaremos imagen con formato JPG y PNG. Las que más utilizaremos serán las PNG ya que son mejores para el tema de las transparencias, y como la aplicación tenemos un fondo en rayas, nos interesa que las imágenes nos muestren dicho fondo y no un fondo en blanco como muestran los formatos JPG. - Utilizaremos una resolución de 48x48 pixeles para los iconos de acceso directo a la agenda, gestor de correo, home y impresión. Para el fondo de cada uno de los módulos del menú principal utilizaremos imágenes con una resolución de 250x180 pixeles exceptuando en el menú de parámetros que utilizaremos una imagen de 582x180 pixeles. El logotipo de la aplicación tendrá una resolución de 144x166 pixeles. Todas las imágenes, excepto el logotipo, provienen del tema de iconos llamado Mashup de Gnome. Todas tienen formato PNG, ya que es el estándar de iconos de Linux. ¾ Todas las imágenes utilizadas las podremos encontrar en la carpeta “images” en el directorio donde se encuentra la web. Universitat Autònoma de Barcelona 49 Capítulo 5: Diseño SGAR 5.5 Elementos de la interfaz A continuación se comentará de una forma más detallada cada una de las dos interfaces que existirán. Se explicara con detalle todas las partes que forman la aplicación, entre ellas los menús, formularios, mensajes de advertencia o error y demás elementos que contienen las páginas que forman el aplicativo. 5.5.1 Interfaz para PC 5.5.1.1 Menú de acceso En esta pantalla nos encontraremos una película de flash y un formulario de validación donde introduciremos el nombre de usuario y password para acceder al menú principal. Una vez introducidos, los datos serán validados en la base de datos, y si son correctos la aplicación nos remitirá al menú principal. Si los datos son incorrectos, nos aparecerá una pantalla mostrando un error de validación donde se nos indica que el usuario o el password introducidos son incorrectos, además de un vínculo a la página de validación. En caso de no recordar ni el usuario ni el password, nos pondremos en contacto con el administrador del sistema para que nos lo facilite. 5.5.1.2 Menú principal En el menú principal nos encontraremos los cinco módulos que componen esta aplicación, tal y como podemos observar en la siguiente imagen: Fig. 7 – Menú principal de la aplicación Universitat Autònoma de Barcelona 50 Capítulo 5: Diseño SGAR Cada uno de los módulos, junto con sus vínculos, nos dará acceso a las diferentes funcionalidades que se explican a continuación. 5.5.1.3 Entradas material Dentro de este módulo nos encontramos tres opciones: recuento de material, asignación a operario y reasignación a operario. Recuento de material Se nos mostrará un listado con los materiales a contar que el responsable de almacén ha asignado a nuestro usuario. Fig. 8 – Listado de materiales a contar por operario Si accedemos a la opción ubicar de cada una de las líneas, esta nos remitirá a un formulario donde se ha auto-rellenado con la información de dicha línea. Fig. 9 – Formulario de ubicación de material Universitat Autònoma de Barcelona 51 Capítulo 5: Diseño SGAR Si no rellenamos ninguno de los campos en blanco, se mostrará un mensaje indicando que campos faltan por rellenar: Fig. 10 – Mensaje de aviso de campos necesarios para ubicar material Como ayuda al usuario, al lado de cada campo hay un icono de ayuda que al poner el puntero del ratón encima nos aparecerá un recuadro, que se ha programado en Ajax, donde se explica de forma detallada, el significado de este campo. Fig. 11 – Mensaje de ayuda de formulario de ubicar material Una vez introducidos y validados todos los datos serán guardados en la base de datos y se nos remitirá de nuevo a la página de recuento de entradas, donde no estará la línea de material que acabamos de ubicar. Si al usuario no se le ha asignado ningún material a recontar, en esta página nos aparecerá un mensaje de advertencia indicándonos que no se han asignado materiales a este usuario y además un vínculo a la página anterior (recuento de entradas). Fig. 12 – Mensaje de aviso de no asignación de tareas de recuento Asignación de tareas En esta página nos aparecerá un listado de los materiales que han sido introducidos mediante un albarán de entrada. Para asignar tareas a un operario, seleccionaremos cada línea de material deseada e indicaremos a que usuario se le va asignar y con qué prioridad. Universitat Autònoma de Barcelona 52 Capítulo 5: Diseño SGAR solicitada desde cada uno de los diferentes informes, junto con un icono de impresión y un botón para volver a la página de informe desde donde se ha solicitado la información. Fig. 27 – Visor de informes Si los parámetros enviados por algún informe, no existen en la base de datos o son incorrectos, se mostrara un mensaje de error indicando el fallo ocurrido. Fig. 28 – Error al generar la vista de informe 5.5.1.6 Mantenimiento almacén Dentro de este módulo nos encontramos tres opciones: recuento de bulto, mover bulto y regulación de stock. Recuento de bulto Encontraremos un pequeño formulario donde deberemos introducir el número de bulto para visualizar su contenido. Una vez introducido este número de bulto, el sistema nos mostrará mediante un pequeño listado ubicado en la parte inferior de este formulario, con la relación de material que contiene este número de bulto. Universitat Autònoma de Barcelona 59 Capítulo 5: Diseño SGAR Fig. 29 – Formulario y listado de recuento de bulto Si en el formulario no introducimos ningún número de bulto, el sistema nos mostrará un mensaje de advertencia indicándonos el error producido. Fig. 30 – Mensaje de advertencia en recuento de bulto Mover bulto Se nos mostrara un formulario donde deberemos introducir la información necesaria para llevar a cabo el movimiento de bulto. Un vez introducida, el sistema nos imprimirá en la misma página un mensaje donde indicara si se ha producido correctamente o ha habido algún error en el movimiento de bulto. Fig. 31 – Formulario de movimiento de bulto Si en el formulario no introducimos ningún algún parámetro necesario, el sistema nos mostrará un mensaje de advertencia indicándonos los campos que faltan por introducir para que se realice el movimiento Universitat Autònoma de Barcelona 60 Capítulo 5: Diseño SGAR Fig. 32 – Mensaje de error por falta de parámetros en mover bulto Regulación de stock En esta opción encontraremos, al igual que en la opción de recuento de bulto, un pequeño formulario donde deberemos introducir el numero de bulto al que deseamos realizar una regularización de stock. Una vez introducido y validado el bulto, se nos mostrara un listado con la relación de material de este, y en cada una de las líneas de material aparecerá un campo con la cantidad de material que consta en la base de datos. Es en este campo, donde introduciremos la cantidad de material que hemos contado en inventario, y una vez introducido podremos actualizar dicha cantidad mediante el botón “regular”. Fig. 33 – Regularizaciones de stock Al igual que en las demás opciones, si no introducimos un numero de bulto, el sistema nos mostrara una pantalla de advertencia indicándonos de la falta de esta información. Además, si el bulto no existe en la BBDD o ya ha sido regulado, se nos mostrara en la misma página un mensaje de error. Fig. 34 – Mensaje de advertencia en regulación de stock Universitat Autònoma de Barcelona 61 Capítulo 5: Diseño SGAR Fig. 35 – Mensaje de error en regulación de stock 5.5.1.7 Parámetros del sistema Dentro de este módulo nos encontramos seis opciones: alta usuario, modificar usuario, alta ubicación, modificar ubicación, generar códigos e imprimir etiqueta. Alta usuario Consta de un formulario que deberemos rellenar para dar de alta al nuevo usuario en el sistema. Una vez introducidos todos los datos, el sistema validara esta información y la insertara en la base de datos. Fig. 36 – Formulario de alta de nuevo usuario Como en los demás formularios, si no introducimos algún campo necesario, el sistema nos mostrara un mensaje de advertencia indicándonos que campos faltan por introducir. Fig. 37 – Mensaje de advertencia de formulario alta usuario Universitat Autònoma de Barcelona 62 Capítulo 5: Diseño SGAR Si el usuario y password introducidos ya existen en la base datos, el programa mostrara en la misma pantalla un mensaje indicando el error. Fig. 38 – Mensaje de error en el formulario alta usuario Modificar usuario Consta de un selector de usuarios dados de alta en el sistema, donde escogeremos uno y aceptaremos. Una vez seleccionado, nos aparecerá el mismo formulario de altas de usuario, pero con los campos rellenados con la información del usuario seleccionado anteriormente. Fig. 39 – Selección de usuario y modificación de parámetros Como en los demás formularios, si no introducimos algún campo necesario, el sistema nos mostrara un mensaje de advertencia indicándonos que campos faltan por introducir. Fig. 40 – Mensaje de advertencia de formulario modificar usuario Alta ubicación Consta de un formulario que deberemos rellenar para dar de alta la nueva ubicación en el sistema. Una vez introducidos todos los datos, el sistema validara esta información y la insertara en la base de datos. Universitat Autònoma de Barcelona 63 Capítulo 5: Diseño SGAR Fig. 41 – Formulario de alta de nueva ubicación Como en los demás formularios, si no introducimos algún campo necesario, el sistema nos mostrara un mensaje de advertencia indicándonos que campos faltan por introducir. Fig. 42 – Mensaje de advertencia de formulario alta ubicación Si calle, pila y altura introducidas ya existen en la base datos, el programa mostrara en la misma pantalla un mensaje indicando el error. Fig. 43 – Mensaje de error en el formulario alta ubicación Modificar ubicación Al igual que en la modificación de usuarios, consta de un selector de ubicaciones dadas de alta en el sistema, donde escogeremos una y aceptaremos. Una vez seleccionada, nos aparecerá el mismo formulario de altas de ubicación, pero con los campos rellenados con la información de la ubicación seleccionada anteriormente. Universitat Autònoma de Barcelona 64 Capítulo 5: Diseño SGAR Fig. 44 – Selección de ubicación y modificación de parámetros Como en los demás formularios, si no introducimos algún campo necesario, el sistema nos mostrara un mensaje de advertencia indicándonos que campos faltan por introducir. Fig. 45 – Mensaje de advertencia de formulario modificar ubicación Generar códigos Consta de un pequeño formulario donde indicaremos el número de bultos que deseamos generar. Al generarse, el sistema nos informara que como ha ido el proceso. Fig. 46 – Formulario de generación de bultos Si no introducimos el numero de bulto que deseamos generar, el nos mostrara un mensaje de advertencia indicándonos de que falta por introducir este campo. Universitat Autònoma de Barcelona 65 Capítulo 5: Diseño SGAR Fig. 47 – Mensaje de advertencia de formulario generar códigos Al generarse los códigos correctamente, el sistema nos informara mediante un mensaje en esta misma página Fig. 48 – Mensaje de generación códigos de formulario generar códigos Imprimir etiqueta Consta de un formulario donde deberemos introducir el intervalo de bultos o un único bulto que queramos imprimir. Una vez introducido, el sistema validara la información introducida y si es correcta nos remitirá a una página en blanco con la relación de bultos que hemos solicitado. Para poder imprimir este bulto, seleccionaremos un formato de página adecuado al tamaño de la etiqueta de impresión ya guardado en el sistema. Fig. 49 – Formulario de impresión de etiquetas Fig. 50 – Vista de impresión de números de bulto Si no introducimos el numero de bulto que deseamos generar, el nos mostrara un mensaje de advertencia indicándonos de que falta por introducir este campo. Universitat Autònoma de Barcelona 66 Capítulo 5: Diseño SGAR Universitat Autònoma de Barcelona 67 Fig. 51 – Mensaje de advertencia de formulario impresión etiquetas Si el número de bulto introducido no existe en la base de datos, el sistema informara de ello mediante un mensaje con un fondo en color rojo, indicándonos la incidencia. También nos mostrara un link hacia la página anterior. Fig. 52 – Mensaje de error en formulario impresión etiquetas 5.5.2 Interfaz para dispositivo móvil El diseño para los dispositivos es igual que el diseño para PC, con la diferencia que se ha tenido que adaptar para que se pueda visualizar correctamente en las pantallas, con una resolución más pequeña, de los dispositivos móviles. Otra diferencia, es que esta interfaz no tendrá acceso a todos los módulos que ofrece el programa, tan solo tendrá acceso a recuento de entradas, preparar pedido, recuento de bulto, mover bulto ubicación y regulación de stock. También se ha simplificado bastante el menú principal para que resulte los más fácil de utilizar y lo mas intuitivo posible para los operarios. Se ha extraído elementos como la hora, fecha actual y los accesos a la agenda y al gestor de correo. Se ha utilizado un estilo muy simple con un fondo con rayas en diagonal y no se han utilizado demasiadas imágenes para no sobrecargar la red de radiofrecuencia. Cabe destacar, que tal y como se ha diseñado la interfaz, es capaz de adecuarse a muchos tipos de resolución, ya que tan solo basta adecuar el tamaño de la ventana del navegador, y los contenidos de las paginas se centran a este tamaño. Capítulo 6: Implementación SGAR Capítulo 6: Implementación 6.1 Conexión a la base de datos Para realizar la conexión con la base de datos y no tener que ir introduciendo el código php que realiza esta conexión en cada una de las funciones, se ha implementado un archivo php externo donde pondremos el código que realiza la conexión. Para ir llamando a esta función que realiza la conexión cada vez que la necesitemos, pondremos al inicio del script php un include del archivo externo y luego llamaremos a la función conect_bd() para realizar la conexión con la base de datos A continuación se muestra el archivo externo de conexión, el include que se realiza de este archivo y la llamada a la función de conexión: <?//Declaración de función del archivo de conexión function conect_bd(){ //Declaración las variables que se utilizaran $direccion = 'localhost'; $usuario = 'root'; $password = 'vmb'; //Nos conectamos a la BBDD $db = mysql_connect($direccion, $usuario, $password); // Comprobamos la conexión con el servidor if (!$db) { echo 'Error al intentar conectarse con el servidor MySQL'; exit(); } // Comprobamos la conexión con la BBDD en el servidor if (!mysql_select_db("BBDD",$db)) { echo 'No se pudo conectar correctamente con la Base de datos'; exit(); } return $db; } ?> <? include ("conexion.php"); // Incluimos el archive php externo de conexión //Declaramos la función Listar ubicaciones function list_ubic() { $db=conect_bd(); //Llamamos a la función para conectar con la BBDD $qry = mysql_query("SELECT codificacion FROM `ubicaciones`"); echo ("<table align=\"center\"><tr><td><div align=\"right\" class=\"Estilo2\">Ubicacion: </div></td> <td><select name=\"ubic\" id=\"ubic\"><option value = \"1\"></option>"); while($row = mysql_fetch_array($qry)) { echo ("<option value = \"$row[0]\">$row[0]</option>"); } echo ("</select></tr>"); } ?> Universitat Autònoma de Barcelona 68 Capítulo 6: Implementación SGAR 6.6 Mensajes de ayuda mediante Ajax Como ayuda a los usuarios de sistema, se ha implementado unos iconos de ayuda en los formularios de recuento de entradas y preparación de pedidos, para facilitar la compresión de los campos de dichos formularios. A continuación se muestra el código Javascript y el archivo css que se ha implementado para llevar a cabo esta funcionalidad: onload=function() // Al iniciar la pagina { // Accedemos a los objetos y obtenemos la información de cada uno de ellos cAyuda=document.getElementById("mensajesAyuda"); cNombre=document.getElementById("ayudaTitulo"); cTex=document.getElementById("ayudaTexto"); divTransparente=document.getElementById("transparencia"); divMensaje=document.getElementById("transparenciaMensaje"); // Creamos una array donde almacenamos los distintos mensajes que existen ayuda=new Array(); ayuda["Descripcion"]="Descripción del material a contar"; ayuda["Cantidad Teorica"]="Cantidad teórica que tendría que haber físicamente"; ayuda["Cantidad Real"]="Cantidad real recontada"; ayuda["Ubicacion Propuesta"]="Ubicación propuesta por el sistema"; ayuda["Ubicacion Real"]="Ubicación donde se deposita realmente el material"; ayuda["Ubicacion Propuesta"]="Ubicación propuesta por el sistema, donde hay material de la misma familia"; ayuda["Bulto"]="Numero de bulto que identifica dicho material"; ayuda["Ubicacion Completa"]="Indica si en la ubicación caben más bultos"; ayuda["Ubicacion Depositada"]="Indicar en que ubicación se deposita el bulto preparado"; ayuda["Cantidad Preparada"]="Introducir la cantidad de material que se ha preparado"; ayuda["Confirmacion Bulto"]="Comprobar que el bulto donde se ha extraído material es el correcto"; ayuda["Bulto Pedido"]="Introducir el numero de bulto de preparación de pedido"; } // Declaramos la función que genera un nuevo objeto Ajax function nuevoAjax() { var xmlhttp=false; // Creamos el objeto para el navegador xmlhttp=new ActiveXObject("Msxml2.XMLHTTP"); if (!xmlhttp && typeof XMLHttpRequest!="undefined") { xmlhttp=new XMLHttpRequest(); } return xmlhttp; } // Función que coloca el cuadro de texto con la ayuda en la pagina function colocaAyuda(event) { //Declaramos las variables coordenadas que utilizaremos var corX=event.clientX+window.scrollX; var corY=event.clientY+window.scrollY; // Asigamos las coordenadas X e Y donde se colocara el cuadro de texto con la ayudacAyuda.style.top=corY+20+"px"; cAyuda.style.left=corX+15+"px";} document.removeEventListener("mouseout", ocultaAyuda, true); } Universitat Autònoma de Barcelona 75 Capítulo 6: Implementación SGAR // Función que oculta el mensaje de ayuda function ocultaAyuda() { // Ocultamos el cuadro de texto con la ayuda cAyuda.style.display="none"; // Eliminamos los eventos mousemove y mouseout document.removeEventListener("mousemove", colocaAyuda, true); document.removeEventListener("mouseout", ocultaAyuda, true); } // Función que muestra el mensaje de ayuda function muestraAyuda(event, campo) { // Obtenemos las coordenadas de la funcion colocaAyuda colocaAyuda(event); // Añadimos los eventos mousemove y mouseout document.addEventListener("mousemove", colocaAyuda, true); document.addEventListener("mouseout", ocultaAyuda, true); // Mostramos el cuadro de texto cNombre.innerHTML=campo; cTex.innerHTML=ayuda[campo]; cAyuda.style.display="block"; } Cabe destacar que este código tan solo funciona bajo todos los navegadores excepto Internet Explorer, que utiliza otras funciones. Como la aplicación solo trabajara sobre Firefox, se ha desestimado la opción de programar para IExplorer. No se descarta, que si en un futuro hiciese falta, se podría añadir las funciones necesarias para poder visualizar este código Ajax en Explorer. A continuación el código css utilizado para visualizar los mensajes de ayuda: position:absolute; top:0px; left:0px; display:none; text-align:center; } #ayudaTitulo { background-color:#000000; color:#FFFFFF; padding:1px; } #ayudaTexto { vertical-align:middle; padding:2px; } .ayuda { width:50px; text-align:center; } #transparencia { background-color:#FFFFFF; position:absolute; width:400px; height:260px; display:none; opacity:0.95; filter:alpha(opacity="95"); } #mensajesAyuda { width:150px; font-family: Arial; font-size:10px; border:1px solid #000000; Universitat Autònoma de Barcelona 76 Capítulo 6: Implementación SGAR 6.7 Generación de códigos de barras La generación de códigos de barra, ha supuesto varias dificultades en su diseño, ya que el simple hecho de generarlo y visualizarlo en un navegador, hay que añadirle que se está trabajando sobre un entorno Linux, el cual no ofrece muchas alternativas sobre este tema. De las pocas alternativas que se ofrecen, se ha escogido la implementación del modulo php-image-barcode de Ubuntu 8.04. Este modulo ofrece la posibilidad de trabajar con 4 tipos de códigos de barras, entre los que esta Code128, que es el formato que utilizaremos. No explicaremos el funcionamiento del archivo php que genera la imagen, ya que es bastante complejo y nos llevaría demasiado tiempo. Lo que si se explicara es como hemos implementado este modulo en la aplicación y como generamos y obtenemos la imagen del código de barras. Para ello iremos mostrando el código que se utiliza para cada paso: 1. Generar de los códigos en la base de datos function gener_bultos() // Función que genera los bultos a partir del formulario { //Conectamos con la BBDD $db=co nect_bd(); //Declaramos las variables que utilizaremos $ult_bult = $_POST['ult_bult']; $generar = $_POST['bult_gen']; $fin=$ult_bult+$generar; if($generar != '') { //Generamos e insertamos en la tabla bultos los nuevos códigos de bulto for($i=($ult_bult+1);$i<($fin+1);$i++) { $ins = mysql_query("INSERT INTO `bultos` (num_bulto) VALUES ('$i')");} echo ("<table align=\"center\"><tr><td>Los bultos se han creado correctamente!<br><br></td></tr></table>") } //Cerramos la conexión con la BBDD mysql_close($db); } 2. Generar la imagen del código de barras <? // Declaramos las variables que utilizaremos $num = $_GET['num']; //Llamamos a la función que genera los códigos de barras require_once("../../../../usr/share/php/Image/Barcode.php"); //Creamos una imagen nueva $bc = new Image_Barcode; //Dibujamos el código a partir de los valores introducidos en el formulario $bc-> draw($num,'png'); //Pasamos la imagen generada para poder ser visualizada Header("Content-type: image/png"); ?> Universitat Autònoma de Barcelona 77 Capítulo 6: Implementación SGAR Universitat Autònoma de Barcelona 78 3. Visualizar el código de barras en el navegador para la impresión <? session_start(); if($_SESSION["user"]=='') { header ("Location: ../../index.php"); } echo '<?xml version="1.0" encoding="iso-8859-1"?>';?><!DOCTYPE html PUBLIC "- //W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es" lang="es"> <head> <? include('../../php/functions.php'); ?> <title>IMPRESION BULTOS</title> </head> <body> <? comp_bultos(); imp_bultos(); ?> </script> </body> </html> 6.8 Hojas de estilo para la impresión de informes y dispositivos móviles A parte de las hojas de estilo utilizadas para la web, se han implementado css para la impresión de informes y para la visualización del aplicativo en los dispositivos móviles. La hoja de estilo que se utiliza para la visualización de la aplicación en los dispositivos móviles, es muy similar a la hoja de estilo del diseño para PC. El único cambio relevante es que se han eliminado algunas capas y las demás se han adaptado para que se visualicen correctamente. En cambio, la hoja de estilo utilizada para la impresión de informes, sí que es distinta a las demás, ya que se introducen conceptos de ocultación de capas para que, a la hora de imprimir, no se imprima todo lo que se ve en la pantalla. Para ello hemos tenido que añadir un nuevo campo, llamado media, en la llamada a la hoja de estilo que realizamos en el código de Html. Si a este campo le asignamos el valor Print, el navegador interpreta que esa hoja de estilo se utilizara para la imprimir capas de la interfaz que se visualiza. Una vez ya se ha definido en el código Html que tipo de hoja de estilo utilizaremos, crearemos un nuevo archivo css, donde codificaremos las capas de esta hoja de estilo con el mismo nombre de las capas que hay en el css que visualiza la aplicación en la pantalla. En este archivo iremos marcando, con la opción display: none las capas que queremos que no se impriman. Una vez seleccionadas las capas que queremos que se impriman y las que nos, si realizamos una vista previa de impresión, podemos ver que los campo que hay marcados con la opción display: none, no se visualizaran Este no es la única opción que nos permite este tipo de hojas de estilo, ya que si lo deseamos, podemos cambiar el tamaño y tipo de letra, la distribución de la capas, etc., tal y como se ha implementado en la hoja de estilo con nombre style_imp.css, que podemos encontrar en la carpeta css del directorio principal de la aplicación. Capítulo 7: Pruebas de funcionamiento y testeo SGAR Capítulo 7: Pruebas de funcionamiento y testeo 7.1 Pruebas efectuadas Durante las distintas fases del desarrollo se han ido efectuando diferentes pruebas de funcionamiento sobre la aplicación, y al finalizar toda la programación, se ha realizado una prueba más completa y exhaustiva comprobando la integración entre los módulos y su correcto funcionamiento global. Al finalizar la programación de cada modulo, se realizaron diferentes pruebas para comprobar que dicho modulo se integraba correctamente en el aplicativo final, así factores como su acceso y tratamiento de la información de la base de datos o el control de los datos introducidos por los usuarios. Realizando estos procedimientos, nos aseguramos de que cada modulo que se integraba, funcionaba correctamente y esto nos aseguraba que en la prueba final no hubiese demasiados fallos. Para llevar a cabo estas pruebas, se han introducido diferentes entradas en las tablas de la base de datos en relación a pedidos y albaranes de entrada ficticios así como artículos, clientes y proveedores. Para comprobar realmente si la aplicación era funcional y fácil de usar, se realizo un simulacro de ubicación de material de entrada, preparación de pedido y una regulación de stock con un operario que gestiona material a diario y que posee pocos conocimientos de informática. Después de realizar las diversas pruebas, el operario nos comento que la aplicación le había parecido fácil de usar y que no le había supuesto demasiados problemas entender cómo funcionaba. Además nos comento que la forma de trabajar mediante la etiquetación de bultos y ubicaciones, le supuso emplear menos tiempo en la gestión de las tareas asignadas. En resumen, se han realizado las siguientes pruebas de funcionamiento y testeo sobre la aplicación: • Se ha comprobado la correcta visualización de la aplicación en el navegador web así como en los dispositivos móviles. • Se ha comprobado la validación de los datos introducidos por los usuarios así como los mensajes de advertencia, ayuda o error que muestra la aplicación. • Todas las conexiones a la base de datos a través de los módulos, la escritura y lectura de datos en los diferentes registros de cada tabla, son aspectos que también han sido comprobados. • También se ha comprobado que se cumple correctamente el árbol de navegación diseñado e implementado así como los diferentes accesos directos a las aplicaciones externas desde cada una de las páginas del aplicativo. Universitat Autònoma de Barcelona 79 Capítulo 7: Pruebas de funcionamiento y testeo SGAR • Se realizaron pruebas de acceso con usuarios dados de alta en la base de datos así como usuarios ficticios que no constaba en esta para comprobar que no se puede acceder sin estar dado de alta en la base de datos. • Se ha comprobado que las sesiones de usuario funcionan correctamente, ya que se utilizan para registrar los procesos que realizan los operarios. • Se han realizado pruebas para comprobar que los módulos de entrada y salida cumplían con los procesos que se han de seguir para gestionar bien el material desde que se ubica en el almacén hasta que sale de este. • Se ha realizado una simulación con un operario, donde se ha comprobado que la facilidad de uso y la funcionalidad del programa son las adecuadas para gestionar correctamente un almacén. Por último cabe destacar, que el modelo de desarrollo empleado ha funcionado correctamente y esto nos ha ayudado en el éxito global del proyecto. 7.2 Posibles ampliaciones Durante el desarrollo de la aplicación, nos hemos ido dando cuenta de las posibles limitaciones que puede tener. Esto nos ha llevado a pensar posibles ampliaciones que pueden incrementar considerablemente las prestaciones que ofrece la aplicación. A continuación una lista de posibles ampliaciones que se pueden llevar a cabo: - Ampliación del número de informes o Actualmente existen tres informes de los cuales podemos extraer una determinada información. A medida que la aplicación se vaya integrando, podremos determinar que tipo de información es mas requerida por los usuarios y si esta no se puede extraer mediante los informes existentes, se podría estudiar la posibilidad de añadir más informes que contemplen dicha información necesaria. - Validación de formularios mediante Ajax o La validación actual se lleva a cabo mediante Javascript, pero este tipo de programación esta cada vez más en desuso ya que existen otras tecnologías más avanzadas como Ajax. Este lenguaje nos permite que la página donde trabajamos no se recargue para variar algunos datos, lo que reduce muchísimo los tiempos de espera del usuario y también la cantidad de código que es preciso codificar. Además, simplifica y agiliza nuestra la aplicación cuando mostramos resultados paginados. Simplifica también la validación de un formulario ya que, al no cambiar de página, ya no es necesario recuperar los datos que ha enviado el formulario para mostrarlos nuevamente en la página de introducción de datos. Universitat Autònoma de Barcelona 80 Capítulo 7: Pruebas de funcionamiento y testeo SGAR Universitat Autònoma de Barcelona 81 - Optimizar interfaz de dispositivos móviles o Actualmente, la interfaz de los dispositivos móviles es bastante sencilla. A medida de que se vaya implantando el sistema, se consultara con los usuarios si es necesario algún tipo de cambio, para que sea lo más eficiente posible. - Incluir mas funcionalidades en la interfaz de los dispositivos móviles o Además de cambiar algunos aspectos visuales, también se contempla la opción de añadir funcionalidades como un visor de informes adecuado a estos dispositivos, la posibilidad de imprimir los albaranes desde los dispositivos, o funcionalidades que sugieran los propios usuarios - Integrar un módulo de gestión de cargas de material o Sería interesante añadir la opción de gestión de cargas de material a través del programa. Añadiendo esta funcionalidad, abarcaríamos completamente las gestiones que lleva a cabo un almacén. Este modulo se encargaría de controlar las cargas que se realizan a los medios de transportes contratados, lo que nos aseguraría que, mediante el uso de bultos, las cargas se realizan correctamente. Capítulo 8: Conclusiones SGAR Capítulo 8: Conclusiones 8.1 Conclusiones finales El objetivo principal de este proyecto era de abordar un problema y encontrar una solución informática que solventase dicho problema y todo ello mediante la elaboración de unos documentos, tales como el estudio de viabilidad, marco teórico, análisis, etc., y el aprendizaje de las tecnologías utilizadas que junto con los conocimientos adquiridos durante la carrera y las directrices marcadas por el director del proyecto, me han ayudado a finalizar satisfactoriamente este proyecto. En todo momento se ha intentado que la aplicación fuese lo más efectiva y simple de utilizar posible, para que en el momento de implantarla, los usuarios se adecuen lo antes posible al nuevo sistema de trabajo. Mediante este nuevo sistema, garantizamos que la efectividad y fiabilidad en la gestión de material es mucho mayor a la que ofrece el sistema convencional mediante listado impresos. Otro objetivo importante era aprender a utilizar y gestionar un sistema LAMP, ya que se trata de un sistema que cada vez es más utilizado y es interesante tener conocimientos sobre este. Por ello, podemos decir que la aplicación funciona correctamente en este tipo de sistemas y podemos dar por cumplido este objetivo. Además del aprendizaje de estos sistemas, también hemos aprendido a utilizar lenguajes como Ajax, que cada vez se encuentra más extendido en el mercado, y que aunque se haya obtenido un nivel básico, esto nos ayuda a tener unos cimientos en los cuales podamos desarrollar más conocimientos sobre este lenguaje. La planificación inicial del proyecto, no se ha cumplido en las fechas establecidas, debido principalmente a la apretada agenda laboral y académica que tengo y al aprendizaje de las tecnologías utilizadas en el desarrollo de la aplicación. Tengo que destacar que la elaboración de este proyecto supuso un gran reto para mí, ya que nunca me había enfrentado al diseño, codificación y prueba de una aplicación. Además todos los conocimientos adquiridos en la realización de este proyecto, han supuesto para mí una motivación extra para aprender aun más cosas y no quedarme estancado con los que actualmente tengo. Por último, me gustaría decir que estoy muy satisfecho por haber llevado a cabo este proyecto, ya que me ha servido para enfrentarme a retos que nunca me se me habían propuesto, además de adquirir nuevos conocimientos que me han ayudado a encontrar una solución al problema que me propuse al comienzo de este. Universitat Autònoma de Barcelona 82 Capítulo 9: Bibliografía SGAR Capítulo 9: Bibliografía 9.1 Relación de libros consultados • Cesar Perez. MySql para Windows y Linux. Editorial RA-MA, Año 2004. ISBN: 84-7897-601-9. • Abraham Gutiérrez y Ginés Bravo. PHP4 a través de ejemplos. Editorial RA-MA, Año 2004. ISBN: 84-789-565-9. • Justin Gehtland, Ben Galbraith y Dion Almaer. Pragmatic Ajax. Editorial The pragmatic programmers, Año 2006. ISBN: 0-9766940-8-5. 9.2 Relación de páginas Web consultadas • Los diferentes lenguajes de programación Web (Acceso 03/2009) http://www.maestrosdelweb.com/principiantes/los-diferentes-lenguajes-deprogramacion-para-la-web • Conceptos básicos de servidores Web (Acceso 03/2009) http://www.cibernetia.com/manuales/instalacion_servidor_web/1_conceptos _basicos.php • Una introducción a Apache (Acceso 03/2009) http://linux.ciberaula.com/articulo/linux_apache_intro/ • ¿Qué son las Bases de datos? (Acceso 03/2009) http://www.maestrosdelweb.com/principiantes/%C2%BFque-son-las-basesde-datos/ • Carga unitaria (Acceso 03/2009) http://www.monografias.com/trabajos51/carga-unitaria/carga-unitaria3.shtml • Servidor web Microsoft IIS vs. Apache (Acceso 06/2009) http://www.sahw.com/wp/archivos/2007/06/08/apache-vs-microsoft-iisestadisticas-de-utilizacion-distribucion-y-alojamiento-de-malware/ • Ley Orgánica de Protección de Datos (Acceso 06/2009) http://es.wikipedia.org/wiki/Ley_Org%C3%A1nica_de_Protecci%C3%B3n_ de_Datos_de_Car%C3%A1cter_Personal_de_Espa%C3%B1a • Obligaciones de la LOPD (Acceso 06/2009) http://www.leydeprotecciondedatos.com/2006/08/16/obligaciones-basicasde-lopd/ • Niveles LOPD (Acceso 06/2009) http://www.portaley.com/protecciondatos/obligacioneslegales.shtml • Página oficial de la LOPD (Acceso 06/2009) https://www.agpd.es/portalweb/index-ides-idphp.php Universitat Autònoma de Barcelona 83 Capítulo 9: Bibliografía SGAR Universitat Autònoma de Barcelona 84 • Arquitectura LAMP (Acceso 06/2009) http://www.ibiblio.org/pub/linux/docs/LuCaS/Manuales-LuCAS/doc-cursosalamanca-LAMP/lamp-teoria-html/ch02s03.html • RFID (Acceso 05/2009) http://es.wikipedia.org/wiki/RFID • Ventajas de utilizar CSS (Acceso 06/2009) http://www.stardustxs.com/2008/03/05/ventajas-de-usar-css/ • Opciones para crear páginas web amigables de impresión (Acceso 06/2009) http://www.maestrosdelweb.com/editorial/opciones-para-crear-paginasweb-amigables-de-impresion/ • Generación de códigos de barras en Ubuntu (Acceso 06/2009) http://blog.controlzeta.net/?tag=php • Validación o autenticación de usuarios en PHP (Acceso 06/2009) http://wlannot.wordpress.com/2007/03/05/validacion-o-autenticacion-deusuarios-en-php-segunda-parte/ • CSS Tutorial (Acceso 05/2009) http://www.w3schools.com/css/default.asp • HTML Tutorial (Acceso 05/2009) http://www.w3schools.com/html/default.asp • JavaScript Tutorial (Acceso 06/2009) http://www.w3schools.com/js/default.asp • Ajax Tutorial (Acceso 06/2009) http://www.w3schools.com/ajax/default.asp