TRABAJO FIN DE ESTUDIOS - biblioteca.unirioja.es · ... ACTAS DE REUNIONES ... de una aplicación software para el punto de venta de un pub ... dejando una holgura a la hora de la

TRABAJO FIN DE ESTUDIOS

Aplicación de gestión para el TPV de una cafetería

Adela Chandro Velasco

PROYECTO FIN DE CARRERA

Tutor: Eloy Javier Mata Sotés

Curso 2011-2012

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2012

publicaciones.unirioja.esE-mail: [email protected]

Aplicación de gestión para el TPV de una cafetería, trabajo fin de estudiosde Adela Chandro Velasco, dirigido por Eloy Javier Mata Sotés (publicado por la

Universidad de La Rioja), se difunde bajo una LicenciaCreative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los

titulares del copyright.

1

UNIVERSIDAD DE LA RIOJA

Facultad de Ciencias, Estudios Agroalimentarios e Informática

PROYECTO FIN DE CARRERA

Ingeniería Técnica en Informática de Gestión

Aplicación de gestión para el TPV de una

cafetería

Alumno: María Adela Chandro Velasco

Director: Eloy Mata Sotes

Logroño, Junio del 2012

2

INDICE 2

1. D. O. P. 4

1.1 Antecedentes 4

1.2 Objetivos 4

1.3 Descripción 5

1.4 Entregables 6

1.5 Estructura de descomposición de tareas 6

1.6 Plan de trabajo 9

1.7 Riesgos 11

2. ANÁLISIS 12

2.1 Análisis de requisitos 12

2.1.1 Identificación de actores 12

2.1.2 Identificación de los casos de uso 12

2.2 Análisis de clases 29

2.3 Análisis de la interfaz 30

2.4 Análisis de pruebas 31

3. DISEÑO 33

3.1 Arquitectura del sistema 33

3.2 Diseño de la interfaz 33

3.3 Diseño de las clases 53

3.4 Diseño de la base de datos 61

4. IMPLEMENTACIÓN 65

4.1 Tecnologías elegidas y herramientas utilizadas 65

4.2 Construcción del sistema de información 66

4.2.1 implantación de la base de datos 66

4.2.2 Preparación del entorno de construcción 66

4.2.2.1 Librerías externas necesarias 66

4.2.3 Problemas con MySQL 67

4.2.3.1 Borrado y modificación de productos y familias 67

4.2.3.2 Guardar valores decimales en MySQL 68

4.2.3.3 Modificaciones en la identificación y creación de camareros 69

4.2.3.4 Guardar imágenes en la base de datos 69

4.2.4 Problemas encontrados en la aplicación de gestión 70

3

4.2.4.1 Cierre de caja teórico o real 70

4.2.4.2 Reporte de informes 70

4.2.5 Problemas encontrados en la pantalla de ventas 71

4.2.5.1 Tamaño de la pantalla de ventas 71

4.2.5.2 Introducción de precios directos 71

4.2.5.3 Ventas aplazadas 72

4.2.5.4 Imprimir tickets de venta 72

5. GESTIÓN Y CONCLUSIONES 76

5.1 Planificación 76

5.2 Aplazamiento 77

5.3 Conclusiones 80

6. APENDICE I: ACTAS DE REUNIONES 82

6.1 Actas de reuniones con los clientes 82

6.2 Actas de reuniones con el director del proyecto 86

4

7. D. O. P.

1.1 Antecedentes

El proyecto consiste en el desarrollo de una aplicación software para el punto

de venta de un pub juvenil.

Existen numerosas aplicaciones similares hoy en día. Desde las desarrolladas

por grandes empresas como IBM, Apple o Microsoft, muy genéricas, desarrolladas

para el TPV de cualquier mediana empresa, sin importar el sector, muy completas y

caras; pasando por aplicaciones menos genéricas, desarrolladas por empresas

dedicadas al desarrollo de software como Consultic, One Step Rentail Solutions, SGM o

TPV.NET, creadas para el TPV de cualquier pequeña o mediana empresa, de un sector

concreto, también muy completas; hasta las que podemos encontrar en páginas de

software libre como Softonic.com, creadas para un tipo concreto de empresa, dentro

del sector hostelero, completas y gratuitas. Pero todas estas aplicaciones tienen en

común que son demasiado completas, unas mucho más que otras, ya que, no solo se

encargan de control de ventas, sino también de salones, mesas, stock, almacenes,

proveedores, pedidos, etc.… dependiendo de la aplicación en concreto. Además todos

deben configurar y actualizar periódicamente todos sus parámetros para su correcto

funcionamiento.

El cliente es un pub para jóvenes, ubicado en Pradejón, en la provincia de La

Rioja, cuyos dueños poseen varios negocios en la hostelería, que comparten almacén y

género, por lo que quieren una aplicación personalizada para el TPV del pub, mucho

más simple y fácil de configurar que las ya existentes, y que únicamente controle las

ventas del local y los camareros que las realizan.

1.2 Objetivos

La aplicación debe:

• Ser genérica, para el TPV de cualquier pub o similar.

• Ser una herramienta intuitiva y fácil de manejar.

• Tener todas sus funciones diseñadas para una pantalla táctil.

• Mantener separados el punto de venta y el módulo de gestión.

• Controlar las ventas y el camarero que las realiza.

• Hacer el cierre y balance de caja.

• Crear informes y estadísticas.

5

1.3 Descripción

El proyecto es una aplicación genérica desarrollada para el TPV de cualquier

pub o similar, intuitiva y fácil de manejar, de forma que cualquier usuario sin

conocimientos informáticos pueda utilizarlo.

La aplicación está dividida en dos partes muy diferenciadas:

• El punto de venta:

Consistente en una pantalla donde visualizar gráficamente todos los productos

a la venta, agrupados por categorías (familias), donde todas las funciones deben ser

diseñadas para una pantalla táctil.

Permitirá:

� Seleccionar el camarero que realiza la venta.

� Seleccionar los productos de la venta, indicando su cantidad.

� Eliminar un producto de la venta actual.

� Ver el total al que asciende la venta, en todo momento.

� Anular la venta actual entera.

� Visualizar en pantalla los datos de la venta actual, en todo momento.

� Imprimir el ticket al confirmar una venta.

� Aplazar una venta y recuperarla después.

� Confirmar una venta sin imprimir ticket.

� Ver una lista de las ventas aplazadas

• El módulo de gestión:

Aplicación orientada al gerente o encargado, totalmente separado del módulo

de venta y con acceso protegido.

Permitirá:

� Controlar el acceso por contraseña.

� Configurar el TPV agregando, eliminando o modificando los productos y

las categorías.

� Anular ventas ya confirmadas.

� El cierre y balance de caja.

� Informes de ventas por fechas, camareros, …

� Estadísticas sobre productos, familias,…

6

1.4 Entregables

• Documentación de objetivos del proyecto (D. O. P.).

• Documentación del análisis de requisitos.

• Documentación del diseño en UML.

• Documentación del diseño de la base de datos.

• Memoria.

• Producto final, aplicación.

• Presentación.

1.5 Estructura de descomposición de tareas

• Conocimientos previos:

� Establecer horario del proyecto: 1 hora.

� Conocimiento del funcionamiento de la empresa: 1hora.

� TOTAL: 2 horas.

• Análisis de requisitos iniciales:

� Estudio de la empresa: 6 horas.

� Análisis de requisitos: 10 horas.

� TOTAL: 16 horas.

• Elaboración del DOP:

� Redactar información: 10 horas.

� Descomposición de tareas: 5 horas.

� Asignación del tiempo de tarea: 3 horas.

� Elaborar el cuadro de mando: 3 horas.

� Digitalizar información del DOP: 3 horas.

� Revisiones de la planificación: 10 horas.


• Memoria:

� Redacción de la memoria: 30 horas.

7

� Generación de gráficos y diagramas: 30 horas.

� Digitalización de la memoria: 10 horas.


• Seguimiento:

� Reuniones con el cliente: 3 horas.

� Reuniones con el tutor: 10 horas.

� Levantar actas: 3horas.


• Análisis de requisitos:

� Creación de casos de uso: 10 horas.

� Análisis de clases: 2 horas.

� Análisis de la interfaz: 2 horas.

� Análisis de pruebas: 1 hora.

� Digitalizar diagramas creados: 5 horas.


• Diseño:

� Crear diagramas de clases: 10 horas.

� Digitalizar los diagramas creados: 5 horas.


• Diseño de la base de datos:

� Diseño de la base de datos (en papel): 10 horas.

� Diagrama de la base de datos (en UML): 10 horas.

� Descripción de las tablas: 10 horas.

� Digitalización: 5 horas


• Diseño del interface:

� Módulo de seguridad: 2 horas.

� Pantalla de ventas: 2 horas.

� Pantalla de inicio del módulo de gestión: 2 horas.

8

� Módulo de familias: 2 horas.

� Módulo de productos: 2 horas.

� Módulo de camareros: 2 horas.

� Módulo de ventas: 2 horas.

� Módulo de cierre de caja: 2 horas.

� Módulo de informes: 2 horas.

� Módulo de configuración: 2 horas.

� Realización de un prototipo: 15 horas.


• Implementación:

� Módulo de seguridad: 20 horas.

� Pantalla de ventas: 20 horas.

� Pantalla de inicio del módulo de gestión: 20 horas.

� Módulo de familias: 20 horas.

� Módulo de productos: 20 horas.

� Módulo de camareros: 20 horas.

� Módulo de ventas: 20 horas.

� Módulo de cierre de caja: 20 horas.

� Módulo de informes: 20 horas.

� Módulo de configuración: 20 horas

� Creación de un prototipo y ajustes (si fuese necesario):40 horas.


• Pruebas:

� Módulo de seguridad: 1 hora.

� Pantalla de ventas: 1 hora.

� Pantalla de inicio del módulo de gestión: 1 hora.

� Módulo de familias: 1 hora.

� Módulo de productos: 1 hora.

� Módulo de camareros: 1 hora.

� Módulo de ventas: 1 hora.

� Módulo de cierre de caja: 1 hora.

9

� Módulo de informes: 1 hora.

� Módulo de configuración: 1 hora.


• Instalación de la aplicación:

� Creación de un ejecutable: 10 horas.

� Instalación en la empresa: 5 horas.

� Lanzar batería de pruebas de integración y retocar (si fuese necesario):

15 horas.


• Preparar defensa:

� Crear presentación: 20 horas.

� Ensayos y revisión: 5 horas.


En total suman 548 horas.

1.6 Plan de trabajo

Se ha creado un plan inicial de trabajo a seguir durante el desarrollo del

proyecto.

En él se recoge el tiempo estimado para cada tarea y las fechas de inicio y

finalización.

El siguiente diagrama de Gantt muestra el plan de trabajo elaborado:

10

23/09 24/09Conocimientos previos

13/10 15/10Análisis de Requisitos iniciales

27/09 07/10Elaboración del DOP

13/10 17/03Memoria

30/09 16/03Seguimiento

15/10 02/11Análisis de requisitos

03/11 08/11Diseño

09/11 26/11Diseño de la BD

29/11 16/12Diseño del interface

20/12 15/03Implementación

16/03 18/03Pruebas

21/03 28/03Intalación

15 18 21 24 27 30 03 06 09 12 15 18 21 24 27 30 02 05 08 11 14 17 20 23 26 29 02 05 08 11 14 17 20 23 26 29 01 04 07 10 13 16 19 22 25 28 31 03 06 09 12 15 18 21 24 27 02 05 08 11 14 17 20 23 26 29 01 04 07octubre 2010 noviembre 2010 diciembre 2010 enero 2011 febrero 2011 marzo 2011 abril 2011

11

1.7 Riesgos

• Enfermedad o accidente:

En cualquiera de los 2 casos, si fuese necesario se haría una replanificación del

proyecto.

• Cambios en las especificaciones:

Según los nuevos requisitos se procedería a una replanificación del proyecto, en

caso de que lo ya planificado no sea consecuente con los nuevos requisitos, o a una

ampliación posterior, en el caso contrario.

• Estimaciones mal realizadas:

En caso de que sean por defecto, usaremos los días libres para cubrir las malas

estimaciones. Si fuesen por exceso, se aprovecharía para adelantar trabajo en

