MANTENIMIENTO DEL SISTEMA DE PUNTO DE VENTA DE GRUPO ESNA TIK-TOK. SOLSER Soluciones y Servicios

Transcripción

1 UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO Voluntad Conocimiento Servicio MANTENIMIENTO DEL SISTEMA DE PUNTO DE VENTA DE GRUPO ESNA TIK-TOK SOLSER Soluciones y Servicios Reporte de Estadía para obtener el Título de Técnico Superior Universitario en Tecnologías de la Información y Comunicación Área Sistemas Informáticos DAVID DANTE CERVANTES BAUTISTA Santiago de Querétaro Agosto 2010

2

3 UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO Voluntad Conocimiento Servicio MANTENIMIENTO DEL SISTEMA DE PUNTO DE VENTA DE GRUPO ESNA TIK-TOK SOLSER Soluciones y Servicios Reporte de Estadía para obtener el Título de Técnico Superior Universitario en Tecnologías de la Información y Comunicación Área Sistemas Informáticos Asesor de Empresa: ING. AIDABETH ZALAZAR FLORES Asesor de Universidad: M. EN C. MARTIN LARIOS OSORIO Alumno: DAVID DANTE CERVANTES BAUTISTA Santiago de Querétaro Agosto 2010

4

5 ÍNDICE INTRODUCCIÓN 6 CAPITULO I SOLSER (SOLUCIONES Y SERVICIOS) 1.1 SOLSER Giro de la empresa Misión Visión Organigrama 10 CAPITULO II MANTENIMIENTO A LA APLICACIÓN DEL SISTEMA DE PUNTO DE VENTA DE GRUPO ESNA TIK-TOK 2.1 Análisis de necesidades Definición del Proyecto Objetivos Plan de trabajo Diagrama de Gantt Especificaciones 14 CAPITULO III DESARROLLO DEL PROYECTO 3.1 Etapas del proyecto Análisis general del sistema Integración del sistema POS Localización de Problemas y Mejoras Mantenimiento del sistema Problema 1: Botón Abrir cajón 25

6 Problema 2: Espacio del ticket Mejora 1: Cambio en el ticket Mejora 2: Reporte de clientes morosos Pruebas Área de pruebas Pruebas integrales Pruebas, implementación y monitoreo 33 CAPÍTULO IV CONCLUSIONES 4.1 Dificultades Logros obtenidos Recomendaciones 36 GLOSARIO MATERIAL DE CONSULTA

7 INTRODUCCIÓN El sistema POS es una aplicación para el registro de ventas y compras de la tienda Tik-Tok. Además, lleva el control del inventario de la misma tienda. En el presente documento se integra la información acerca del mantenimiento a la aplicación, ya que el sistema presentó una serie de anomalías mientras se encontraba en ejecución dentro del ordenador del cliente. En el capítulo I se describe de manera general la empresa SOLSER, su organización y políticas, así como las actividades a las que ésta se dedica. El capítulo II resume la información acerca del proyecto asignado y muestra los objetivos que han de ser cumplidos al finalizar el mantenimiento de la aplicación. El capítulo III describe de manera general el sistema y la integración del mismo. Además, explica las actividades que se realizaron para cumplir con los objetivos que se enlistan en el capítulo II. El capítulo IV presenta la problemática que se enfrentó durante la realización del proyecto y cómo fue resuelta. De igual manera, muestra los logros que se obtuvieron y algunas recomendaciones hacia la empresa.

8 CAPÍTULO I SOLSER (SOLUCIONES Y SERVICIOS)

9 1.1 SOLSER Giro de la empresa SOLSER (Soluciones y Servicios) es una empresa 100% mexicana, con más de 7 años de experiencia en TI, desarrollos de software y soporte técnico de la más alta calidad, cuenta con profesionales especializados en diferentes áreas y plataformas. La organización, usando metodologías como ITIL y CMMI, brinda soluciones con la más alta tecnología y excelencia en el servicio. Cuenta con experiencia en: - Desarrollo de software. - Soporte técnico. - Soporte e instalación de redes. - Soporte a servidores con sistemas operativos Windows, Linux- Unix. - Soluciones empresariales, bancarias, aseguradoras y financieras sobre plataformas Oracle, IBM, DB2, Microsoft, administración de proyectos. - Levantamiento de Infraestructura, Diagnóstico, Proyectos e implementación. - Instalación y soporte de servidores. - Call Center Misión SOLSER pretende desarrollar el potencial de sus profesionales para crear e innovar tecnología de información de México para el mundo. 9

