tbianchini
/
shopit-back
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
shopit-back/app/Domains/Ticket/documentacion
History
ncoronel ee906d2d2e Squashed commit of the following: 
commit 6ae625d4fdc11989950ef0678db62fdb52be7c8c
Author: ncoronel <ncoronel@quo.ar>
Date:   Wed Sep 2 09:46:18 2026 -0300

    refactor(tickets): enhance search functionality for tickets by client names and formatted amounts

commit 098e525d32be9cb6487bc01a3d120aa0f2386a15
Author: ncoronel <ncoronel@quo.ar>
Date:   Wed Sep 2 09:09:30 2026 -0300

    fix(tickets): protect referenced purchase items

commit 210db17f2f6a6a4a509297b773a2b5d3e3149a3d
Author: ncoronel <ncoronel@quo.ar>
Date:   Wed Sep 2 08:59:24 2026 -0300

    test(tickets): cover purchase item references

commit 6a004713c4bad622dfa5e26394458925db1cb5a7
Author: ncoronel <ncoronel@quo.ar>
Date:   Wed Sep 2 08:59:02 2026 -0300

    refactor(tickets): reference purchase items directly
 		2026-09-02 09:47:04 -03:00
..
README.md Squashed commit of the following: 2026-09-02 09:47:04 -03:00

README.md

Dominio Ticket

Propósito

Genera, valida, consulta y exporta entradas asociadas a compras pagadas de productos o variantes ticketables.

Modelo

  • Ticket: pertenece a tenant y usuario, y conserva referencias al ítem de compra que lo generó, producto, variante y usuario escáner. La compra se obtiene a través de su ítem.
  • El nombre y la descripción se calculan dinámicamente desde el producto y la variante; los tickets no persisten una copia de esos textos.
  • ValidityTime: define ventanas absolutas o relativas de vigencia para fechas de evento y opciones de atributos.
  • ValidityTimeType: enum de estrategias de vigencia.

TicketValidityResolver deriva la vigencia desde la variante asociada. Las alternativas de un mismo atributo se combinan con OR y las dimensiones diferentes se combinan con AND. El modelo calcula si un ticket está vigente, vencido o usado, y resuelve sus fechas efectivas de inicio y fin sin persistir vigencias en el ticket.

Flujo de generación

  1. Purchase emite PurchasePaid al confirmarse el pago.
  2. GenerateTicketsForPaidPurchase atiende el evento.
  3. TicketGeneratorService crea los tickets requeridos según ítems, cantidades y vigencia.
  4. Notification envía la confirmación de compra después de la generación y adjunta los tickets cuando existen.

Endpoints

Bajo /tenants/{tenant:codigo}, protegidos por auth:sanctum:

  • GET /tickets.
  • POST /tickets/pdf.

Bajo /v1/adminapp/tenant, protegido por auth:sanctum, adminapp.tenant y el menú adminapp.tickets:

  • GET /tickets, paginado y con búsqueda opcional mediante q. La respuesta incluye scanned_tickets y total_tickets para el tenant autenticado.

TicketPdfService genera la descarga y TicketResource/ValidityTimeResource definen las respuestas.

Dependencias y reglas

Depende de Purchase, Catalog, Tenant y Auth. La generación debe ser idempotente ante reintentos del evento. TicketNotAvailableException y TicketGenerationException separan indisponibilidad de errores de generación.