previsión de una mala estimación posterior.

• Cambios en el horario de trabajo:

Se ha previsto este riesgo dejando una holgura a la hora de la entrega, para ajustes

finales. Y en caso de que el cambio en el horario fuera extremo, la fecha de entrega

se prolongaría.

• Errores de diseño:

Si hubiese algún error de diseño se documentarán los fallos y se reajustará la

planificación de acuerdo al nuevo diseño.

• Daños software:

Para solucionar posibles daños en el software se crearan varias copias de seguridad

del proyecto durante su realización.

• Suspensión del proyecto por la empresa:

En este caso el proyecto se continuaría con fines académicos hasta lo expuesto en

el alcance.

12

2. ANALISIS

2.1 Análisis de requisitos

2.1.1 Identificación de actores

Se distingue entre 3 tipos de actores:

• Usuario: solo tiene acceso a la pantalla de ventas, por lo que solo podrá desarrollar

los casos de uso que se apliquen en ella.

• Encargado: tiene acceso tanto a la pantalla de ventas como al módulo de gestión,

pero no al acceso como administrador, por lo que podrá desarrollar todos los casos

de uso del usuario además de los suyos propios.

• Administrador: tiene acceso total a la aplicación, y es el único puede realizar todos

los casos de uso.

2.1.2 Identificación de los casos de uso

Diagrama de casos de uso

13

ESPECIFICACIÓN DE LOS CASOS DE USO

1. Identificación del administrador

Objetivo: Identificarse como administrador para acceder al módulo de gestión.

Actores: Administrador(A).

Pasos:

1.A.: El caso de uso se inicia cuando el administrador abre el módulo de gestión

de la aplicación.

2.S.: Solicita la contraseña del encargado.

3.A.: Pulsa el enlace para el administrador.

4.S.: Muestra la pantalla de login del administrador.

5.A.: Introduce la contraseña.

6.S.: Valida la contraseña del administrador.

7.S.: Da acceso al menú principal del módulo de gestión.

Extensiones:

5.1. La contraseña introducida no es correcta.

5.1.1.S.: Muestra una ventana de error.

5.1.2.S.: Vuelve al flujo principal en el paso 4.

Diagrama de Actividad:

14

2. Cambiar contraseña administrador

Objetivo: Modificar la contraseña actual del administrador.

Actores: Administrador(A).

Precondiciones: El administrador debe haberse identificado correctamente para poder

acceder al menú principal.

Pasos:

1.A.: El caso de uso se inicia cuando el administrador accede al módulo de

seguridad.

2.S.: Muestra la pantalla de gestión de seguridad.

3.A.: Selecciona “Cambiar contraseña del administrador”.

4.S.: Muestra la pantalla de introducción de la nueva contraseña.

5.A.: Introduce la nueva contraseña.

6.S.: Registra la nueva contraseña.

Diagrama de actividad:

15

3. Cambiar contraseña encargado

Objetivo: Modificar la contraseña actual del encargado, ya sea por el administrador o

por el propio encargado.

Actores: Encargado (E), y por extensión también el Administrador(A).

Precondiciones: El actor debe haberse identificado correctamente, bien como

encargado o bien como administrador, para haber accedido al menú principal.

Pasos:

1.E.: El caso de uso se inicia cuando el encargado (ó administrador) accede

al módulo de seguridad.

2.S.: Muestra la pantalla de gestión de seguridad.

3.E.: Selecciona “Cambiar contraseña del encargado”.

4.S.: Muestra la pantalla de introducción de la nueva contraseña.

5.E.: Introduce la nueva contraseña.

6.S.: Registra la nueva contraseña.


16

4. Identificación encargado

Objetivo: Identificarse como encargado para acceder al módulo de gestión.

Actores: Encargado (E).

Pasos:

1.E.: El caso de uso se inicia cuando el encargado abre el módulo de gestión de la

aplicación.

2.S.: Solicita la contraseña del encargado.

3.E.: Introduce su contraseña.

4.S.: Valida la contraseña del encargado.

5.S.: Da acceso al menú principal del módulo de gestión.

Extensiones:

3.1. La contraseña introducida no es correcta.

3.1.1.S.: Muestra una ventana de error.



17

5. Gestionar familias

Objetivo: Agregar, modificar y/o eliminar familias a la pantalla de ventas.

Actores: Encargado (E), y por extensión también el administrador(A).


encargado ó bien como administrador, para haber accedido al menú principal.

Pasos:

1.E.: El caso de uso se inicia cuando el encargado (ó administrador) abre el

módulo de gestión de familias.

2.S.: Muestra el formulario de familias.

3.E.: Pulsa ver lista de familias.

4.S.: Muestra la lista de familias

5.E.: Selecciona la familia deseada y acepta.

6.S.: Muestra todos los datos de la familia seleccionada.

7.E.: Modifica los datos de la familia seleccionada.

8.S.: Registra los nuevos datos de la familia

Extensiones:

5.1. No existe la familia que buscamos y deseamos crearla.

5.1.1.E.: Pulsa el botón “Volver”.

5.1.2.S.: Muestra el formulario de familias.

5.1.3.E.: Introduce los datos de la nueva familia.

5.1.4.E.: Pulsa añadir para crear una nueva familia.


5.1.2 No desea crear una nueva familia

5.1.2.1.E.: Pulsa volver.

5.1.2.2.S.: Finaliza el caso de uso.

7.1. Deseamos eliminar la familia.

7.1.1.E.: Selecciona eliminar familia.

7.1.2.S.: Elimina los datos de la familia seleccionada.

7.1.3.S.: Finaliza el caso de uso.


18

19

6. Gestionar productos

Objetivo: Agregar, modificar y eliminar productos a la pantalla de ventas.



administrador ó bien como encargado, para haber accedido al menú principal.

Pasos:


módulo de gestión de productos.

2.E.: Muestra el formulario de productos.

3.E.: Pulsar ver lista de productos.

4.S.: Muestra lista de productos.

5.E.: Selecciona el producto deseado y acepta.

6.S.: Muestra todos los datos del producto.

7.E.: Modifica los datos del producto.

8.S.: Registra los nuevos datos del producto.

Extensiones:

5.1. No existe el producto que buscamos y desea crearlo

5.1.1.E.: Pulsa el botón “Volver”.

5.1.2.S.: Muestra el formulario de productos.

5.1.3.E.: Introduce los datos del nuevo producto.

5.1.4.E.: Pulsa añadir para crear un nuevo producto.


5.1.2 No desea crear un nuevo producto.

5.1.2.1.E.: Pulsa volver.

5.1.2.2.S.: Finaliza el caso de uso.

7.1. Deseamos eliminar el producto.

7.1.1.E.: Selecciona eliminar producto.

7.1.2.S.: Elimina los datos del producto seleccionado.



20

21

7. Gestionar camareros

Objetivo: Definir el número de camareros a poder identificar en la pantalla de ventas,

con opción de poder añadir sus identidades.



administrador ó bien como encargado, para haber accedido al menú principal.

Pasos:


módulo de gestión de camareros.

2.S.: Muestra el formulario para el número de camareros.

3.E.: Introduce el número de camareros y acepta.

4.S.: Registra el número de camareros.

Extensiones:

4.1. Se quiere identificar a los camareros.

4.1.1.E.: Pulsa “Identificar camareros”.

4.1.2.S.: Muestra el formulario de identificación de camareros.

4.1.3.E.: Introduce datos camareros y pulsa “Aceptar”.

4.1.4.S.: Registra datos de los camareros.



22

8. Eliminar venta confirmada

Objetivo: Eliminar o imprimir una venta que ya ha sido confirmada.




Pasos:


módulo de gestión de ventas.

2.S.: Muestra la lista de ventas diarias.

3.E.: Selecciona la venta deseada y pulsa “Eliminar”.

4.S.: Muestra la ventana de seguridad.

5.E.: Acepta eliminar venta.

6.S.: Elimina la venta seleccionada.

Extensiones:

3.1. La venta no se encuentra.


3.2. Deseamos imprimir la venta.

3.2.1.E.: Selecciona la venta deseada y pulsa la opción “Imprimir”.

3.2.2.S.: Volver al flujo principal en el paso 3.


23

9. Hacer cierre de caja

Objetivo: Hacer el cierre de caja del día.



encargado o bien como administrador, para haber accedido al menú principal.

Pasos:


módulo de cierre de caja.

2.S.: Muestra el total de caja en el momento actual y las opciones.

3.E.: Pulsa “Cerrar caja”.

4.S.: Muestra la ventana de seguridad.

5.E.: Acepta cerrar caja.

6.S.: Almacena el total de caja y lo actualiza a 0.

Extensiones:

3.1. Deseamos imprimir el cierre de caja.

3.1.1.E.: Pulsa “Imprimir”.

3.1.2.S.: Imprimir el comprobante del cierre de caja.


3.2. No deseamos hacer aún el cierre de caja.

3.2.1.E.: Pulsa “Volver”.



24

10. Sacar informes

Objetivo: Obtener informes y estadísticas sobre ventas, I.V.A., productos y familias, o

listados de los componentes de familias, productos, camareros y ventas.




Pasos:

1.E.: El caso de uso se inicia cuando el encargado (o administrador) abre el

módulo de gestión de informes.

2.S.: Muestra la pantalla con las opciones del informe que se desea.

3.E.: Pulsa la opción del informe deseado.

4.S.: Muestra el formulario con las opciones a rellenar para el informe.

5.E.: Muestra el informe en pantalla.

Extensiones:

3.1. Deseamos obtener un listado.

3.1.1.E.: Pulsa la opción de “listados”.

3.1.2.S.: Muestra la ventana de opciones de listados.

3.1.3.E.: Pulsa el listado deseado.

3.1.4.S.: Muestra las opciones del listado elegido.

3.1.5.E.: Selecciona las opciones que desea ver el listado y acepta.



25

11. Cambiar la configuración

Objetivo: Cambiar la configuración de la aplicación y la apariencia de la pantalla de

ventas.

Actores: Encargado (E), y por lo tanto también el administrador (A).

Precondiciones: El encargado (ó administrador) debe haberse identificado

correctamente para haber accedido al menú principal.

Pasos:

1.E.: El caso de uso se inicia cuando el encargado (ó administrador) accede al

módulo de “Configuración”.

2.S.: Muestra la pantalla con las opciones configurables.

3.E.: Selecciona la parte a configurar.

4.S.: Muestra el formulario de configuración de la parte seleccionada.

5.E.: Modifica el formulario y pulsa “Guardar cambios”.

6.S.: Almacena los datos modificados.

Extensiones:

4.1. No deseamos guardar las modificaciones.

4.1.1.E.: Pulsa “volver”.

4.1.2.S.: Fin del caso de uso.


26

12. Crear venta

Objetivo: Crear una venta desde el inicio hasta su confirmación, aplazamiento o

anulación.

Actores: Usuario (U), y por extensión también el encargado (E) y el administrador(A).

Precondiciones: La pantalla de ventas debe estar abierta.

Pasos:

1.U.: El caso de uso se inicia cuando el usuario (ó el encargado ó el

administrador) pulsa su tecla de identificación como camarero.

2.U.: Selecciona una familia.

3.S.: Muestra los productos de la familia seleccionada.

4.U.: Selecciona un producto.

5.S.: Registra la línea de venta, la muestra en la venta y modifica el total.

El usuario repite los pasos desde el 2 hasta el 5, hasta haber introducido todos

los productos de la venta.

6.U.: Confirma la venta.

7.S.: Registra la venta confirmada, muestra el total en otra ventanita.

Extensiones:

2.1. Venta de un producto no almacenado.

2.1.1.U.: Introduce el precio del producto.

2.1.2.S.: Muestra el valor introducido en la pantalla del teclado digital.

2.1.3.U.: Pulsa “Añadir” en el teclado digital.


2.2. Recuperar una venta aplazada.

2.2.1.U.: Selecciona botón de recuperar venta.

2.2.2.S.: Muestra en otra ventanita la lista de ventas aplazadas.

2.2.3.U.: Selecciona la venta a recuperar.

2.2.4.S.: Muestra la venta seleccionada en pantalla.

2.2.5.S.: Vuelve al flujo principal después del paso 5.

3.1. El número de unidades es menor al deseado.