10 1.1.3 Visión SOLSER pretende ser la mejor empresa para trabajar, permitiendo establecer relaciones a largo plazo con sus clientes apoyando el desarrollo de sus objetivos Organigrama SOLSER está conformada por las áreas que en el siguiente organigrama se muestran (fig. 1.1). Figura 1.1 Organigrama de SOLSER 10

11 CAPÍTULO II MANTENIMIENTO A LA APLICACIÓN DEL SISTEMA DE PUNTO DE VENTA DE GRUPO ESNA TIK-TOK

12 2.1 Análisis de necesidades Definición del Proyecto El área de Coordinación de Infraestructura y Productos Internos se encarga de que el hardware y el software que está siendo utilizado dentro la organización, se encuentre en las mejores condiciones; además de ser el área que se encarga de realizar la configuración e instalación del mismo en los equipos con los que cuenta dentro y fuera de la empresa. En esta área también se llevan a cabo algunos de los proyectos internos, tal es el caso del sistema POS (Point Of Sales) para Tik-Tok del grupo ESNA. Este sistema está diseñado para las ventas que puedan ser realizadas dentro de los restaurantes y como tal, fue adaptado para llevar a cabo el control de las ventas de Tik-Tok; en este momento se encuentra en mantenimiento, ya que algunas de las funciones de este sistema no lograron satisfacer las necesidades del cliente Objetivos 1. Analizar las fallas e inconformidades que fueron detectadas en la ejecución del programa para comprender por completo las necesidades del cliente y que éstas sean corregidas a la brevedad. 2. Realizar los cambios al software solicitados por el cliente y validar que estos funcionen correctamente. 3. Implementar el programa dentro de la tienda Tik-Tok. Con ésto se pretende que el cliente quede completamente satisfecho 12

13 con el programa. Posteriormente a la implementación del sistema, el área de pruebas mantendrá una constante comunicación con el cliente, con esto SOLSER garantiza la satisfacción total del cliente. 2.2 Plan de trabajo El siguiente diagrama muestra las actividades que van a realizarse para la corrección, el mantenimiento y la implementación de las especificaciones dadas por el cliente Diagrama de Gantt Fig. 1.1 Diagrama de Gantt 13

14 2.2.2 Especificaciones 1. Entrevista con el cliente En esta etapa, el cliente nos indicará cuáles son los módulos que no funcionan justo como él lo requería, además, de las funciones que él desea que sean agregadas al sistema y los errores que se presentaron durante su ejecución. 2. Definir tiempo Una vez que sean obtenidas todas las especificaciones que el cliente nos indique, el coordinador de área de Desarrollo definirá el tiempo que se llevará en cada una de las correcciones al sistema; esto tiene la finalidad de delimitar una fecha de entrega del sistema con los nuevos cambios y el costo correspondiente a dichos cambios. También se asignará al personal que ha de llevar a cabo el mantenimiento del sistema 3. Análisis general del sistema Cuando el proyecto sea asignado, se comenzará con el análisis general del sistema; ésto para conocer y familiarizarse con su funcionamiento, lógica y estilo de programación. 4. Realizar cambios En esta fase, el programador comenzará a aplicar los cambios que previamente serán definidos en la entrevista con el cliente. 5. Realizar pruebas Ya que los cambios se efectúen, se comenzarán las pruebas del sistema. Estas pruebas serán ejecutadas por el programador que efectúe el mantenimiento del sistema. Después el sistema será enviado al área de Pruebas, donde se efectuarán las Pruebas 14

15 Unitarias del Sistema; el área de pruebas es quien acredita que el sistema funciona de manera correcta y que puede ser puesto en producción. De existir fallas, éstas se indican al programador quien corregirá cualquier anomalía que sea presentada durante la ejecución de las pruebas. 6. Implementación Cuando sea autorizado, el sistema será reinstalado en el ordenador del cliente y se conectará a la base de datos del mismo, previamente respaldada continuándose con la fase de monitoreo. 7. Monitoreo Cuando un sistema ha sido implementado por la empresa, ésta mantiene una constante comunicación con el cliente, y así, valida que sean cumplidas todas las expectativas de éste. Ya que sea reimplementado el sistema, se continuará con esta fase, la cual termina un mes después de implementarse el programa. 15

