Casos de uso del sistema

3. Casos de uso del sistema

Esta sección tiene por objetivo presentar un resumen de los requerimientos del sistema sin llegar a mucho detalle, es un compendio de las
funcionalidades que el sistema implementará expresadas en casos de uso que son la notación recomendada por el proceso de desarrollo que se
esta utilizando.

Estos casos de uso están compuestos por una diagrama de Casos de Uso de UML y una plantilla que contiene elementos bastante explicativos
sobre las funcionalidades a ser implementadas.

CU1 Validacion de usuario

Diagrama:

Actores: Usuario

Flujo de eventos:
1. El usuario ingresa su login y password.
2. El sistema valida la autenticidad del usuario.
3. El sistema tambien debe verificar de que oficina esta intentando ingresar el usuario.

Pre-condiciones: El usuario debe estar registrado en la base de datos.

Post-condiciones: El usuario es autentificado.

Notas: Ninguna

CU2 Gestion Incidencia

Diagrama:
Actores: Usuario

Flujo de eventos:
1. El usuario crea incidencia para la encomienda.
2. El usuario puede modificar la incidencia.

Pre-condiciones: El usuario debe estar registrado en la base de datos.

La encomienda para el que se quiere crear la incidencia debe estar registrada en la base de datos.

Post-condiciones: Los datos de la incidencia son registrados en la base de datos.

Notas Se puede crear mas de una incidencia para una encomienda.

CU3 Actualizar tipo de cambio

Diagrama:

Actores: Administrador

Flujo de eventos:
1. El administrador ingresa a la vista de tipos de cambio de monedas
2. El administrador actualiza el tipo de cambio de las monedas manejadas por el sistema

Pre-condiciones: El administrador debe estar autentificado.

Post-condiciones: Se tiene registrado el nuevo tipo de cambio.

Notas: Ninguna

CU4 Recepcion de encomiendas

Diagrama:

Actores: Personal de recepcion, cliente

Flujo de eventos:
1. El personal de recepcion busca si ya existen los datos del cliente en el sistema
2. Si los datos del cliente no existen:
a. El recepcionista crea un contacto con los datos del cliente
3. El recepcionista busca si ya existe los datos del destinatario en el sistema
4. Si los datos del destinatario no existen
a. El recepcionista crea un contacto con los datos del destinatario
5. El recepcionista llena los datos de la encomienda
6. El recepcionista selecciona modo de envio
7. El recepcionista calcula el costo a pagar por la encomienda
8. El recepcionista imprime el detalle de la encomienda con el monto a cancelar

Pre-condiciones: El encargado de recepción esta validado en el sistema

Post-condiciones: Se tienen almacenados los datos de la encomienda.

Notas Tiene que haber dos numeros de guia : uno general y otro correlativo por oficina.
Se tiene dos modalidades de cobro, pagar en origen o en destino.
Los modos de envio son: mano, express, carga y equipaje

CU5 Cobro de encomiendas

Diagrama:

Actores: Cajero, cliente

Flujo de eventos
1. El cajero busca el detalle de la encomienda
2. El cajero registra el cobro por la encomienda
3. El cajero imprime la factura

Pre-condiciones: Los datos de la encomienda debe estar en el sistema

El costo a pagar deberia estar calculado

Post-condiciones: La encomienda tiene que estar registrada como pagada

Notas Se imprimen dos comprobantes de pago uno para el cliente y otro para la empresa.

CU6 Verificar encomiendas

Diagrama:

Actores: Encargado de despacho

Flujo de eventos:
1. El encargado accede a la lista de encomiendas registradas
2. El encargado elabora la lista de empaque
3. El encargado elabora lista de despacho actualizando la lista de empaque, puede quitar las encomiendas
observadas en aduana y controles, y poner observaciones
4. El encargado puede hacer búsquedas de las encomiendas faltantes

Pre-condiciones: Las encomiendas a ser enviadas deben estar registradas en el sistema, y el encargado debe estar validado en el sistema

Post-condiciones: Se tiene la lista de despacho de encomiendas registrada en el sistema