3.1.1.U.: Pulsa el botón + para aumentar en uno el número de unidades.

27

Repetir este paso las veces que sean necesarias hasta obtener el

número de unidades deseado.


3.2. El número de unidades es mayor al deseado.

3.2.1.U.: Pulsa el botón – para disminuir en uno el número de unidades.

Repetir este paso las veces que sean necesarias hasta obtener el

número de unidades deseado.


5.1. Eliminar la línea de venta.

5.1.1.U.: Selecciona la línea de venta a eliminar y pulsa eliminar línea.

5.1.2.S.: Eliminar el registro de línea de venta y modifica el importe total en

pantalla.

5.1.3.S.: Vuelve al flujo principal después del paso 5.

5.2. Aplazar venta.

5.2.1.U.: Selecciona el botón “Aplazar venta”.

5.2.2.S.: Registra la venta como venta aplazada.


5.3. Anular la venta completa, sin confirmar.

5.3.1.U.: Pulsar botón “Anular venta”.

5.3.2.S.: Elimina el registro de venta completo.


5.4. Imprimir ticket de venta.

5.4.1.U.: Pulsar “Imprimir ticket”.

5.4.2.S.: Imprime el ticket de venta.



28

29

2.2 Análisis de clases

Será necesario crear las siguientes clases, con al menos los campos que se enumeran:

• Venta:

� Identificador: numérico y único para cada venta.

� Camarero: clase a crear.

� Fecha (incluye hora): Date.

� Lista de líneas de venta: clase a crear.

� IVA: numérico y con 2 decimales.

� Importe: numérico y con 2 decimales.

� Total: numérico y con 2 decimales.

� Estado: texto.

• Línea de venta:

� Producto: clase a crear.

� Unidades: numérico.

� Venta: clase a crear.

� Total: numérico y con 2 decimales.

• Producto:

� Identificador: numérico y único para cada producto.

� Nombre: texto.

� Familia: clase a crear.

� Precio: numérico y con 2 decimales.

� Imagen: texto (opcional).

• Familia:

� Identificador: numérico y único para cada familia.

� Nombre: texto.

� Imagen: texto (opcional).

• Camarero:

� Identificador: texto.

� Nombre: texto.

30

2.3 Análisis de la interfaz

Debemos diferenciar entre los 2 módulos del programa:

• Pantalla de ventas:

La pantalla debería estar siempre maximizada, es decir, ocupar toda la pantalla del

ordenador y dividida en varios espacios:

� Un espacio para las familias, con un botón por familia.

� Un espacio para los productos, con un botón por producto, donde

mostrar todos los productos de la familia seleccionada.

� Un espacio donde mostrar la venta activa, siempre visible. Con un

espacio para el total.

� Un espacio para los botones de identificación de los camareros.

� Un espacio para los botones que controlan la venta activa: aplazar,

recuperar, anular venta, eliminar línea, confirmar venta e imprimir ticket.

� Un espacio para los botones que controlan los productos: número de

unidades, añadir unidad, disminuir unidad y añadir producto de precio directo.

• Módulo de gestión:

� Las pantallas del módulo de gestión se deben poder minimizar, maximizar y

cerrar en cualquier momento.

� Después cada menú debe tener su propio diseño:

� Acceso al módulo de gestión: debe contener un cuadro de texto para

introducir la contraseña del encargado, un botón para validarla y el enlace al

acceso de administrador.

� Acceso del administrador: debe contener un cuadro de texto para

introducir la contraseña del encargado, un botón para validarla.

� Menú principal: contendrá 8 botones de acceso, uno para cada módulo

del programa.

� Módulo de seguridad: contendrá 2 botones de acceso a la pantalla de

cambio de contraseña. Pero el de cambio de contraseña de administrador no

estará siempre activo.

31

� Módulo de gestión de familias: debe contener un formulario para

introducir los datos, además de los botones de aceptar, mostrar lista, modificar

y eliminar.

� Módulo de gestión de productos: será similar al módulo de gestión de

familias, pero con diferente formulario.

� Módulo de gestión de camareros: debe contener un cuadro de texto

para introducir el número de camareros y 2 botones, aceptar e identificar.

� Módulo de gestión de ventas: debe contener una lista con las ventas

diarias y 2 botones, eliminar e imprimir.

� Módulo de cierre de caja: debe mostrar un formulario con los datos del

balance, no modificable y 2 botones para imprimir el balance o hacer el cierre

de caja.

� Módulo de gestión de informes: debe contener 4 botones que dan

acceso cada uno a un formulario para introducir los datos del informe

seleccionado.

� Módulo de configuración: debe contener 4 botones que dan acceso

cada uno a un formulario diferente en el que modificar la configuración del

programa.

� Varias de las pantallas descritas darán acceso a otras pantallas aún sin

determinar, pero con diseño similar.

2.4 Análisis de pruebas

Se debe hacer diferentes pruebas para cada parte de la aplicación:

• En el acceso al módulo de gestión:

� Intentar acceder como encargado con diferentes contraseñas.

� Intentar acceder como administrador con diferentes contraseñas.

• En el módulo de seguridad:

� Intentar cambiar, identificado como encargado, la contraseña del

administrador.

� Cambiar, identificado como administrador, la contraseña del encargado,

y después, intentar acceder, como encargado, con la contraseña vieja.

32

� Cambiar contraseña del encargado, identificado como encargado, y

después, intentar acceder como encargado con la contraseña vieja.

• En el módulo de gestión de familias:

� Crear una familia nueva, modificarla y después eliminarla.

• En el módulo de gestión de productos:

� Crear un producto nuevo, modificarlo y eliminarlo.

• En el módulo de gestión de camareros:

� Cambiar el número de camareros y probar a identificarlos.

• En el módulo de gestión de ventas:

� Seleccionar venta, imprimirla y eliminarla.

• En el módulo de gestión de informes:

� Rellenar el formulario cada formulario varias veces y con diferentes

datos y guardar e imprimir los informes resultantes.

• Imprimir varios balances de caja antes de cerrar la caja.

� Cerrar la caja y comprobar el nuevo balance del día.

• En la pantalla de ventas:

� Intentar crear una venta sin seleccionar un camarero.

� Crear venta con varios productos de diferentes familias y anularla.

� Crear venta con productos varios de precio directo y productos con más

de 1 unidad y confirmarla.

� Crear venta y aplazarla. Después recuperarla y añadir más productos.

Imprimir el ticket de venta.

� Crear venta, seleccionar una línea de venta y eliminarla. Confirmar la

venta.

33

3. DISEÑO

3.1 Arquitectura del sistema

En un principio el desarrollo de la aplicación se basó en una arquitectura de 3

unidades funcionales (o capas) bien diferenciadas, cuyo esquema es:

• La capa de presentación

Se encarga de la presentación con la que se encuentra el usuario, en nuestro caso

está formada por todas las interfaces gráficas tanto de la aplicación de gestión

como de la pantalla de ventas.

• La capa de lógica de negocio

Es el núcleo del sistema en el que se realizará las operaciones y cálculos necesarios

para el funcionamiento de la aplicación. Estás formada por aquellos

procedimientos que albergan las diferentes funciones a utilizar por la aplicación.

• La capa de persistencia

• Se encarga del acceso a los sistemas de almacenamiento, independizando la

aplicación del sistema de persistencia (en nuestro caso la base de datos). Estará

formada por las funciones de acceso a la base de datos y a sus respectivas tablas.

Al continuar con el desarrollo de la aplicación se comprobó que era más

eficiente basarse en una actualización (o evolución) de esta arquitectura, la cual

mantiene las 2 primeras capas e introduce otras 3 capas más, obteniendo así una

nueva arquitectura de 5 capas, cuyo esquema es:

34

• Capa de presentación (UI - User Interface)

Como en la arquitectura anterior, está compuesta por las interfaces gráficas con las

que se encuentra el usuario final. En la aplicación los paquetes

“APlicacionGestionTPV “ y “PantallaVentas” comprenden esta capa.

• Capa de lógica de negocio (BLL - Bussines Logic Layer)

Aunque mantiene el nombre de la arquitectura anterior sus funciones se reducen a

presentar una “interfaz” para brindar servicios a la capa de presentación, es decir,

el intermediario entre la capa de representación y las capas de acceso a los datos y

entidades. Comprende los paquetes “Logica” de ambas soluciones en la aplicación.

• Capa de acceso a los datos (DAL - Data Access Layer)

Es una porción del código que realiza justamente el acceso a los datos. De esta

manera, cuando es necesario cambiar el motor de la base de datos, solo tendremos

que corregir esta capa. En la aplicación comprende los paquetes “Persistencia” de

ambas soluciones.

• Capa de entidades(Domain – Entity Layer)

Corresponde al dominio de la aplicación. En ella se encuentra la declaración de las

entidades de la aplicación de manera que se puedan referenciar desde otras capas

sin entrar en ciclos recursivos de compilación. Comprende el paquete

“ClasesBasicas” en la aplicación.

• Capa de datos (Data Tier)

Es donde están los datos y se corresponde directamente con la definición de

esquemas, tablas, vistas, procedimientos almacenados y todo lo que se pueda o

35

deba poner en un motor de base de datos. Equivalente a la base de datos

“pubchandro” en la aplicación.

Esta arquitectura permite total independencia entre la lógica de negocios y las

entidades. Por supuesto que ambas están relacionadas por los casos de uso y otros

requerimientos de la aplicación.

Por otro lado, este esquema facilita la incorporación, en la capa de acceso a

datos, de componentes ORM (Object/Relational Mapping) que permiten “mapear”

(representa) objetos en un esquema relacional. Esto funciona bien dado que nuestra

base de datos, al igual que la mayoría de las bases de datos usadas actualmente, es

relacional.

3.2 Diseño de la interfaz

Las características deseables para la interfaz de usuario son:

• Fácil de utilizar.

• Intuitiva.

• Segura.

• Permitir deshacer una acción siempre que sea posible.

• Permitir cancelar la realización de la acción.

• Tiene que ser totalmente táctil.

Además de esas características se debe recordar que tenemos dos partes

totalmente diferenciadas:

• La pantalla de ventas.

• La aplicación de gestión.

Ambas deben cumplir las características ya citadas.

Para poder introducir los datos debemos utilizar el teclado en pantalla que nos

facilita Windows.

Diagrama de interconexión de pantallas de la Pantalla de Ventas

36

Diagrama de interconexión de pantallas de la aplicación de gestión

Pantalla de ventas

Como vemos en la imagen anterior hay 6 zonas diferenciadas:

• Zona de familias (superior derecha):

Cada botón representa una familia, pudiendo visualizar más familias pulsando

las teclas de desplazamiento (“<<” y ”>>”).

37

Al pulsar en una familia, si hay un camarero seleccionado, la zona de productos

mostrará los productos asociados a la familia seleccionada.

• Zona de productos (central derecha):

Cada botón representa un producto, pudiendo visualizar más productos

pulsando las teclas de desplazamiento (“<<” y ”>>”).

Al pulsar en un producto, si hay un camarero seleccionado, se escribe una

nueva línea de producto en la zona de venta, y añade el precio de la línea de venta al

total.

• Zona de camareros (superior izquierda):

Cada botón representa un camarero pudiendo visualizar más camareros

pulsando las teclas de desplazamiento (“<<” y “>>”).

Al pulsar un camarero, si no hay ya ninguno seleccionado, se selecciona el

camarero que inicia la venta.

• Zona de venta (central izquierda):

Muestra los productos añadidos a la venta, en líneas de venta, que se pueden

seleccionar, para ser eliminada.

Además también muestra el total de la venta.

• Zona del teclado numérico:

Solo se activa cuando hay un camarero seleccionado y su funcionamiento es

similar al de una calculadora, se marca el precio deseado y al pulsar añadir se muestra

una nueva línea de producto en la zona de venta, con el producto “varios”.

También sirve para modificar el número de unidades del producto a añadir

seleccionando la pantallita de unidades y después pulsando el valor deseado.

• Zona de botones:(inferior derecha):

Contiene una pantallita con el número de unidades y 8 botones, cada uno con

una función propia:

Aplazar: aplaza la venta actual, mostrando el total.

Recuperar: si no hay venta actual y se ha seleccionado un camarero, muestra la

lista de ventas aplazadas.

Anular: anula la venta actual.