16 CAPÍTULO III DESARROLLO DEL PROYECTO

17 3.1 Etapas del proyecto Análisis general del sistema El sistema POS-Point of Sales, es un programa de punto de venta en código libre (GNU) patrocinado por Openbravo, dedicado originalmente para su uso en Restaurantes. Fue adaptado para la tienda Tik-Tok de grupo ESNA que es una tienda minorista de artículos de bisutería Integración del sistema POS El sistema POS está conformado por tres módulos: 1. Principal: a. Ventas: El registro de las ventas que se van realizando durante la ejecución del programa. b. Editar ventas: Donde pueden editarse los productos, el modo de pago, el cliente o los productos de una venta anteriormente registrada. c. Clientes: Donde se muestran los detalles del registro de clientes (Nombre, Deuda Máxima y Actual, Última deuda) y contiene la opción que permite saldar por completo la cuenta del cliente. d. Movimientos de Caja: Donde se indica cuánto dinero entra o sale de la caja cuando no se involucra una venta. e. Cerrar Caja: Donde se muestra el informe de pagos y el informe de ventas, también contiene las opciones para cerrar la caja e imprimir el informe. f. Cierres de caja: Permite generar un reporte donde se 17

18 presentan todos los cierres de caja a partir de un rango de fechas. 2. Administración: a. Clientes: El apartado del sistema donde se registran, editan o eliminan los clientes dentro del sistema y muestra tres tipos de reportes: el informe de clientes (todos los clientes que se tienen registrados en el sistema y los detalles de su registro), el informe de clientes morosos (todos los clientes que tienen una deuda con la tienda) y el diario de clientes (donde se muestran los pagos realizados por los clientes y las fechas de los mismos). b. Inventario: Este apartado está enfocado a los productos; aquí es donde estos se registran, editan, se organizan por almacén, se definen sus categorías, sus atributos y se definen las entradas de productos al almacén de la tienda. c. Ventas: Muestra los informes de caja por vendedor (nombre del vendedor, la fecha de la primera y de la última venta y el total que éstas generaron), el informe de ventas de productos (las unidades totales vendidas de cada producto y las ganancias que generaron a la tienda), el informe de descuentos o impuestos (muestra el total de cada impuesto aplicado), el gráfico de ventas (los productos vendidos por cada caja registradora dentro de la tienda) y el gráfico de ventas de productos (número de productos vendidos y total de ganancias que generaron). d. Mantenimiento: Las funciones que ofrece este apartado 18

19 son exclusivas del administrador, ya que es aquí donde se registran, editan o eliminan los usuarios del sistema, se definen sus roles y accesos, se determina el código de impresión de los tickets, se modifican algunas imágenes del sistema; además se pueden editar los diferentes almacenes con los que cuenta la tienda. 3. Sistema: a. Cambiar clave. b. Configuración: Donde se define el tipo y la ubicación de la base de datos que se usa en el sistema, el nombre de la caja que se muestra en los informes, el aspecto de las ventanas o skins, los tipos de ticket, las impresoras a ser usadas, los formatos numéricos con respecto a la localización y el tipo de lector de tarjetas y códigos de barras que ha de ser usado en el sistema. c. Impresora: Muestra una vista del ticket, en caso de que en configuración esté definida una impresora a pantalla. d. Salir. 19

20 Localización de Problemas y Mejoras Al iniciar el sistema, la pantalla muestra los usuarios por default registrados en el sistema (fig. 3.1). Fig. 3.1 Pantalla principal 1 En esta pantalla se puede dar clic en el usuario correspondiente e ingresar al sistema; éste, automáticamente, muestra una pequeña pantalla donde pide la contraseña para ingresar (esto en caso de que el usuario tenga configurada la contraseña, si no, solo redirecciona) para después ser redireccionados a la pantalla de ventas (fig. 3.2); en la cual se encuentra el primer problema encontrado por el cliente: - Problema 1: El Botón Abrir Cajón no funciona correctamente. 20

