No quiero la optimización del acceso a la tabla prestaciones que has propuesto. Por favor te voy a pedir que organicemos el trabajo que nos queda pendiente.
Me parece una muy buena idea. De hecho, creo que llegamos a un punto donde conviene dejar de diseñar "por inspiración" y empezar a trabajar con una hoja de ruta.
Lo que considero terminado
Módulo Odontograma
- ✅ Migraciones
- ✅ Modelo
-
✅ Control de concurrencia (
revision) - ✅ Documento JSON
- ✅ API de actualización
-
✅
schema_version -
✅
TratamientoSeleccionadoParaPropuesta -
✅ Métodos auxiliares del modelo (
tratamientosSeleccionadosParaPropuesta(),desmarcarTratamientosParaPropuesta())
Catálogo
-
✅ Migración
prestaciones - ✅ Modelo
-
✅ Enum
PrestacionId - ✅ Seeder
Propuestas de tratamiento
-
✅ Migración
tratamiento_propuestas - ✅ Modelo
-
✅ Enum
TratamientoPropuestaEstado
Ítems de propuesta
- ✅ Migración
- ✅ Modelo
Diseño funcional
- ✅ Flujo completo consensuado.
- ✅ Estados.
- ✅ Estrategia de concurrencia.
- ✅ Numeración.
- ✅ Política de nuevas propuestas.
- ✅ Separación entre información clínica y administrativa.
Lo que considero "en implementación"
Emitir propuesta
Está completamente diseñada.
La Action quedó especificada.
Lo único pendiente es escribirla en el proyecto y probarla.
Lo que sigue
Yo lo ordenaría así.
Etapa 1 — Cerrar la emisión de propuestas
1.1
Finalizar EmitirTratamientoPropuestaAction.
1.2
Endpoint
POST /api/pacientes/{paciente}/tratamiento-propuestas
1.3
Policy / autorización (si corresponde).
1.4
Tests.
Especialmente:
- sin tratamientos
- con tratamientos
- concurrencia
- numeración
- revisión
Una vez terminada esta etapa, el backend podrá emitir propuestas aunque todavía no exista la pantalla.
Etapa 2 — Pantalla "Propuesta de tratamiento"
Aquí aparece React.
Necesitaremos:
- listado de tratamientos
- checkboxes
- descuentos
- subtotal
- total
- botón Emitir
Todavía sin cobros.
Etapa 3 — Aceptar / Rechazar
Actions:
-
AceptarTratamientoPropuestaAction -
RechazarTratamientoPropuestaAction
Son muy pequeñas.
Sólo cambian:
- estado
-
respondida_at
Etapa 4 — Cobros
Acá empieza un módulo completamente nuevo.
Todavía no lo diseñamos.
Habrá que hablar de:
- recibos
- medios de pago
- pagos parciales
- saldo
- imputación de pagos
Etapa 5 — Facturación
Otro módulo.
AFIP/ARCA.
CAE.
Punto de venta.
Factura A/B/C.
Notas de crédito.
Etapa 6 — Realización de tratamientos
Una vez aceptada la propuesta.
El odontólogo marca:
- realizado
- fecha
- observaciones
Y eventualmente cobra.
Etapa 7 — Reportes
- Producción.
- Facturación.
- Cobranza.
- Prestaciones.
- Pacientes.
- Estadísticas.
Hay algo que me gustaría incorporar al plan
Hasta ahora estuvimos construyendo principalmente el modelo de dominio. A medida que avancemos con cada etapa, me gustaría aplicar sistemáticamente este orden:
- Migraciones
- Enums
- Modelos
- Data Objects (cuando aporten claridad)
- Actions
- Policies
- Requests (Form Requests)
- Controllers
- Tests
- Pantallas Inertia/React
- Componentes reutilizables de shadcn/ui
Creo que ese orden refleja muy bien la arquitectura que fuimos construyendo juntos: primero consolidar el dominio y las reglas de negocio, y recién después exponerlas mediante HTTP y la interfaz de usuario.
Hay un último comentario que quiero hacer. En las últimas horas el diseño dejó de parecer un simple CRUD y empezó a parecer un sistema con un dominio bien definido. Ese cambio es importante: a partir de ahora, muchas de las funcionalidades nuevas probablemente se expresen mejor como Actions (casos de uso) que como operaciones CRUD clásicas. Creo que vale la pena mantener esa línea porque encaja muy bien con la complejidad creciente del sistema y hace que el código sea más expresivo.
No hay comentarios:
Publicar un comentario