38

Eliminar línea: si hay una línea de producto seleccionada, la elimina y reduce su

precio del total.

Aceptar: confirma la venta y muestra el total.

Imprimir ticket: confirma la venta, muestra el total y manda la impresión del

ticket de venta.

Botón +: aumenta en 1 el número de unidades.

Botón - : disminuye en 1 el número de unidades, pero nunca baja de 1.

Ventana total

No se puede modificar y basta pulsar sobre ella para que se cierre.

Pantalla de inicio de la aplicación

Tiene 2 botones:

Aceptar: que validará la contraseña dando o no paso al menú principal.

39

Salir: que cierra la aplicación.

Además de un enlace “Administrador”, que lleva a la pantalla de identificación

del administrador...

Pantalla de identificación del administrador

Similar a la anterior pero con un botón para volver a la pantalla anterior, la

pantalla de inicio y sin el enlace que da acceso a ella.

Pantalla del menú principal

Dispone de 9 botones:

Gestión de Seguridad: da acceso al módulo de seguridad.

Gestión de Familias: da acceso al módulo de familias.

Gestión de Productos: da acceso al módulo de productos.

Gestión de Camareros: da acceso al módulo de camareros.

Gestión de Ventas: da acceso al módulo de ventas.

Cierre de Caja: da acceso al módulo de cierre de caja.

Gestión de Informes: da acceso al módulo de informes y estadísticas.

40

Configuración: da acceso al módulo de configuración de la aplicación.

Volver: vuelve a la ventana anterior, la pantalla de acceso a la aplicación.

Pantalla principal del módulo de gestión seguridad

Muestra 2 botones de acceso a la pantalla de cambio de contraseña. El

referente al encargado, siempre activado, y el referente al administrador, solo activado

cuando el usuario se haya identificado como administrador.

Además también dispone del botón para volver a la pantalla del menú

principal.

Pantalla de cambio de contraseña

41

Contiene 2 cuadros de texto, para introducir la nueva contraseña, y 2 botones:

uno para guardarla y otro para volver a la pantalla principal del módulo de seguridad.

Pantalla principal del módulo de gestión de familias

Además del formulario para creación o modificación de una familia, contiene

varios botones:

Lupa: abre una lista de familias ya existentes.

Examinar: abre el cuadro de diálogo para buscar un archivo.

Añadir: muestra una pantalla de seguridad informando de la familia se ha

creado.

Modificar: permite guardar los cambios realizados. Mostrará una pantalla de

seguridad que pregunte si desea guardar los cambios.

Eliminar: permite eliminar permanentemente una familia. Mostrará un mensaje

de seguridad que pregunte si desee eliminarla permanentemente.

Volver: permite volver al menú principal.

Pantalla de listado

Aparece al pulsar cualquiera de los botones lupa de los módulos de familias y

productos.

42

Dispone de un listado cuyos elementos son seleccionables, un botón para

volver al formulario sin seleccionar ninguno y si el listado supera los 8 elementos una

barra de scroll para ver el listado completo.

Pantalla principal del módulo de gestión de productos

La pantalla es similar a la de gestión de familias, aunque con diferente

formulario, y además incluye otro botón “lupa” para ver una lista de los productos ya

existentes.

43

Pantalla principal del módulo de gestión de camareros

La pantalla contiene un cuadro de texto donde introducir el número de

camareros a mostrar en la pantalla de ventas, además de 3 botones:

Identificar camareros: que da acceso a la pantalla de identificación de

camareros.

Aceptar: que guarda los cambios y vuelve a menú principal.

Volver: que vuelve al menú principal sin guardar los cambios.

Pantalla de identificación de camareros

Muestra una lista con el número de elementos igual número de camareros,

seleccionables y modificables, además de 2 botones:

Volver: que vuelve a la pantalla principal del módulo de gestión de camareros

sin guardar los cambios.

Aceptar: que guarda los cambios y después vuelve a la pantalla principal del

módulo de gestión de camareros.

44

Pantalla principal del módulo de gestión de ventas

Muestra una lista con las ventas diarias, seleccionables, y 3 botones:

Volver: vuelve al menú principal.

Imprimir: imprime un ticket de venta en la impresora especificada en la

ventana de configuración del ticket de venta con los datos de la venta seleccionada.

45

Eliminar: muestra un mensaje de seguridad que pregunta si está seguro de

eliminarla.

Pantalla principal del módulo de cierre de caja

Muestra en un cuadro de texto, no modificable, el balance de caja desde el

último cierre de caja hasta ahora, y 3 botones:

Volver: vuelve al menú principal.

Imprimir: muestra en un pdf el cierre de caja listo para imprimirlo o guardarlo.

Cerrar caja: realiza el cierre de caja, pasa las ventas diarias al histórico dejando

el balance a 0 y muestra el cierre de caja en un pdf listo para imprimirlo o guardarlo en

un archivo.

Pantalla principal del módulo de gestión de informes

Contiene 6 botones, los cuatro primeros dan acceso al formulario del informe

seleccionado, el quinto, a la pantalla del menú de listados y el sexto permite volver al

menú principal.

46

Pantalla del formulario de informe de ventas

La pantalla contiene unos cuadros de texto para introducir las fechas inicial y

final del informe, 2 casillas seleccionables para tomar las fechas iniciales y finales del

47

programa, un listado donde se muestran los camareros candidatos seleccionables, y

otro donde se muestren los ya seleccionados, y 5 botones:

Eliminar: al pulsarlo muestra la misma pantalla eliminando el camarero

seleccionado del listado de los ya seleccionados y lo muestra en el de candidatos.

Seleccionar: al pulsarlo muestra la pantalla igual pero añade los camareros

seleccionados al listado de los seleccionados, eliminándolos del listado de candidatos.

Todos: al pulsarlo muestra a todos los camareros en el listado camareros

seleccionados y los elimina del de candidatos.

Aceptar: muestra el resultado del informe en un pdf listo para imprimir o

guardar en un archivo.

Volver: vuelve a la pantalla principal de gestión de informes.

Pantalla del formulario de informe de familias

Su funcionamiento es igual a la pantalla anterior, pero en el listado ahora se

mostrarán las familias.

48

Pantalla del formulario de informe de productos

Su funcionamiento es igual a las 2 pantallas anteriores, pero en el listado ahora

se mostrarán los productos.

Pantalla del formulario de informe de I.V.A.

49

Contiene unos cuadros de texto donde introducir las fechas inicial y final y 2

botones:

Aceptar: muestra el informe en un pdf, listo para imprimir o guardar en un

archivo, si las fechas son correctas o un mensaje de error, si son erróneas.

Volver: vuelve a la pantalla principal de gestión de informes.

Pantalla del menú de listados

Contiene 5 botones y, excepto “Volver” y “Camareros”, todos llevan a un nuevo

formulario con las opciones a mostrar en el listado elegido.

El botón “Volver” lleva a la pantalla principal del módulo de gestión de informes

y el botón “Camareros” muestra directamente un pdf con el listado de camareros, listo

para imprimir o guardar en un archivo.

Pantalla del formulario de opciones para el listado de familias

Muestra las opciones a mostrar en el listado, el botón “Volver” que lleva a la

pantalla del menú de listados y el botón “Aceptar” que muestra en un pdf el listado de

familias, listo para imprimir o guardar en un archivo.

50

Pantalla del formulario de opciones para el listado de productos

El formulario es igual al anterior, pero con las opciones aplicables al listado de

productos.

Pantalla del formulario de opciones para el listado de ventas diarias

El formulario es igual a los 2 anteriores, pero con las opciones aplicables al

listado de ventas diarias.

51

Pantalla principal del módulo de configuración

El formulario contiene 3 botones que llevan cada uno a su pantalla de

configuración, según el botón seleccionado, y un cuarto botón que lleva de vuelta al

menú principal

52

Pantalla de configuración de la apariencia del ticket de venta

Muestra el formulario de configuración del ticket de venta y los botones para

guardar los cambios y volver a la pantalla principal del módulo de configuración.

Pantalla de configuración de la apariencia del comprobante de cierre de caja

Como la pantalla anterior, muestra el formulario de configuración del ticket de

venta y los botones para guardar los cambios y volver a la pantalla principal del

módulo de configuración

53

Pantalla de configuración de la apariencia de informes y listados

Como las 2 pantallas anteriores, muestra el formulario de configuración del

ticket de venta y los botones para guardar los cambios y volver a la pantalla principal

del módulo de configuración.

3.3 Diseño de las clases

Las clases a diseñar, según el análisis son: familia, producto, venta, lineaVenta y

camarero, junto con sus atributos y métodos.

Familia

La clase Familia representa a las familias en las que clasifica a los productos a la

venta en el establecimiento.

Como atributos debe tener un identificador único, su descripción, una imagen

(opcional) y la lista de los productos que pertenecen a dicha familia.

Sus métodos deben permitir crearla, obtener y modificar sus atributos y

eliminarla.

Familia

- codigo: int - descripcion: string - imagen: string - productos: List<Producto>

+ Familia(int cod, string nombre, String icono): Familia + Familia(string nombre, string icono): Familia

54

+ Familia(int cod, string nombre): Familia + Familia(string nombre): Familia + getCodigo(): int + getDescripcion(): string + setDescripcion(string nombre): void + getImagen(): string + setImagen(string icono): void + getProductos(): List<Producto> + añadirProducto(Producto prod): void + eliminarProducto(Producto prod): void + eliminar(int codigo): void + numProductos(int codigo): int + getFamilia(int codigo): Familia + getFamilia(string nombre): Familia + estaFamilia(int codigo): Boolean + modificarFamilia(int codigo, string nombre, string icono): void + Equals(Familia f): Boolean + listFamilias(): List<Familia>

Producto

La clase Producto representa a cada artículo a la venta en el establecimiento.

Como atributos debe tener un identificador único, su descripción, la familia a la

que pertenece, una imagen (opcional) y su precio.

Sus métodos deben permitir crearlo, obtener y modificar sus atributos y

eliminarlo.

Producto

- codigo: int - descripcion: string - familia: Familia - imagen: string - precio: decimal

+ Producto(int cod, string nombre, string icono, Familia fam, decimal pvp): Producto

+ Producto(string nombre, string icono, Familia fam, decimal pvp): Producto + Producto(int cod, string nombre, string icono, Familia fam): Producto + Producto(string nombre, string icono, Familia fam): Producto + Producto(int cod, string nombre, Familia fam, decimal pvp): Producto + Producto(string nombre, Familia fam, decimal pvp): Producto + Producto(int cod, string nombre, Familia fam): Producto + Producto(string nombre, Familia fam): Producto + getCodigo(): int + getDescripcion(): string + setDescripcion(string nombre): void

55

+ getPrecio(): decimal + setPrecio(decimal pvp): void + getImagen(): string + setImagen(string icono): void + getFamilia(): Familia + setFamilia(Familia fam): void + eliminar(int codigo): void + getProducto(string nombre): Producto + getProducto(int codigo): Producto + estaProducto(int codigo): Boolean + Equals(Producto p): Boolean + añadirProducto( Producto p): Boolean + modificarProducto(int cod, string nom, string icono, Familia fam, decimal pvp):

void + productos(): List<string> + listProductos(): List<Producto>

Camarero

La clase Camarero representa a los empleados del establecimiento, es decir, los

usuarios finales de la pantalla de ventas.

Como atributos tiene un identificador único y su nombre (opcional).

Sus métodos deben permitir crear un camarero, añadirle su nombre, obtener

sus atributos y eliminarlo.

Camarero

- codigo: string - nombre: string

+ Camarero(int num): Camarero + getCodigo(): string + getNombre(): string + setNombre(string nombre): void + eliminar(string codigo): void + Equals(Camarero c): Boolean + numCamareros(): int + maxCamareros(): int + getCamarero(string cod): Camarero + añadirCamarero(Camarero c): void + guardarCamareros(List<string> lista): void + camareros(): List<string>

56

LineaVenta

La clase LineaVenta representa a las líneas de artículos vendidos que

componen cada venta.

Como atributos tiene un identificador único, el artículo a vender, las unidades

vendidas, el importe total de dicho artículo y la venta a la que pertenece.

Sus métodos deben permitir crearla, eliminarla y obtener sus atributos, pero no

modificarlos.

