# Prompts de actualización (frontend + backend) Usar siempre junto con las reglas del proyecto en `.cursorrules` y los scripts SQL en `database/sql/` (sin depender de migraciones para desplegar esquema). **Cómo usar:** copia un bloque completo en el chat de Cursor (o adjunta `@` los archivos que indique el prompt). Ejecuta por fases si el alcance es grande. --- ## Fase 0 — Inventario y datos **Prompt 0.1 — Mapa del dominio venta / tienda / envío** ``` Según .cursorrules, analiza el flujo de venta en línea (tienda): modelos Venta, Tienda, Pago, TipoPago, Envio, relaciones en VentaController y rutas en routes/api.php. Documenta en comentarios breves: qué significa es_pago_tienda, es_tienda_online, cómo se registra envío (tabla envios) y dónde el cliente o admin marcan "pedido enviado". No cambies código aún. ``` **Prompt 0.2 — Configuración empresa** ``` Localiza dónde se guarda hoy la configuración general de empresa (impresión, correos, etc.): ConfigImpresion, ConfigCorreo, vistas en resources/js/src/views/configuracion/, repositorios asociados y tablas involucradas. Propón dónde añadir campos nuevos: días máximos para cancelar venta en línea tras pago, y días hábiles máximos para devolución (SLA informativo al cliente), editables por administrador. Salida: lista de archivos + columnas SQL sugeridas para database/sql/cambios_pendientes.sql. ``` --- ## Fase 1 — Ticket de venta: desglose por forma de pago **Prompt 1.1 — Backend: datos del ticket** ``` En VentaController (o el endpoint que ya alimenta el ticket) y modelo Pago/TipoPago, asegura que al cargar una venta para impresión/previsualización se devuelvan todos los pagos con tipo_pago (nombre/código) e importe por línea. Si falta, amplía la respuesta JSON sin romper consumidores actuales. Respeta .cursorrules. ``` **Prompt 1.2 — Frontend: módulo ventas** ``` En resources/js/src/views/ventas/index.vue (y vender.vue si comparte lógica), en el HTML del ticket (#printable-content-ticket / modal de ticket), muestra una tabla o lista: cada forma de pago (efectivo, débito, crédito, crédito cliente, transferencia, etc.) con el monto pagado en esa línea, usando los datos de form.pagos o la respuesta del API. Mantén el diseño del ticket actual (tipografía/impresión). ``` **Prompt 1.3 — Frontend: historial de ventas** ``` Localiza la vista de historial / verificación de ventas en línea (ej. ventas/verificar.vue o rutas relacionadas con VentaRepository.paginacionTiendaVerificar). Añade la misma visualización de desglose por tipo de pago en el detalle o ticket si el usuario lo imprime desde ahí. Reutiliza componentes o funciones si es posible. ``` --- ## Fase 2 — Correos: venta, venta en línea, cita **Prompt 2.1 — Unificar estilo de plantillas** ``` Revisa app/Mail/ y resources/views/mails/ (incl. avisos de venta y cita). Elige una plantilla base "profesional" existente y alinea las demás: mismo header/footer, tipografía, botones y textos legales breves. Actualiza las clases Mailable si hace falta pasar más datos. No rompas asuntos ni rutas de envío actuales sin revisar VentaController/SesionController. ``` **Prompt 2.2 — Contenido específico** ``` Para correos de: (1) venta confirmada, (2) venta en línea / tienda, (3) cita — asegura que incluyan resumen claro (montos, sucursal si aplica, siguiente paso). Textos en español, tono formal. Variables Blade sin datos sensibles innecesarios. ``` --- ## Fase 3 — Cancelación venta en línea (reglas + borrado lógico + correos) **Prompt 3.1 — Esquema y modelo** ``` Implementa borrado lógico de ventas canceladas por el cliente (no DELETE físico): columnas necesarias en ventas (ej. deleted_at o cancelado_en_linea + motivo; alinea con campos existentes cancelado, observacion_cancelado). Añade SQL a database/sql/cambios_pendientes.sql. Actualiza app/Models/Venta.php ($fillable, SoftDeletes o scopes whereNull). Documenta impacto en reportes, cortes de caja, inventario y listados: deben excluir o marcar ventas canceladas según reglas de negocio. ``` **Prompt 3.2 — Reglas de negocio cancelación** ``` Endpoint dedicado (cliente autenticado, venta es_tienda_online / es_pago_tienda según corresponda): permitir cancelar solo si: (a) el pedido no ha sido enviado — usar tabla envios / estatus coherente con el código existente; o (b) el cliente pagó y la fecha de pago no supera N días (N desde configuración general empresa en BD). Si no existe bando "enviado", créalo o usa fecha_envio/estatus en envios. Validación en backend; mensajes claros al frontend. Respeta .cursorrules y rutas api.php. ``` **Prompt 3.3 — Config administrable** ``` Añade en la tabla de configuración general (la que definas en Fase 0) los campos: dias_max_cancelacion_venta_linea_tras_pago y dias_habiles_max_devolucion_aviso (o nombres consistentes). Pantalla de administración para editarlos, API GET/PATCH, y uso en las validaciones del Prompt 3.2 y en textos al cliente (aviso de devolución manual hasta X días hábiles). ``` **Prompt 3.4 — Notificaciones cancelación** ``` Al cancelar con éxito: enviar correo al administrador (correo(s) desde config existente) con datos de venta, cliente, formas de pago y texto de que la devolución es MANUAL. Correo al cliente confirmando cancelación y advirtiendo plazo de devolución según configuración. Usa Mailable nuevo o existente en app/Mail/. ``` **Prompt 3.5 — Frontend tienda / cliente** ``` En el flujo de cliente (tienda, carrito, historial de pedidos): botón cancelar visible solo si el backend indica que puede; mostrar mensajes de SLA de devolución desde la API/config. No eliminar filas en UI; mostrar estado "Cancelada". ``` --- ## Fase 4 — Cliente local: citas + pago + precios tratamientos **Prompt 4.1 — Detección cliente local** ``` Revisa Cliente (campo tipo), User y sesión en frontend. Define regla única: "cliente logueado y tipo local" para mostrar precios de tratamientos y flujo de cita con pago. Lista archivos: citas/reservar.vue, repositorios, SesionController, rutas API. ``` **Prompt 4.2 — Precios solo local** ``` Ocultar o anonimizar precios de tratamientos en vistas públicas; mostrar precios solo si el usuario es cliente tipo local autenticado. Ajustar endpoints si hoy exponen precios sin filtro. ``` **Prompt 4.3 — Cita pendiente de pago (similar a tienda)** ``` Diseña flujo: agendar cita crea sesión/cita en estado "pendiente de pago" hasta que el cliente complete pago en línea (reutilizar patrón de Tienda/Venta con es_pago_tienda o equivalente para sesiones). Incluir: pasarela/forma de pago, comprobante, y cola para que administración valide el pago manualmente (similar a paginacionTiendaVerificar). Backend + SQL en cambios_pendientes.sql + vistas Vue + notificaciones por correo al administrador y cliente. ``` **Prompt 4.4 — Coherencia con venta en línea** ``` Asegura que validación manual de pago de cita reutilice los mismos patrones de UI/estados que la verificación de ventas en línea (listados, filtros, mensajes), sin duplicar lógica innecesariamente. ``` --- ## Verificación final **Prompt Z — Pruebas manuales guiadas** ``` Genera una checklist en comentarios: (1) ticket con varios tipos de pago, (2) correos renderizados, (3) cancelación permitida/prohibida según envío y días, (4) venta cancelada no rompe corte de caja, (5) cliente no local no ve precios, (6) cliente local agenda y paga cita. Sin automatizar tests salvo que ya existan en tests/. ``` ### Checklist manual (Prompt Z) Marcar cada ítem al validar en un entorno de prueba (datos no productivos). No sustituye pruebas automatizadas: solo ejecutar lo que exista bajo `tests/` si aplica. #### (1) Ticket con varios tipos de pago - [ ] Crear o cargar una **venta** con al menos **dos** líneas de pago distintas (p. ej. efectivo + transferencia, o las que use el mostrador). - [ ] Abrir el ticket / vista de impresión (`ventas/index.vue`, `vender.vue` o modal de ticket según flujo). - [ ] Comprobar que el ticket lista **cada forma de pago** con su **importe por línea** (desglose coherente con `Pago` / `TipoPago` y respuesta del API). - [ ] Desde **Ventas en línea por confirmar** (`/ventas/confirmar`), si se imprime ticket o detalle, el desglose coincide con lo anterior. #### (2) Correos renderizados - [ ] Disparar al menos un correo de **venta confirmada** / tienda y revisar plantilla en bandeja (o modo prueba de `ConfigCorreo` si está activo). - [ ] Revisar un correo de **cita** (nueva cita / activación) y comprobar datos mínimos: montos o texto claro, sucursal si aplica, sin datos sensibles de más. - [ ] Si se probó cancelación (Fase 3), abrir los correos de **cancelación** a admin y cliente y validar tono y plazos SLA si se muestran. #### (3) Cancelación permitida / prohibida (envío y días) - [ ] Con usuario **cliente en línea**, pedido **sin enviar** (sin `fecha_envio` o equivalente): **cancelar** debe **permitirse** si el backend indica `puede_cancelar_cliente` (o flag equivalente). - [ ] Mismo pedido **ya enviado**: cancelación debe **denegarse** con mensaje claro (validación backend). - [ ] Pedido **pagado y verificado**: cancelar **dentro** de `dias_max_cancelacion_venta_linea_tras_pago` (config empresa) → según reglas implementadas; **fuera** del plazo → **denegada**. - [ ] Confirmar que el botón cancelar en **tienda / mis compras** respeta lo que devuelve la API (oculto o deshabilitado cuando no procede). #### (4) Venta cancelada no rompe corte de caja - [ ] Registrar una venta en línea cancelable, cancelarla desde el flujo cliente. - [ ] Generar o revisar un **corte de caja** que incluya el periodo: la venta cancelada **no** debe sumar como venta válida (o debe figurar como cancelada según reglas del listado). - [ ] Comprobar que **no** hay error 500 al abrir detalle de corte / reportes que filtren `cancelado`. #### (5) Cliente no local no ve precios (tratamientos) - [ ] Iniciar sesión como **Cliente** `tipo_cliente` = **cliente_linea** (u otro no local según regla del proyecto). - [ ] Llamar o usar UI que consuma `POST /api/tratamientos/all`: **precio / total / iva** deben ir **anónimos o nulos** en respuesta. - [ ] Opcional: abrir modal de tratamientos en flujo donde aplique y confirmar que no se muestran importes. #### (6) Cliente local agenda y paga cita - [ ] Iniciar sesión como **Cliente** **local** (`cliente_local`). - [ ] En **Reservar** (`/citas/reservar`), completar cita con **transferencia** + **comprobante** y guardar. - [ ] Verificar en BD o API que la sesión queda con `es_pago_cita = no` (pendiente de verificación) y comprobante almacenado. - [ ] En **Confirmar → Pagos citas (transferencia)** (`/citas/verificar-pagos`), **autorizar pago**: la cita pasa a aprobada, `es_pago_cita = si`, y el cliente recibe notificación de activación si el flujo de correo está configurado. --- **Nota:** Si existe suite en `tests/`, ejecutar `php artisan test` (o el comando del proyecto) como complemento; el Prompt Z no exige nuevos tests automatizados. --- ## Orden sugerido 0 → 1 → 2 pueden paralelizarse en parte; **3 depende de 0** (config + envíos); **4 es grande** y conviene después de tener claro el patrón de tienda (Fase 0).