Del interés comercial al contrato
Diseñé el flujo comercial de Rancho Flor María para que una consulta pueda avanzar a cotización y llegar a contrato cuando se cumplan las reglas de formalización.
- Responsabilidad
- Único desarrolladorAnálisis, diseño e implementación del flujo.
- Trazabilidad
- 9 reglas de negocio documentadasVinculadas con el código y las pruebas.
- Validación del backend
- 171/171 pruebas aprobadasResultado de E04 en SQLite en memoria con datos sintéticos, confirmado después en GitHub Actions sobre a95ce07.
- Proyecto
- RFM CORE
- Competencia principal
- Análisis funcional e ingeniería de requisitos
- Periodo
- 2026
Cuándo se exige un paquete
Registrar la solicitud pública
La persona puede enviar una solicitud de servicio completo con el paquete pendiente. El personal puede confirmarla en ese estado.
Formalizar el contrato
Para convertir esa cotización confirmada, RFM CORE exige un paquete. Si falta, rechaza la conversión y conserva la cotización sin crear un contrato.
Problema y contexto
En Rancho Flor María, una consulta podía empezar con una fecha tentativa, un número estimado de invitados y una modalidad por decidir. El sistema debía conservar esa información durante el seguimiento y distinguirla de las condiciones acordadas al contratar. La fecha tentativa se registra como dato de la solicitud.
Alcance y participación
Definí los datos, las reglas y las transiciones del proceso comercial. Implementé el flujo en React y las validaciones de negocio en Django REST Framework.
Análisis y decisiones
Separé la cotización del contrato para distinguir una oportunidad de una operación formalizada. Reservé la conversión para cotizaciones confirmadas e incorporé instantáneas para recuperar las condiciones de la oferta cuando son compatibles con los términos finales.
Trabajo realizado
Modelé las etapas del proceso y las traduje en entidades, servicios y validaciones. Después documenté la relación entre las reglas, el código y las pruebas, y preparé escenarios para comprobar la conversión y el uso de ofertas históricas.
Validación y resultados
La auditoría local E04 del 11 de noviembre de 2026 partió de d9fe5ae con ajustes de pruebas. QA-06 comprueba el rechazo de la conversión sin paquete y QA-14 distingue cuándo se reutiliza o reconstruye la oferta histórica. Las regresiones se integraron mediante el PR #2. Después, GitHub Actions validó por separado el commit a95ce07 de main: 171/171 pruebas de backend y 25/25 de frontend. La ficha E04 enlaza las pruebas y la ejecución de CI.
Resultados y límites
Las pruebas del backend usaron SQLite en memoria y datos sintéticos. El rechazo de una segunda conversión se comprobó de forma secuencial; queda sin validar la concurrencia con PostgreSQL. E04 no cubrió recorridos de interfaz en navegador ni el envío efectivo de mensajes. La captura de E01 ilustra el alta pública y los resultados de CI no acreditan recorridos de extremo a extremo. El impacto en tiempos de atención, conversión y rentabilidad sigue sin medir.
Evidencias
E01 — Proceso comercial
Distingue la atención comercial del registro en RFM CORE, con una captura de la precotización con datos sintéticos.
Consultar evidenciaE02 — Trazabilidad funcional
Vincula las nueve reglas con el código y las pruebas que las respaldan.
Consultar evidenciaE03 — Decisiones de diseño funcional
Explica la separación entre cotizaciones y contratos, las transiciones y el uso de ofertas históricas.
Consultar evidenciaE04 — Pruebas y resultados
Documenta la auditoría local, enlaza las regresiones integradas y distingue los resultados de GitHub Actions.
Consultar evidencia
Aprendizajes
Aprendí a definir qué significa cada estado y a comprobar las condiciones de cada transición. Los escenarios de oferta histórica me ayudaron a distinguir qué datos deben conservarse y cuándo la aplicación los reconstruye.