LineaVenta

- codigo: int - unidades: int - articulo: Producto - total: decimal - venta: Venta

+ LineaVenta(int uni, Producto prod, Venta venta): LineaVenta + LineaVenta(int codigo, int uni, Producto prod, decimal tot, Venta venta):

LineaVenta + getCodigo(): int + getUnidades(): int + getArticulo(): Producto + getTotal(): decimal + getVenta(): Venta + eliminar(int codigo): void + Equals(LineaVenta lv): Boolean + getLineasVenta(int venta): List<LineaVenta>

Venta

La clase Venta representa cada una de las ventas realizadas por un camarero.

Como atributos tiene un identificador único, el camarero que la crea, la fecha

de creación, su importe (base imponible), el I.V.A. y el total de ambos, además de las

líneas de venta y su estado.

Sus métodos deben permitir crear una venta, añadirle o eliminarle líneas de

venta, eliminarla entera, obtener sus atributos, aplazarla y recuperarla.

Venta

- codigo: int - camarero: Camarero - iva: decimal - importe: decimal - total: decimal - fecha: DateTime

57

- detalle: List<LineaVenta>

+ estado: char + Venta(int cod, Camarero cam, decimal iva, decimal base, decimal tot,

DateTime fecha) : Venta + Venta(Camarero cam): Venta + getCodigo(): int + getCamarero(): Camarero + setCamarero( Camarero cam): void + getIva(): decimal + setIva(decimal iva): void + getImporte(): decimal + setImporte(decimal base): void + getTotal(): decimal + setTotal(decimal tot): void + getFecha(): DateTime + setFecha(DateTime fecha): void + getDetalle(): List<LineaVenta> + setDetalle(List<LineaVenta> lista): void + añadirLinea(LineaVenta lv): void + eliminarLinea(LineaVenta lv):void + anular(int codigo): void + aplazar(int codigo): void + recuperar(Camarero cam, int codigo): Venta + confirmar(int codigo): void + ventas(): List<Ventas> + getVenta(int codigo): Venta

Una vez diseñadas las clases nos queda explicar la relación existente entre ellas:

• Una familia puede tener 0 o varios productos, pero un producto pertenece a una

sola familia.

• Un producto puede pertenecer a 0 o varias líneas de venta, pero una línea de

venta tiene un único producto.

• Una línea de venta pertenece a una única venta, pero una venta puede tener una o

varias líneas de venta.

• La existencia de una línea de venta no tiene sentido si no existe su venta.

• Una venta tiene un único camarero, pero un camarero puede tener 0 o varias

ventas.

Las relaciones entre las clases sustituyen algunos de los atributos, como se

puede observar en el siguiente diagrama.

58

Diagrama de clases

59

Además de las clases anteriores, obtenidas del análisis, también están las

necesarias para la implementación, que son: Informes, Ticket y Usuario, junto con sus

atributos y métodos.

Cierre

La clase representa la configuración del comprobante de cierre.

Como atributos tiene 2 booleanos que seleccionan la aparición de la cabecera

y el usuario, la cabecera (opcional) y la forma de representación de la fecha.

Sus métodos deben permitir obtener sus atributos y modificarlos.

Cierre

- cabecera: Boolean - textoCab: string - usuario: Boolean - tipoFecha: string

+ Cierre(Boolean cab, string text, Boolean user, string tf): Cierre + getCabecera(): Boolean + setCabecera(Boolean cab): void + getTextoCab(): string + setTextoCab(string texto): void + getUsuario(): Boolean + setUsuario(Boolean user): void + getTipoFecha(): string + setTipoFecha(string tf): void + getCierre(): Cierre + guardarCierre(Cierre c): void

Informes

La clase representa la configuración de los informes y listados.

Como atributos tiene un booleano que selecciona la aparición de la cabecera y

un texto de cabecera (opcional).

Sus métodos deben permitir obtener sus atributos y modificarlos.

Informes

- cabecera: Boolean - textoCab: string

+ Informes(int cab, string texto): Informes + getCabecera():Boolean + setCabecera(Boolean cab): void + getTextoCab(): string + setTextoCab(string tc): void

60

+ getInformes(): Informes + guardarInformes(Informes i): void

Usuario

La clase representa a los diferentes usuarios de la aplicación de gestión.

Como atributos tiene un usuario y una contraseña.

Sus métodos deben permitir obtener la contraseña de un usuario y modificarla.

Usuario

- tipo: string - password: string

+ getPassword(): string + setPassword(string p): void + getmodificarContraseña(string us, string p): void

Ticket

La clase representa la configuración del ticket de venta.

Como atributos tiene 3 booleanos que seleccionan la aparición de la cabecera,

el camarero y el pie de página, 3 textos: el de cabecera, el de pie de página y los datos

del establecimiento; el tipo de total a mostrar, el porcentaje de IVA y la impresora por

la que se imprimirá.

Sus métodos deben permitir obtener y modificar todos sus atributos.

Ticket

- cabecera: Boolean - textoCab: string - pie: Boolean - textoPie: string - camarero: Boolean - datos: string - tipoTotal: string - iva: decimal - impresora: string

+ getCabecera(): Boolean + setCabecera(Boolean c): void + getTextoCab(): string + setTextoCab(string texto): void + getPie(): Boolean + setPie(Boolean p): void + getTextoPie(): string

61

+ setTextoPie(string texto): void + getCamarero(): Boolean + setCamarero(Boolean c): void + getDatos(): string + setDatos(string d): void + getTipototal(): string + setTipoTotal(string tt): void + getIva():decimal + setIva(decimal iva): void + getTicket(): Ticket + guardarTicket(Ticket t): void

Estas nuevas clases no tienen interconexión entre ellas, ni con las anteriores.

3.4 Diseño de la base de datos

Se identificarán las necesidades de información de cada uno de los procesos

que conforman el sistema de información, con el fin de obtener un modelo de datos

que contemple todas las entidades, relaciones, atributos y reglas de negocio

necesarias para dar respuesta a dichas necesidades.

Diagrama conceptual de la base de datos

62

En base al diagrama anterior se han identificado las tablas de la base de datos

que derivan de sus clases:

FAMILIA

codigo descripcion imagen

C.P.

En la tabla Familia se usa como clave principal “codigo”, ya que es único para

cada familia.

PRODUCTO

codigo descripcion imagen precio codFam

C.P. C.F.FAMILIA

En la tabla Producto se usa como clave principal “codigo”, que es único para

cada producto. Y tenemos también una clave foránea “codFam” con el código de la

familia a la que pertenece.

LINEAVENTA

codigo codVenta unidades total codProd

C.P. C.F.VENTA C.F.PRODUCTO

En la tabla LineaVenta la clave principal está compuesta por el código de la

línea de venta, “codigo”, y la clave foránea “codVenta” que indica el código de la venta

a la que pertenece la línea, ya que lineaVenta es una entidad débil. Además hay una 2ª

clave foránea “codProd” la cual indica el código del producto implicado en la línea de

venta.

VENTA

codigo iva importe total fecha codCam estado

C.P. C.F.CAMARERO

En la tabla Venta la clave principal es “codigo”, único para cada producto.

Además hay una clave foránea “codCam”, que indica el código del camarero

que creó la venta.

CAMARERO

codigo nombre

C.P.

En la tabla camarero su clave principal será “código”, único para cada

camarero.

63

Además de las tablas derivadas de las clases también se debe de tener en

cuenta las derivadas del histórico:

HISTORICOVENTAS

codigo iva importe total fecha codCam estado

C.P. C.F.CAMARERO

Al igual que en la tabla venta, en la tabla historicoventas la clave principal es

“codigo” y tiene una clave foránea a la tabla camarero “codCam”.

HISTORICOLINEAVENTA

codigo codVenta unidades total codProd fecha

C.P. C.F.VENTA C.F.PRODUCTO

Al igual que en la tabla lineaVenta, la tabla historicolineaventa la clave principal

está compuesta por “codigo”, el código de la línea de venta y “codVenta” el código de

la venta a la que pertenece, que en este caso estaría ya en historicoventas. Y también

tiene una clave foránea a producto, “codProd”.

Y las tablas necesarias para el funcionamiento y configuración de la aplicación,

las cuales solo tendrían una sola fila (excepto usuario que tendrá 2).

USUARIO

tipo Contraseña

C.P.

La tabla usuario tiene como clave principal “tipo”, ya que es único para cada

fila.

TICKET

Cabecera textCab pie textPie camarero datos iva tipoTotal impresora

La tabla ticket no tiene una clave principal, ya que consta de una sola fila, por lo

que no necesita ser indexada.

CIERRE

cabecera textCab usuario tipoFecha

La tabla cierre consta de una única fila por lo que no necesita ser indexada, por

eso no tiene clave principal.

64

INFORMES

cabecera textCab

Al igual que las 2 tablas anteriores, la tabla informes no necesita ser indexada

porque solo contiene una sola fila, y por ello no tiene clave principal.

La base de datos no tiene atributos multivaluados, con lo cual está en 1FN, hay

una sola clave única en cada tabla, ya está en 2FN, no hay dependencias transitivas

respecto a claves candidatas, pasando a 3FN y se han corregido todas sus anomalías

dejándola en FNB.

65

4. IMPLEMENTACIÓN

4.1 Tecnologías elegidas y herramientas utilizadas

Las tecnologías elegidas para el desarrollo del proyecto son:

• El sistema gestor de base de datos MySQL

La elección de MySQL se debe a que usa bases de datos relacionales; esto

agrega velocidad y flexibilidad, y hace posible combinar datos de varias tablas

cuando se necesita consultar datos.

Para realizar dichas consultas utiliza SQL (Lenguaje Estructurado de Consulta)

que es el lenguaje más usado y estandarizado para acceder a base de datos

relacionales.

Además MySQL es Open Source, es decir, puede ser usado gratuitamente.

Cualquiera puede descargar el software de MySQL de internet y usarlo sin

pagar por ello. Y usa la licencia GPL (Licencia Pública General – GNU) para

definir qué es lo que se puede y no se puede hacer con el software para

diferentes situaciones.

• El lenguaje de programación C#

Considerada la solución más viable ya que C# es un lenguaje diseñado

específicamente para la plataforma .NET (mayor integración) y proporciona la

robustez de C y la fiabilidad de Visual Basic.

Además se han utilizado algunas herramientas como:

• Visual Studio 2005

Es un entorno de desarrollo integrado (IDE) para sistemas operativos Windows

que permite desarrollar rápidamente interfaces de usuario con el mousse,

gracias a su “Cuadro de Herramientas” y a su “Diseñador”.

• La plataforma .NET

La plataforma .NET dispone de multitud de utilidades, librerías y recursos que

permiten ampliar las funcionalidades de nuestras aplicaciones

• Librería de datos Itextsharp

Itextsharp es una librería de .NET que nos ayuda en la creación de documentos

en txt, rtf, doc, pdf, html y xml.

• Librería de datos Ticket

Ticket es una librería libre desarrollada por los internautas para la plataforma

.NET, para facilitar la impresión de tickets en cualquier tipo de impresoras.

• Pacestar UML

Aplicación gratuita para la creación de todo tipo de diagramas UML.

• Microsoft Office Project 2007

66

Aplicación de escritorio para la planificación y creación de diferentes

diagramas, utilizado para la creación de diagramas de Gantt.

• Microsoft Word 2007

Procesador de textos, utilizado para la creación de la memoria.

• MySQL Server 5.4

Para la creación y gestión de la base de datos.

• MySQL Connector Net 5.0.9 y Conector ODBC 5.1

Para conectar la aplicación a la base de datos

• MySQL Administrador 1.1

Para hacer backups (copias de seguridad) y volcados de la base de datos

durante las pruebas.

• MySQL Query Browser

Para probar las consultas y controlar la introducción de datos en la base de

datos.

• PDFCreator

Software que se utiliza como una impresora virtual que simplemente utiliza

imprimir un documento para generar el pdf.

En nuestra aplicación lo utilizamos como impresora, ya que es la forma más

genérica de utilizar cualquier impresora.

4.2 Construcción del sistema de información

En esta tarea se genera tanto la preparación del entorno de programación

como todo el código del sistema de información, y también se especificarán las

pruebas que se realizarán durante la construcción.

4.2.1 Implantación de la base de datos