21 Una vez dentro del sistema, se puede registrar una venta de la siguiente manera: - Ingresar a Ventas desde el menú principal. - Pasar el código de barras por el verificador y el detalle del producto, teclear el código de barras y dar clic en el botón del código de barras, o seleccionar el producto del grupo de productos y categorías que aparece en la parte inferior de la pantalla (fig. 3.2). Fig. 3.2 Pantalla de Ventas (detallada) - Para efectuar la venta: dar clic en el botón = que aparece en la sección del código de barras. - Se despliega la pantalla para seleccionar el tipo de pago (fig. 3.3). - El usuario del sistema teclea la cantidad con la que se efectúa el pago y el sistema muestra el cambio que ha de ser entregado al 21

22 cliente. Al terminar se muestra la pantalla de ventas en su forma original. En el momento en que termina esta función se encuentran el segundo problema y la primera mejora. - Problema 2: La impresora corre demasiado papel antes de comenzar con la impresión. - Mejora 1: Que el ticket muestre el cambio que se entrega al cliente. Fig. 3.3 Pantalla de Selección de pago (detallada) 22

23 Desde el módulo de clientes se accede al registro y al informe de éstos; al ingresar a este apartado del módulo se nos presenta una pantalla con las diferentes opciones que este ofrece (fig. 3.4). Fig. 3.4 Pantalla de Clientes Al ingresar el informe de clientes morosos, se presenta la única opción de para generar el informe (fig. 3.5). Si desplegamos el informe, se muestran únicamente los datos generales de los clientes que tienen algún adeudo pendiente con la tienda; este informe no muestra el detalle de los productos que el cliente está pagando a cuenta, sólo el monto total de la deuda y la fecha de la misma. 23

24 Fig. 3.4 Reporte de Clientes Morosos En este informe se muestra la segunda mejora que se debe realizar. - Mejora 2: El reporte debe de mostrar el detalle de los productos que el cliente se encuentra pagando a cuenta Mantenimiento del sistema Problema 1: Botón Abrir cajón La funcionalidad correcta es, que al dar clic al botón o al imprimir el ticket de una venta el cajón abra automáticamente; se encontró que el problema no era el botón sino la función que abre el cajón en las dos acciones anteriormente mencionadas. El problema consiste en que la impresora conectada al cajón no recibía los caracteres exactos para poder mandar la señal al cajón y que éste abriese. 24

25 Después de la revisión del código, el método dedicado a efectuar esta acción opendrawer(), de la clase DevicePrinterPOS.java, el cual llama a la clase CashDrawer.java que es una clase para la conexión de la impresora y el cajón con java. El error consistía en que el método no efectuaba la acción correctamente, así que se implementó la clase Drawer.java, esta clase contiene únicamente el método open() el cual, al ser ejecutado, envía los caracteres correctos a la impresora para que esta abra el cajón. Para corregir el error, solo fue necesaria llamar al método open() de la clase Drawer.java en el método opendrawer() Problema 2: Espacio del ticket La función se efectuaba de manera correcta, el único problema era, que el espacio del ticket previo a la información que presentaba, era demasiado largo (15 cm aproximadamente) y esto, a la larga, representa una pérdida. Después de la revisión del código, se encontró que la clase DeviceTicket, utilizaba el método addprinter() para enviar caracteres a la impresora conectada a la computadora. Al método addprinter() se le enviaba una nueva instancia de la clase DevicePrinter, la cual en su constructor recibía 2 parámetros numéricos posicionales para que esta comenzara a imprimir, uno para x y el otro para y. Con el primero no había problema, ya que la posición del ticket a lo ancho era correcta, y el segundo era demasiado grande, así que éste se redujo para que el ticket se imprimiera de la manera deseada (figuras 3.5 y 3.6). 25

26 Fig. 3.5 Ticket anterior Fig. 3.6 Ticket corregido Mejora 1: Cambio en el ticket Esta función del sistema no había sido implementada, así que hubo que hacer varias modificaciones. La primera modificación fue dentro del código fuente del programa; la clase TicketInfo contiene las funciones que son llamadas dentro del código XML del programa. Dentro de las funciones se encuentran las siguientes: - printdate(), devuelve el valor de la hora y la fecha. - printuser(), devuelve el nombre del usuario del sistema. - printcustomer(), devuelve el nombre del cliente, en caso de que el ticket haya sido asignado a uno. - printtotal(), devuelve el costo total de lo que el cliente compró. Y los métodos agregados a esta clase para cumplir con el 26

