Flujos de Trabajo
Este documento describe los flujos de trabajo principales del sistema UnoSportClub.
Flujo de Reserva por Cliente
El flujo completo de reserva realizado por un cliente incluye los siguientes pasos:
-
Cliente accede al sitio web
-
Cliente hace clic en "Reservar"
-
Sistema muestra el asistente de reserva
-
Cliente selecciona cantidad de canchas necesarias
-
Sistema consulta disponibilidad
-
Sistema muestra calendario semanal con disponibilidad
-
Cliente selecciona fecha y hora
-
Sistema verifica canchas disponibles para esa fecha/hora
-
Cliente selecciona canchas específicas y define lapso de tiempo
-
Sistema crea la reserva (estado: amarillo/pendiente)
-
Sistema muestra datos de pago y campo para número de confirmación
-
Cliente ingresa número de confirmación de pago
-
Sistema conecta WebSocket para escuchar registro de pago
-
Sistema compara número de referencia:
-
Si el pago fue registrado antes del número ingresado: alinea automáticamente
-
Si el número fue ingresado antes del pago: espera coincidencia
-
-
Cuando hay coincidencia, sistema cambia estado de reserva a "comprada" (verde)
-
Cliente llega a la cancha y solicita Check-in
-
Operador registra la presencia del cliente
-
Sistema confirma asistencia registrada
Ver diagrama de secuencia completo en Diagrama de Secuencia: Flujo de Reserva.
Flujo de Reserva por Operador
El flujo de reserva realizado por un operador es similar pero gestionado directamente:
-
Operador accede al sistema
-
Operador crea reserva para cliente
-
Operador selecciona cantidad de canchas
-
Sistema consulta disponibilidad
-
Operador selecciona fecha, hora y canchas
-
Operador define lapso de tiempo
-
Sistema crea la reserva
-
Operador registra el pago
-
Sistema confirma pago
-
Cuando el cliente llega, operador registra asistencia
-
Sistema confirma asistencia registrada
Ver diagrama de secuencia completo en Diagrama de Secuencia: Flujo de Reserva (Operador).
Flujo de pago en reserva
Los pagos de reserva se registran en el paso Pago del wizard de reserva (/booking/payment/:id):
-
El operador ingresa monto, tipo de pago y
transaction_id, guarda con + y puede adjuntar la captura con el botón verde Subir (o integraciones víaPOST/PATCHmultipart). -
POST /admin/booking/{bookingId}/paymentacepta JSON (foto = null) o multipart (fotoobligatorio);PATCH …/payment/{paymentId}en multipart añade o reemplaza comprobante. La API usaPaymentReceiptStorage(S3/R2 privado). -
El operador valida pagos pendientes ya vinculados desde Pagos → Pendientes (
PATCH /admin/payments/:idconstatus: true). -
Ver abre el modal con
GET …/payment/{paymentId}/foto(Bearer + CSRF). Eliminar comprobante (modal) llamaDELETE …/payment/{paymentId}/foto(borra objeto en bucket ypayment.foto = null). Eliminar pago (icono papelera en la fila) llamaDELETE …/payment/{paymentId}; si el pago tenía comprobante, también se elimina del bucket antes de borrar el registro.
No existe conciliación manual de pagos sin reserva ni inscripción desde el panel.
Referencia API: Comprobantes de pago. Diagramas: Subida y Visualización privada.
Flujo de creación de evento (operador)
Operador en panel (/events/new):
-
Selección de slot en calendario (cancha + rango horario mural).
-
Datos del evento: título,
event_type_id, capacidad, descripción opcional. -
POST /admin/events→ reserva pendiente tipo Evento + filaevent. -
Asignación de participantes por casilla (
POST /admin/events/{id}/participants) con boleto disponible del cliente. -
La reserva aparece en agenda (
/booking) conevent_idasociado.
Diagrama: Diagramas de Ingeniería (secuencia creación de evento).
Flujo de tickets (emisión panel)
-
Operador abre
/tickets(listado de ventas alineado conGET /admin/tickets/sales). -
Wizard de emisión: cotización (
POST /admin/tickets/quote) y venta (POST /admin/tickets/sales). -
Boletos quedan
availablehasta usarse en unevent_participant.
Ver xref:api-reference.adoc y xref:enrollment-payment-module.adoc.
Flujo de Disponibilidad
El sistema calcula la disponibilidad considerando:
-
Consulta todas las reservas existentes para el rango de fechas
-
Filtra por cancha y tipo de cancha si se especifica
-
Calcula slots disponibles basándose en:
-
Horarios de operación de las canchas
-
Reservas existentes (ocupadas)
-
Cantidad de canchas requeridas vs disponibles
-
-
Retorna slots disponibles marcados como disponibles/no disponibles
Un slot se marca como no disponible si: * Ya hay una reserva confirmada en ese horario * No hay suficientes canchas disponibles para la cantidad requerida
Flujo de Check-in
Cuando un cliente llega a la cancha:
-
Cliente solicita Check-in (desde la aplicación o en persona)
-
Sistema notifica al operador sobre la solicitud
-
Operador verifica la identidad del cliente
-
Operador registra la presencia del cliente
-
Sistema actualiza
RESERVATION.checkingcon la fecha/hora actual -
Sistema confirma el Check-in al cliente