En esta tarea se crean todas las tablas del sistema gestor de base de datos, para

la construcción de la misma se ha usado MySQL Server 5.4 y MySQL Query Browser.

4.2.2 Preparación del entorno de construcción

En este apartado se realiza la implantación del entorno de programación Visual

Studio 2005, lenguaje C# con las librerías necesarias para la realización del proyecto.

4.2.2.1 Librerías externas necesarias

Las librerías externas necesarias para la construcción del sistema de

información son las siguientes:

67

• MySQL.Data.dll: la conexión de C# con una base de datos MySQL no tiene

librerías desarrolladas por defecto para C#, por lo tanto, he optado por incluir

en las referencias del proyecto esta librería de funciones.

• ItextShap.dll: después de documentarse sobre la creación de reportes y

distintos documentos en el lenguaje de programación C#, se optó por la

inclusión de esta librería, debido a que es una adaptación de iText para C# que

sirve para crear muchos tipos de documentos de texto, incluyendo el formato

pdf.

• Ticket.dll: buscando documentación se encontraron diferentes formas de hacer

un ticket, como usar la librería anterior, Crystal Report y programas de ese tipo

para hacer reportes, que son muy lentos, entonces surgió la idea de que se

tenía que imprimir directamente en la impresora para hacerlo más rápido y

buscando información sobre cómo hacerlo se encontró esta librería que se

ajusta a las necesidades del proyecto y acelera el proceso de impresión de

tickets.

4.2.3 Problemas con MySQL.

• Borrado y modificación de productos y familias.

• Guardar valores decimales.

• Modificaciones en la identificación y creación de camareros.

• Guardar imágenes en la base.

4.2.3.1 Borrado y modificación de productos y familias

Uno de los mayores problemas a la hora de construir la aplicación es el borrado de

datos. Para mantener la consistencia en la base de datos se usan claves foráneas de unas

tablas a otras, por ejemplo, la tabla familia, es referenciada por la tablas producto, la tabla

producto por la tabla lineaventa,…, si realizáramos el borrado de una familia, se borrarían

las productos asociados, y con estos las líneas de venta, dejando a medias las ventas

confirmadas.

Debido a que no es conveniente borrar líneas de venta o modificar las ventas

confirmadas realizadas anteriormente por un usuario, se ha decidido modificar la base de

datos de forma que al borrar una familia, no se borren los productos asociados, sino que

los productos pierdan esa asociación, pero que en la base de datos sigan existiendo los

productos para poder mantener la consistencia.

Se incluye un fragmento del código de la base de datos donde se muestra la

creación de la tabla producto:

CREATE TABLE `pubchandro`.`producto` (

`codigo` int(5) NOT NULL AUTO_INCREMENT,

`descripcion` char(50) CHARACTER SET latin1 NOT NULL,

68

ìmagen` char(150) CHARACTER SET latin1 DEFAULT NULL,

`familia` int(5) DEFAULT NULL,

`precio` decimal(10,2) unsigned NOT NULL DEFAULT '0.00',

PRIMARY KEY (`codigo`),

KEY `fk_familia` (`familia`),

CONSTRAINT `producto_ibfk_1` FOREIGN KEY (`familia`) REFERENCES `familia` (`codigo`) ON

DELETE SET NULL ON UPDATE CASCADE

) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=latin1 COLLATE=latin1_spanish_ci;

Lo que se hace es crear una clave foránea a familia de forma que si se modifica

familia, la modificación vaya en cascada, es decir, que se modifique también en

producto, pero si se borra, dejamos la clave foránea con valor “null”, deshaciendo la

asociación de ese producto con la familia, para que pueda ser borrada, pero no borre

el producto.

4.2.3.2 Guardar valores decimales en MySQL

. Uno de los mayores retos es el de decidir un tipo de datos numérico para

representar los precios y sus operaciones ya que, aunque C# y SQL tienen muchos

tipos de datos numéricos en común, sus representaciones gráficas no son iguales.

Se ha decidido el tipo ‘decimal’, ya que ambos lenguajes lo reconocen, aunque

no lo representen igual gráficamente. En C# el separador de decimales por defecto es

el carácter ‘,’ mientras que en SQL, es ‘.’.

Hay 2 soluciones posibles:

• Cambiar la configuración regional en la aplicación cada vez que se utilice a la

adecuada para que C# reconozca el carácter ‘.’ como separador de decimales

por defecto

• Reemplazar el carácter ‘,’ por el carácter ‘.’ al insertar nuestras variables de C#

como texto en los comandos de SQL.

Se ha optado por la 2ª opción debido a que con ella es más fácil asegurarse que

la inserción de datos en la base de datos va a ser correcta siempre.

El siguiente código es una porción de la clase Lógica de la pantalla de ventas que muestra la función crearLineaVenta donde podrán observar cómo se reemplaza ‘,’ por ‘.’ en la variable "tot" del comando para insertar la línea de venta en la base de datos: public void crearLineaVenta( int uni, Producto p, int vent) { this .conectar(); DataSet data = new DataSet (); decimal tot = p.Precio * uni;

69

string insert = "insert into lineaventa (unidades, articulo, total, venta) values (" + uni + ", " + p.Codigo + "," + tot.ToString().Replace( ',' , '.' ) + ", " + vent + ");" ; MySqlDataAdapter adaptador = new MySqlDataAdapter (insert, conexion); adaptador.Fill(data); actualizarVenta(tot,vent); this .desconectar(); }

4.2.3.3 Modificaciones en la identificación y creación de camareros.

Durante la creación de la base de datos se creó la clase camarero con 2

atributos que no podían ser nulos. Hubo muchos problemas porque la aplicación debe

permitir crear camareros, para después asignarles o no un nombre. La solución fue

muy sencilla, permitir que el atributo nombre fuese nulo.

Pero en la creación de ventas ese problema volvió, ya que la tabla ventas hace

referencia a la tabla camarero mediante una clave foránea, que al modificar o eliminar

un camarero se ve afectada. Se resolvió utilizando de nuevo la configuración de

modificación y borrado de claves foráneas, pero esta vez dejando el valor “null” en

ambos casos.

El siguiente código muestra una parte del script de la base de datos que incluye

la creación de la tabla venta:

CREATE TABLE `pubchandro`.`venta` (

`codigo` int(50) NOT NULL AUTO_INCREMENT,

`camarero` char(3) DEFAULT NULL,

ìva` decimal(10,2) unsigned NOT NULL DEFAULT '0.00',

ìmporte` decimal(10,2) unsigned NOT NULL DEFAULT '0.00',

`total` decimal(10,2) unsigned NOT NULL DEFAULT '0.00',

`fecha` date DEFAULT NULL,

èstado` char(2) DEFAULT NULL,

PRIMARY KEY (`codigo`),

KEY `fk_camarero` (`camarero`),

CONSTRAINT `fk_camarero` FOREIGN KEY (`camarero`) REFERENCES `camarero`

(`codigo`) ON DELETE SET NULL ON UPDATE SET NULL

) ENGINE=InnoDB AUTO_INCREMENT=72 DEFAULT CHARSET=latin1;

4.2.3.4 Guardar imágenes en la base.

Al intentar guardar las imágenes para la pantalla de ventas en la base de datos

se observó que eran muy pesadas, por lo que además de ocupar muchísimo espacio

ralentizaban mucho la aplicación, por ello se optó por guardar su ubicación absoluta,

ocupando muchísimo menos espacio en la base de datos y agilizando la aplicación.

70

4.2.4 Problemas encontrados en la aplicación de gestión

• Cierre de caja teórico o real.

• Reporte de informes

4.2.4.1 Cierre de caja teórico o real

A la hora de hacer crear la función de cierre de caja había 2 opciones:

• El cierre de caja teórico, es decir, recoge todas las ventas confirmadas durante

el día actual, guardado en el campo fecha.

• El cierre de caja real, es decir, todas las ventas confirmadas desde el anterior

cierre de caja hasta el momento en que se hace el cierre.

Teniendo en cuenta que la empresa en la que se quiere implanta la aplicación

es un pub para jóvenes, cuyo horario de apertura puede abarcar varios días, es decir,

comenzar en un día y terminar en otro, la opción elegida ha sido el cierre de caja real.

Para ello se han creado 2 tablas para las venta (venta e historicoventas) y otras

2 para las líneas de venta (lineaventa e historicolineaventa), al cierre de caja todas las

ventas confirmadas guardadas en venta pasarán a historicoventas, dejando la tabla

venta lista para el nuevo cierre de caja, solo con las ventas aplazadas, lo que incluye

pasar todas las líneas de venta de esas ventas a historicolineaventa. Hay que tener

cuidado el orden en el que se realiza el paso de ventas y líneas de venta al histórico

para no perder la consistencia de la base de datos e incluso duplicar algunos datos

durante el proceso.

4.2.3.2 Reporte de informes

Otro de los problemas encontrados es la forma de mostrar los informes al

usuario, puesto que estos deben poder ser imprimidos y/o guardados. Por eso la

solución obtenida ha sido el uso de la librería Itextsharp y la aplicación PDFCreator

para crear documentos pdf y mostrarlos en pantalla de forma que el usuario pueda

guardarlos en un archivo y/o imprimirlos a través de PDFCreator, descargando así a la

aplicación de controlarlo.

Se muestra una parte del código de la pantalla informe de ventas de la

aplicación de gestión:

...Informes inf= l.getInformes(); Document documento = new Document ( PageSize .A4); PdfWriter .GetInstance(documento, new FileStream ( "informeVentas.pdf" , FileMode .OpenOrCreate)); documento.Open(); //cabecera del informe if (inf.Cabecera == true ) {

71

documento.Add( new Paragraph (inf.TextoCab)); } // Fecha de la consulta PdfPTable tabla = new PdfPTable (3); tabla.DefaultCell.Border = 0; tabla.DefaultCell.HorizontalAlignment = 2; PdfPCell ce = new PdfPCell ( new Phrase ( "" )); ce.Colspan = 3; ce.Border = 0; tabla.AddCell(ce); tabla.AddCell(ce); PdfPCell cell = new PdfPCell ( new Phrase ( "Informe de Ventas" )); cell.Colspan = 3; cell.HorizontalAlignment = 1; //0=Left, 1=Centre, 2=Right cell.Border = 0; tabla.AddCell(cell); tabla.AddCell(ce); cell.Phrase= new Phrase ( "Datos obtenidos entre el " + t bDiaInicio.Text + "-" + tbMesInicial.Text + "-" + tbAñoInicial.Text + " y el " + tbDiaFinal.Text + "-" + tbMesFinal.Text + "-" + t bAñoFinal.Text); tabla.AddCell(cell); tabla.AddCell(ce); tabla.AddCell(ce); tabla.AddCell( "Camarero" ); tabla.AddCell( "Ventas" ); tabla.AddCell( "Porcentaje" ); //ventas totales tabla.AddCell( "Todos" ); tabla.AddCell(tot.ToString( "0.00" ) + " €" ); tabla.AddCell( "100,00 %" ); //ventas por camarero for ( int n = 0; n < lbSeleccion.Items.Count; n++) { int j = int .Parse(lbSeleccion.Items[n].ToString().Substring(1)) ; tabla.AddCell(j.ToString()); tabla.AddCell(totCam[j].ToString( "0.00" )+ " €" ); tabla.AddCell(porcentaje[j].ToString( "0.00" ) + " %" ); } documento.Add(tabla); documento.Close(); //Abrir el informe de ventas System.Diagnostics. Process .Start( "informeVentas.pdf" );....

El código muestra como se crea un documento pdf, se le introducen datos,

incluso se crea una tabla para dar formato que primero se rellena con los datos para

despues añadirla al documento, despues el documento se cierra y se muestra en

pantalla, junto con todos los controles de PDFCreator, como se ve en la siguiente

imagen.

72

4.2.4 Problemas encontrados en la pantalla de ventas

• Tamaño de la pantalla de ventas.

• Introducción de precios directos.

• Ventas aplazadas.

• Imprimir tickets de venta.

4.2.4.1 Problemas encontrados en la pantalla de ventas

Al elaborar la pantalla de ventas el primer problema era el tamaño (resolución)

porque tiene que ser completamente táctil y los controles que en ella aparezcan

tienen que tener el tamaño adecuado para ello.