Notas: En la lista de empaque se encuentran todas las encomiendas a enviarse.

Al momento de ser enviadas las encomiendas pasan por control (ADUANA) y puede ser que algunas no puedan ser
enviadas.
La lista de despacho es la lista final de encomiendas a enviarse.

CU7 Buscar encomiendas no encontradas

Diagrama:

Actores: Encargado de despacho

Flujo de eventos:
1. el encargado de despacho introduce el criterio de busqueda.
2. ejecuta la busqueda.
3. muestra el resultado.

Pre-condiciones:

Post-condiciones: resultado de la busqueda.

Notas: Ninguna

CU8 Ordenar encomiendas

Diagrama:

Actores: Encargado de recepcion de almacen

Flujo de eventos:
1. El encargado de recepción de almacén realiza una búsqueda de listas de depacho
2. El encargado selecciona una lista de despacho para ver su contenido
3. El encargado busca una encomienda en la lista de despacho seleccionada
4. El encargado selecciona una encomienda para ver su información
5. El encargado asigna una ubicacion para la encomienda seleccionada
6. El encargado crea una lista de las encomiendas faltantes

Pre-condiciones: Las encomiendas deben estar registradas en la lista de despacho

Post-condiciones: Se tiene registrada la ubicacion (en almacen) de cada encomienda y la lista de encomiendas que faltan

Notas: Segun la lista de despacho se va verificando la encomienda y a esta se le asigna una ubicación en el almacén este dato
tiene que actualizarse en el sistema. Y de las encomiendas que no se encuentran (fisicamente) se elabora una lista.

CU9 Entrega de encomiendas

Diagrama:

Actores: Encargado de recepcion, cliente.

Flujo de eventos:
1. El encargado busca una encomienda mediante los datos personales del destinatario (un cliente)
2. Si no se encuentra la encomienda:
a. Se busca la encomienda mediante otros datos mas específicos (como ser direcciones)
b. Si tampoco se encuentra la encomienda mediante esta búsqueda:
i. Se crea una incidencia respecto al problema y se notifica al usuario
3. Si se encuentra la encomienda:
a. El encargado actualiza el estado de la misma en el sistema como entregada
4. Si la encomienda fue enviada en modalidad de pago en destino:
a. Se realiza el cobro de la encomienda

Pre-condiciones: Todas las encomiendas que llegaron deben estar registradas en el sistema.
Se crean incidencias solo para las encomiendas que esten registradas.

Post-condiciones: Se tiene el registro de las encomiendas que fueron entregadas.

Notas: Ninguna

CU10 Recepcion de giros

Diagrama:

Actores: Encargado de giros, cliente.

Flujo de eventos:
1. El encargado de giros busca si ya existen los datos del cliente en el sistema
2. Si los datos del cliente no existen:
a. El encargado crea un contacto con los datos del cliente.
3. El encargado busca si ya existe los datos del destinatario en el sistema.
4. Si los datos del destinatario no existen:
a. El encargadp crea un contacto con los datos del destinatario.
5. El encargado crea el detalle de giro
6. El encargado selecciona la modalidad del giro
7. El sistema le permite al encargado realizar el cálculo automático de la comisión a pagar por el giro
8. El encargado imprime un recibo
9. El encargado imprime factura y se la entrega al cliente.

Pre-condiciones: El encargado de giros debe estar validado en el sistema

Post-condiciones: Se tienen registrados los datos del giro.

Notas: Ninguna

CU11 Entrega de giros

Diagrama:

Actores: Encargado de giros, cliente.

Flujo de eventos:
1. El encargado busca los datos del giro mediante información proporcionada por el cliente
2. El encargado actualiza el estado del giro como entregado
3. El encargado imprime un comprobante y lo entrega al cliente

Pre-condiciones: Todos los giros deben estar registradas en el sistema y el encargado de giros debe estar validado en el sistema

Post-condiciones: Se tiene el registro de los giros que fueron entregados

Notas: La busqueda del giro debe ser por destinatario en caso de no encontrar se debe usar la busqueda avanzada (busqueda
por otros campos).