27 requerimiento fueron: - printchange(), implementado para la obtención del cambio a partir del importe. - printamount(), implementado para imprimir el monto total. La segunda modificación se realizó dentro del código XML de la aplicación. Para localizar este código basta con iniciar sesión como administrador e ingresar a la sección de Mantenimiento del módulo Administración (fig.3.7), en esta se encuentra la opción de recursos, donde se muestra una parte de la configuración del sistema, entre las opciones a configurar se encuentra Printer.Ticket (fig. 3.8), que contiene código XML que es enviado a la impresora para que esta imprima con el formato deseado los tickets. Sólo se localizó la posición correcta y se agregó la llamada a los métodos anteriormente implementados. 27

28 Fig. 3.7 Pantalla de Mantenimiento Fig. 3.8 Pantalla de Recursos, con el código XML para el ticket Una vez implementado lo anterior, cualquier ticket impreso mostraba el 28

29 monto total y el cambio entregado al cliente (figuras 3.9 y 3.10). Fig. 3.9 Ticket anterior Fig Ticket corregido Mejora 2: Reporte de clientes morosos Para esta mejora, sólo se modificó el reporte desde IReport, el cual es un programa que te permite hacer cualquier tipo de reportes conectándose a una infinidad de tipos de bases de datos. El reporte fue modificado casi en su totalidad, ya que antes sólo se conectaba con una sola tabla y ahora era necesario mostrar los datos con los que ya contaba, además de generar una consulta para agregarle un subreporte al mismo. Para la implementación de esta mejora, fue necesario hacer 3 29

30 cambios: a la base de datos, al reporte y al código que presenta los reportes del sistema. A la base de datos se le agregó una vista, quien nos generaba la lista de clientes que tienen una deuda con la tienda. Una vez generada la vista, se generó una consulta que a partir de la vista, enlistaba de manera particular los el detalle de los tickets del cliente seleccionado. Ya con lo anterior, se realizó la modificación al reporte; se le agregó el subreporte y se hizo un reacomodo para presentar la información de una manera más compacta y clara. Después, fue modificado el archivo Customers.bs; que contiene la información necesaria para que el programa presente el reporte en la pantalla. Este archivo, contiene código java que el programa toma y compila para ser usado por la librería de IReport que anteriormente fue agregada al sistema al momento de su creación. La tercera modificación fue sobre el código fuente, ya que ninguno de los reportes que se pueden generar desde el sistema contenía un subreporte o tabla. La clase dedicada al mostrar los reportes es JPanelReport.java, así que solo hubo que validar el tipo de reporte a presentar y agregar como parámetro el subreporte dentro del reporte, así, este se presentaría de la manera deseada (figuras 3.11 y 3.12) 30

31 Fig Reporte anterior sin detalle de venta Fig.3.12 Reporte nuevo con el detalle de la venta 31

32 3.1.3 Pruebas Área de pruebas Dentro de SOLSER, el área de pruebas es quien realiza la ejecución final del programa, antes de ser enviado a producción, es decir, antes de que sea instalado en los ordenadores del cliente; además, durante el monitoreo del programa, es quien recibe las observaciones del cliente acerca de los errores que se presentasen durante la ejecución del programa Pruebas integrales Una vez que el programador considera que las correcciones han concluido, se envía un documento al área de pruebas junto con el programa para que, dicha área, realice las pruebas integrales del sistema. El documento enviado contiene información detallada sobre el ambiente con el que se debe contar dentro del ordenador para que el programa se ejecute de manera correcta. Además, contiene el nombre de los módulos del sistema a los que se les debe realizar las pruebas. Si el programa no presenta ningún error durante la ejecución de las pruebas, se le da el visto bueno para la puesta en producción. En caso contrario, se regresa al programador junto con un documento donde se le indica donde y cuando fue que el sistema falló. Si la falla es durante la ejecución del sistema en el ordenador del cliente, es decir, la fase de monitoreo, el cliente envía los datos del error al área de pruebas y ésta se encarga de que el programador corrija dicho error. 32