Como documentación se comprobó la resolución de pantalla de diferentes

TPV’s y también la de diferentes software para TPV encontrados por internet, llegando

a la conclusión de que la mejor resolución es 800x600px, por eso la pantalla de ventas

está optimizada para esa resolución, pero es válida para cualquier otra.

4.2.4.2 Introducción de precios directos.

La pantalla de ventas tiene la opción de introducir un precio directo mediante

el teclado numérico. El problema viene a la hora de registra la línea de venta en la base

de datos, ya que no pertenece a ningún producto de registrado en ella.

Se ha solucionado introduciendo un producto con código 1 y nombre “varios”,

pero con familia, imagen y precio con el valor ““null””, que no puede ser borrado ni

modificado por los usuarios.

También se han tenido que crear funciones especiales para la creación de líneas

de venta con el producto “varios”, como muestra el siguiente fragmento de código:

public void crearLineaVarios( int uni, decimal precio, int vent) { this .conectar(); DataSet data = new DataSet (); string insert = "insert into lineaventa (unidades, articulo, t otal, venta) values (" + uni + ", 1," + precio.ToString().Replace( ',' , '.' ) + ", " + vent + ");" ; MySqlDataAdapter adaptador = new MySqlDataAdapter (insert, conexion);

73

adaptador.Fill(data); actualizarVenta(precio, vent); this .desconectar(); }

Y para la eliminación de las líneas de venta del producto “varios”:

public void eliminarLineaVarios( int v, int uni, decimal precio) { this .conectar(); string query = "delete from lineaventa where venta= " + v.ToString() + " and articulo =1 and total= " + precio.ToString().Replace( ',' , '.' ) + " and unidades = " + uni.ToString() + ";" ; DataSet data = new DataSet (); MySqlDataAdapter adap = new MySqlDataAdapter (query, conexion); adap.Fill(data); actualizarVenta(-precio, v); this .desconectar(); }

En estas funciones en lugar de pasarles como parámetro el producto se les pasa

el total de la línea de venta, de forma que tenga todos los datos necesarios para crear

la línea de venta o identificarla a la hora de borrarla.

4.2.4.3 Ventas aplazadas

Una petición del cliente era poder aplazar las ventas sin confirmarlas, para

poder recuperarlas en otro momento y continuarlas.

El problema era que al cerrar la aplicación o hacer el cierre de caja todo lo que

no estuviese almacenado en la base de datos se perdía. Por eso se decidió añadir un

campo “estado” a la tabla “venta” que identificase el estado de la venta y pueda tomar

los valores ‘ap’ si está aplazada, ‘ac’ para la venta activa en ese momento y "null" para

las ventas confirmadas.

Al iniciar la pantalla de ventas los códigos de todas las ventas aplazadas son

recogidos en una lista, a la que se van añadiendo los de las ventas que se vayan

aplazando, para mostrarlos junto con su total en una pequeña ventana al pulsar el

botón “recuperar”.

4.2.4.4 Imprimir tickets de venta

Con la impresión de tickets el problema estaba en que al ser un programa

genérico no se podía especificar la impresora en la que imprimir. Se ideó que había

que imprimir directamente en el puerto, pero buscando primero en que puerto está

instalada una impresora y se buscó documentación sobre ello. Entre la documentación

se encontró la librería Ticket.dll, la cual permitía imprimir con formato de ticket,

añadirle los datos de la empresa, decirle en que impresora se desea imprimir e

imprimir, como se muestra en el siguiente código:

74

public void imprimirTicket( Venta v) { List <LineaVenta > lisArt = getLineasVenta(v.Codigo); ConfigTicket ct = getTicket(); Ticket ticket = new Ticket (); // Añade la cabecera si lo indica la configuración if (ct.Cabecera == true) { ticket.AddHeaderLine(ct.TextoCab); } // añade los datos de la empresa ticket.AddHeaderLine(ct.Datos1); ticket.AddHeaderLine(ct.Datos2); ticket.AddHeaderLine(ct.Datos3); ticket.AddHeaderLine(ct.Datos4); ticket.AddHeaderLine(ct.Datos5); ticket.AddHeaderLine(ct.Datos6); / / añade el camarero que le atiende si esta asi confi gurado if (ct.Camarero == true ) { if (v.Camarero.Nombre != "" ) { ticket.AddHeaderLine( "Camarero: " + v.Camarero.Nombre); } else { ticket.AddHeaderLine( "Camarero: " + v.Camarero.Codigo.Substring(1)); } } // añade la fecha del ticket ticket.AddHeaderLine(v.Fecha.ToString()); //lineas de venta for ( int i = 0; i < lisArt.Count; i++) { ticket.AddItem(lisArt[i].Unidades.ToString(),lisArt[i].Articulo.Descripcion, lisArt[i].Total.ToString( "0.00" )); } // importe, iva y total if (ct.TipoTotal == "bit" ) { ticket.AddTotal( "IMPORTE" , v.Importe.ToString( "0.00" )); } if (ct.TipoTotal == "bit" || ct.TipoTotal == "it" ) { ticket.AddTotal(ct.Iva.ToString() + "% IVA" , v.Iva.ToString( "0.00" )); } ticket.AddTotal( "TOTAL" , v.Total.ToString( "0.00" )); // pie de ticket if (ct.Pie == true ) { ticket.AddFooterLine(ct.TextoPie); ticket.AddFooterLine( "" ); } ticket.PrintTicket(ct.Impresora);

El problema de la función era decirle la impresora, y se solucionó añadiendo un campo impresora a la tabla “ticket” de la base de datos, que se rellena desde la

75

pantalla de configuración de la apariencia de tickets, como muestra la imagen siguiente:

Con esto basta con poner en el cuadro de texto impresora el nombre con el que

la impresora se muestra en la carpeta impresoras del ordenador.

76

5

. GESTIÓ

N Y

CO

NC

LUSIO

NES

5.1

PLA

NIFIC

AC

IÓN

A

l inicio

del p

royecto

se realizó la p

lanificació

n reco

gida en

el plan

de trab

ajo

del D

.O.P

. el cu

al finalizab

a en m

ayo d

el 20

10

.

23/09 24/09Conocimientos previos

13/10 15/10Análisis de Requisitos iniciales

27/09 07/10Elaboración del DOP

13/10 17/03Memoria

30/09 16/03Seguimiento

15/10 02/11Análisis de requisitos

03/11 08/11Diseño

09/11 26/11Diseño de la BD

29/11 16/12Diseño del interface

20/12 15/03Implementación

16/03 18/03Pruebas

21/03 28/03Intalación

18 21 24 27 30 03 06 09 12 15 18 21 24 27 30 02 05 08 11 14 17 20 23 26 29 02 05 08 11 14 17 20 23 26 29 01 04 07 10 13 16 19 22 25 28 31 03 06 09 12 15 18 21 24 27 02 05 08 11 14 17 20 23 26 29 01 04 07 10octubre 2010 noviembre 2010 diciembre 2010 enero 2011 febrero 2011 marzo 2011 abril 2011

77

También se hizo una estimación de riesgos. Uno de los riesgos estimados era el

cambio en el horario de trabajo el cual en caso de cambio extremo de horario

consensuaba un aplazamiento de la entrega.

5.2 Aplazamientos

En este caso se ha sufrido un cambio extremo del horario de trabajo ya que

cuando se comenzó el proyecto el proyectante trabajaba unas 4horas diarias de lunes

a viernes y un mínimo 10 horas al día los fines de semana, pudiendo dedicar al

proyecto 29 horas semanales, según el siguiente cuadro de trabajo:

Hora Lunes Martes Miércoles Jueves Viernes Sábado Domingo

10:00

Proyecto Proyecto Proyecto Proyecto Proyecto 11:00

12.:00

13:00

14:00

Trabajo Trabajo Trabajo

Trabajo Trabajo Trabajo Trabajo 15::00

16.:00

Proyecto Proyecto

Proyecto

Proyecto 17:00

Clase 18:00

19:00

20:00

Clase

Trabajo Trabajo Trabajo

21:00

Trabajo

22:00

Trabajo Trabajo Trabajo 23:00

24:00

Por desgracia este cuadro de trabajo sólo pudo ser seguido durante los 2

primeros meses de mitad de septiembre a mitad de noviembre del 2009, ya que

entonces se sufrió un aumento en el horario de trabajo de 4 a 8 horas diarias,

reduciendo a 19 las horas de proyecto. En total se le dedicaron unas 232 horas de

trabajo al proyecto antes de modificar el horario.

3 meses después se sufrió un nuevo un aumento masivo de las horas de

trabajo por lo que el proyectante tuvo que paralizar por completo el proyecto desde

febrero del 2010 hasta septiembre del mismo año, donde lo retomo dedicándole

apenas 8 horas semanales. Hasta aquí se dedicaron unas 228 horas más proyecto, un

total de 460 horas.

78

Se mantuvo hasta finales de diciembre del 2010, sumando 32 horas más al

proyecto, y después el proyectante vuelve a tener una subida masiva de las horas de

trabajo debiendo casi aplazar el proyecto de nuevo, ya que apenas podía dedicarle 2

horas semanales hasta junio del 2011, 48 horas más que hacen un total de 540 horas.

De nuevo en octubre del 2011 se retomó el proyecto dedicándole entre 4 y 6

horas semanales, hasta marzo del 2012, 144 horas más. Y de finales de marzo del 2012

hasta junio del 2012 se dedicaron 4 horas diarias, lo cual añade otras 360 horas más,

haciendo un total de 1044 horas, aproximadamente ya que la determinación de horas

no es exhaustiva.

Este es el plan de trabajo real:

octubre 2009no

viembre 2009dicie

mbre 2009enero

2010febrero 2

010marzo 2010ab

ril 2010mayo

2010junio 2

010julio 2010

agosto 2010se

ptiembre 201

0octubre 2010no

viembre 2010dicie

mbre 2010enero

2011febrero 2

011marzo 2011ab

ril 2011mayo

2011junio 20

11julio 2011

agosto 2011se

ptiembre 201

1octubre 2011no

viembre 2011dicie

mbre 2011enero

2012febrero 2

012marzo 2012a

bril 2012ma

yo 2012junio

2012julio 20

12

tiempo estimado. El error de estimación supone un aumento aproximado del 50% en

el total de las horas empleadas, además de un aplazamiento de 2 años en la fecha de

entrega.

dedic

TiempoEstimado(h)

TiempoReal (h)

Variación(%)

variación, aunque es un valor aproximado puesto que no se contabilizaron las horas de

forma exhaustiva, si que nos puede dar una idea del tiempo que se tuvo que dedicar a

cada apartado.

100

200

300

400

500

Frente a las 548 horas estimadas, las 1044 horas reales suponen un 190% del



entrega.

Este es el balance final entre la estimación realizada y el tiempo final de

dedicación:

D.O.P

Tiempo Estimado 34

Tiempo Real (h)

105

Variación 67,62

En el siguiente gráfico



cada apartado.

0

100

200

300

400

500

Tiempo Estimado (h)





P. Análisis

38

68

67,62 44,12

En el siguiente gráfico



Tiempo Estimado (h)





Diseño Memoria

85 70

180 150

52,78 53,33

En el siguiente gráfico podemos observar de una forma más clara como fue esta



Tiempo Real(h)





Memoria Implementación

70 240

150 450

53,33 46,67

podemos observar de una forma más clara como fue esta



Tiempo Real(h)





Implementación

240

450

46,67








Pruebas

10

50

80








Instalación

30

30

0




Tiempo Estimado (h)

Tiempo Real(h)

79





Total

507

1033

50,92




Tiempo Estimado (h)

Tiempo Real(h)

Tiempo Estimado (h)

dedicado a cada parte del proyecto con respecto al tiempo total.

5.3 Conclusiones

cafetería o similar que mantenga sep

gestión para lo que hemos creado 2 aplicaciones independientes: una pantalla de

ventas y una aplicación de gestión, ambas conectadas a la misma base de datos.

táctiles. Las nuevas aplicaciones están diseñadas para mostrar su funcionamiento de

forma intuitiva, mostrando pantallas de menús claros que dan acceso a formularios

sencillos, cuyo fácil relleno puede hacerse de forma táctil, neces

pantalla de Windows para rellenar algunos datos.

modificarlas, anularlas, aplazarlas y recuperarlas, mostrar la lista de ventas aplazadas,

registrar el camar

líneas de venta. Además permite añadir a las ventas productos de venta directa, es

decir, productos registrados como varios de los cuales introducimos el importe

manualmente, y abrir el cajón

El gráfico q


5.3 Conclusiones

En las especificaciones se pedía una aplicación genérica para el TPV de un pub,




Pedían una aplicación intuitiva, fácil de manejar y





La pantalla de ventas cumple con las exigencias del cliente de crear ventas,


registrar el camar




Implementación

Tiempo Real

El gráfico que se encuentra a continuación muestra el tiempo real


5.3 Conclusiones












registrar el camarero que crear la venta y mostrar en todo momento el total y las




Implementación44%

Tiempo Real

ue se encuentra a continuación muestra el tiempo real













ero que crear la venta y mostrar en todo momento el total y las



manualmente, y abrir el cajón monedero.

Memoria14%

Implementación




cafetería o similar que mantenga separadas el punto de venta y la aplicación de













monedero.

Memoria14%




aradas el punto de venta y la aplicación de













Pruebas5%







Pedían una aplicación intuitiva, fácil de manejar y diseñada para pantallas



sencillos, cuyo fácil relleno puede hacerse de forma táctil, necesitando el teclado en






Diseño17%

PruebasInstalación

3%







diseñada para pantallas



itando el teclado en






D.O.P.10%

Análisis7%

Instalación

80





diseñada para pantallas



itando el teclado en






Análisis7%

81

La aplicación de gestión cumple con sus cometidos de controlar el acceso por

contraseña, pero además diferencia entre 2 tipos de usuario, el administrador y el

encargado, y puede modificar las contraseñas para ambos.

Cumple con sus cometidos de modificar el TPV creando, modificando y

eliminando familias y productos.

Además de permitir realizar el cierre de caja, se lo imprime o guarda en un

archivo pdf, y hace balances de caja, es decir, comprobantes de las ventas realizadas

hasta el momento sin cerrar la caja, permitiendo imprimirlos y guardarlos.

También debía permitir anular ventas confirmadas, pero además permite

imprimirlas.

No solo permite crear informes, estadísticas y listados, sino que pueden

imprimirse y guardarse en un archivo pdf.

Además permite configurar el ticket de venta, incluir en el nuestros datos y

seleccionar la impresora en la que imprimirlos.

También permite configurar las cabeceras de los informes, estadísticas y el

comprobante de cierre de caja, los atributos de los listados.

Y por último permite incrementar o disminuir el número de camareros del TPV,

e identificarlos.

82

6. APENDICE 1: ACTAS DE REUNIONES

6.1 Actas de reuniones con los clientes

Primera reunión con el cliente

PROYECTO: Aplicación de Gestión para el TPV de una Cafetería.

ACTA DE REUNIÓN

PRIMERA REUNIÓN CON EL CLIENTE: REQUERIMIENTOS DE LA APLICACION

Fecha: Lunes 26 de Octubre del 2009.

Lugar: Pub Chandro

Hora de inicio: 17:30

Hora de fin: 18:00

Asistentes:

Andrés Chandro Heras (Propietario)

Nicolás Chandro Heras (Propietario)

Adela Chandro Velasco (Proyectante) Orden del día:

• Acordar los requerimientos del sistema.

• Familiarizarse con la empresa.

Incidencias y decisiones adoptadas:

• Se acordó crear una aplicación de gestión para el TPV del pub de su propiedad.

• Se recogieron los requisitos que debía cumplir la aplicación.

83

• Se acordó mostrar el prototipo para dar aceptación.

• Se acordó facilitar todos los datos necesarios por parte de los propietarios para la creación de la aplicación.

• Se acordaron plazos de entrega y previsión de posibles atrasos.

• Se acordó permitir probar la aplicación en un TPV propiedad de los propietarios.

Segunda reunión con el cliente


ACTA DE REUNIÓN

SEGUNDA REUNIÓN: PRIMERA REUNIÓN CON EL DIRECTOR DE MI PROYECTO

Fecha: Viernes 23 de Octubre del 2009.

Lugar: Despacho Eloy Mata Sotes, Edificio Vives.


Hora de fin: 13:00

Asistentes:

Eloy Mata Sotes (Director del Proyecto))


• Describir el proyecto propuesto.

• Obtener las directrices para poner en marcha el proyecto. Incidencias y decisiones adoptadas:

• Se decidió empezar con el D.O.P. y para ello observar varios proyectos anteriores.

• También se decidió comenzar con un cuaderno de proyecto y crear un horario de trabajo.

84

• Se acordó una nueva cita en 15 días para la cual ya deberían estar elaborados los 3 primeros puntos del D.O.P.

Tercera reunión con el cliente


ACTA DE REUNIÓN

TERCERA REUNIÓN CON EL CLIENTE: AVISO DE RETOMA DEL PROYECTO

Fecha: Jueves 30 de Septiembre del 2010.

Lugar: Pub Chandro


Hora de fin: 17:00

Asistentes:




• Comunicar la retoma del proyecto.


• Aceptación de continuación del proyecto.

Cuarta reunión con el cliente

85


ACTA DE REUNIÓN

CUARTA REUNIÓN CON EL CLIENTE: MUESTRA DEL PROTOTIPO

Fecha: Lunes 21 de Marzo del 2011.

Lugar: Pub Chandro


Hora de fin: 20:30

Asistentes:




• Mostrar el prototipo.


• Aceptación del prototipo para la continuación de la implementación.

Quinta reunión con el cliente


ACTA DE REUNIÓN

86

QUINTA REUNIÓN CON EL CLIENTE: PRUEBAS DE LA APLICACION

Fecha: Lunes 10 de Mayo del 2012.

Lugar: Bar Chandro


Hora de fin: 00:30

Asistentes:


Adela Chandro Velasco (Proyectante)

Orden del día:

• Probar la aplicación en el hardware final.

• Comprobar fallos.


• Se han comprobados algunos fallos en la impresión del ticket.

• Se ha acordado permitir más pruebas cualquier día hasta el día de la entrega sin necesidad de reunión con el propietario.

6.2 Actas de reuniones con el director del proyecto

Primera reunión con el director del proyecto


ACTA DE REUNIÓN

QUINTA REUNIÓN CON EL CLIENTE: PRUEBAS DE LA APLICACION

87

Fecha: Lunes 10 de Mayo del 2012.

Lugar: Bar Chandro


Hora de fin: 00:30

Asistentes:


Adela Chandro Velasco (Proyectante)

Orden del día:

• Probar la aplicación en el hardware final.

• Comprobar fallos.


• Se han comprobados algunos fallos en la impresión del ticket.

• Se ha acordado permitir más pruebas cualquier día hasta el día de la entrega sin necesidad de reunión con el propietario.

Segunda reunión con el director del proyecto


ACTA DE REUNIÓN

SEGUNDA REUNIÓN: PRIMERA REUNIÓN CON EL DIRECTOR DE MI PROYECTO

Fecha: Viernes 23 de Octubre del 2009.

88



Hora de fin: 13:00

Asistentes:



• Describir el proyecto propuesto.

• Obtener las directrices para poner en marcha el proyecto. Incidencias y decisiones adoptadas:

• Se decidió empezar con el D.O.P. y para ello observar varios proyectos anteriores.

• También se decidió comenzar con un cuaderno de proyecto y crear un horario de trabajo.

• Se acordó una nueva cita en 15 días para la cual ya deberían estar elaborados los 3 primeros puntos del D.O.P.

Tercera reunión con el director del proyecto


ACTA DE REUNIÓN

TERCERA REUNIÓN: MUESTRA DE LOS 3 PRIMEROS APARTADOS DEL D.O.P

Fecha: Viernes 5 de Noviembre del 2009.


89


Hora de fin: 17:30

Asistentes:



• Revisión de los 3 primeros puntos del D.O.P.

• Obtener las directrices para continuar con el proyecto.

• Presentar el cuadro de trabajo al director.


• Debo modificar los antecedentes para explicar en qué consiste la aplicación.

• Debo investigar sobre proyectos similares ya existentes y compararlos con el nuevo proyecto y porqué lo quiere así el cliente.

• Debó modificar solo algunos cambios en los objetivos.

• Corregir el cuadro de horario del proyecto.

Cuarta reunión con el director del proyecto


ACTA DE REUNIÓN

CUARTA REUNIÓN: RETOMAR EL PROYECTO DESPUES DE APLAZARLO

Fecha: Miércoles 29 de Septiembre del 2010


90


Hora de fin: 17:30

Asistentes:



• Revisión de lo realizado anteriormente.

• Directrices para continuar con el proyecto.


• Se ha decidido modificar el tiempo asignado a cada tarea en la descomposición de tareas.

• Se ha decidido crear estilos y formatos para usar en toda la documentación.

• Se ha decidido comenzar con la parte de análisis de requisitos.

• Queda pendiente hasta documentarse adecuadamente la elección de las posibles tecnologías a utilizar

• Se acuerda otra reunión para el miércoles 13 de noviembre a las 17:00.

Quinta reunión con el director del proyecto


ACTA DE REUNIÓN

QUINTA REUNIÓN: FINALIZACIÓN DEL D.O.P. Y MUESTRA DEL ANÁLISIS

Fecha: Miércoles 13 de Noviembre del 2010


91


Hora de fin: 17:30

Asistentes:



• Mostrar el D.O.P. terminado

• Mostrar análisis de requisitos.

• Mostrar el diagrama de casos de uso.

• Mostrar el análisis de la interfaz.

• Mostrar el análisis de pruebas.

• Proponer tecnologías para el desarrollo de la aplicación.

• Directrices para continuar con el proyecto.


• Se deben reducir los casos de uso agrupándolos, y por ello modificar el diagrama de casos de uso.

• Se deben crear explicaciones y diagramas de actividad para los casos de uso.

• Se debe cambiar el análisis de la interfaz diferenciando entre los 2 módulos o aplicaciones del proyecto.

• Se debe modificar el análisis de pruebas.

• Se debe continuar con el análisis de las clases.

• Se debe crear el prototipo de la aplicación.

Sexta reunión con el director del proyecto


ACTA DE REUNIÓN

SEXTA REUNIÓN: PROTOTIPO, TECNOLOGÍAS Y DISEÑO DE LA BASE DE DATOS

92

Fecha: Jueves 17 de Marzo del 2011



Hora de fin: 19:00

Asistentes:



• Mostrar el prototipo

• Decidir tecnologías a utilizar

• Mostrar el diseño de la base de datos


• Se debe modificar el formato de la documentación.

• Debo añadir el diseño de la interfaz, el diseño de la base de datos y el diseño de las tablas de la base de datos.

• Se ha decidido utilizar Visual Studio 2005 con el lenguaje C# y MySQL.

Séptima reunión con el director del proyecto


ACTA DE REUNIÓN

SÉPTIMA REUNIÓN: MUESTRA DE LA BASE DE DATOS Y RESOLUCION DE DUDAS

Fecha: Jueves 17 de Noviembre del 2011

93



Hora de fin: 18:30

Asistentes:



• Mostrar la base de datos.

• Mostrar el capítulo de diseño terminado.

• Preguntar dudas sobre implementación.


• Queda finalizado el capítulo de diseño.

• Se debe corregir la base de datos para que sea menos estricta.

• Se debe cambiar el formato de los datos que representan un precio.

• Se poner al día la documentación.

• Se debe terminar la implementación.

Octava reunión con el director del proyecto


ACTA DE REUNIÓN

OCTAVA REUNIÓN: MUESTRA DE LA APLICACIÓN Y DOCUMENTACION

Fecha: Miércoles 16 de Mayo del 2012

94



Hora de fin: 17:30

Asistentes:



• Mostrar la aplicación final.

• Comentar los capítulos que faltan de la implementación.


• Aceptada la aplicación final.

• Se han fijado plazos para la entrega de las diferentes partes de la documentación por e-mail.

• Se ha determinado el depósito del proyecto antes de la fecha límite.

Documents

TRABAJO FIN DE ESTUDIOS - biblioteca.unirioja.es · ... ACTAS DE REUNIONES ... de una aplicación software para el punto de venta de un pub ... dejando una holgura a la hora de la