33 Pruebas, implementación y monitoreo Ya que se concluyó con la programación de las mejoras y la corrección de los errores, el sistema fue enviado al área de Pruebas; en dicha área, fueron examinados los módulos modificados por el programador y no se encontró falla alguna. Una vez terminadas las pruebas, el sistema fue instalado en el ordenador del cliente; una vez ahí, se continuó con la fase de monitoreo. Dentro de esta fase se envió al área de pruebas la información sobre un error: el cajón del dinero seguía sin abrir. Revisando una vez más el código, se encontró que este se había implementado correctamente, el error fue que la versión del sistema entregado al área de pruebas no era la misma que se implementó dentro de la tienda Tik-Tok; así que se reprogramó una cita con la dueña de la tienda y el sistema nuevo fue implementado en su ordenador. Se regresó a la etapa de monitoreo y hasta la fecha de elaboración del presente reporte, no se han presentado errores de la aplicación. 33

34 CAPÍTULO IV CONCLUSIONES

35 4.1 Dificultades Durante la aplicación de los cambios al sistema POS (Point Of Sales) se presentaron 2 dificultades muy importantes. El estilo de programación del sistema fue la más grande dificultad; ya que es un programa descargado y uno se debe adaptar al modo y estilo de programación del autor (este problema se presentó la primera vez que el programa se modificó y se implementó para la tienda Tik- Tok). Al revisar el código para la realización de las correcciones y las mejoras, se encontró que el modo de integración de las interfaces estaba demasiado confuso; para resolver este problema, fue necesario acudir a los manuales en línea del POS y se pudo concluir correctamente la programación del mismo. La segunda dificultad sólo afectó la realización de las pruebas del cajón del dinero. Ya que la empresa no cuenta con el equipo necesario para la realización de las pruebas, se solicitó el equipo a la dueña de la tienda Tik-Tok quien sólo podía facilitar el equipo a partir de las 9 de la noche, así que todas las pruebas, tanto las corridas de escritorio como las integrales, se realizaron durante el horario nocturno. Esta problemática se intentó resolver con el uso de un simulador de impresión, el cual nunca fue bien configurado para su uso. 35

36 4.2 Logros obtenidos Los objetivos anteriormente planteados fueron cumplidos en su totalidad: - Se analizaron de manera correcta las fallas e inconformidades del cliente y estas fueron solucionadas en tiempo y forma. - Los cambios al software fueron correctamente realizados, ya que dentro de la fase de pruebas el sistema no presento anomalías. - La segunda implementación del sistema en el ordenador del cliente dio inicio a la fase de monitoreo y no se han presentado problemas hasta la fecha de elaboración de éste reporte. Al finalizar con las correcciones al sistema, se logró obtener el resultado deseado: que el cliente estuviera satisfecho con él; después del último monitoreo ya no hubo ningún tipo de queja por parte del cliente acerca del funcionamiento del sistema ni de las mejoras que se le implementaron. Además de esto, durante el transcurso de la estadía, pude observar cómo se organiza una empresa y sus áreas, como es que se lleva a cabo la realización de un proyecto, los procesos y la forma en cómo deben comunicarse las áreas. 4.3 Recomendaciones El programa trabaja bien para lo que está dedicado, es decir, las ventas en restaurantes y cuando se adapta para una tienda como Tik- Tok, este pierde una gran cantidad de funcionalidades. La única recomendación está dedicada más a la empresa que a la funcionalidad del programa: si se desea hacer un programa, que todo 36

37 el código sea programado desde la empresa ya que en caso de que se le quieran hacer correcciones éstas se realizarían más rápido ya que la estructura se comprendería por todos los programadores, además de que da una mejor imagen el hecho de saber que la empresa realizó por completo el programa en vez de haberlo adaptado. 37

38 GLOSARIO

39 Clase Es un archivo que contiene código compilado a partir de un documento con extensión.java, que sirve para generar aplicaciones. GNU Licencia Pública General. Software desarrollado para distribución sin fines de lucro. Método Es cualquier función programada que puede realizar una parte del sistema. XML Son las siglas de Extensible Markup Language, que es un lenguaje de programación diseñado especialmente para los documentos de la web. Permite que los diseñadores creen sus propias etiquetas, permitiendo la definición, transmisión, validación e interpretación de datos entre aplicaciones y entre organizaciones. 39

40 MATERIAL DE CONSULTA

41 Referencias WEB - Manual en línea del sistema POS de Openbravo: - Guía de usuario en línea Openbravo Wiki: Manuales - Manual de la Impresora Star SP