Módulo cuenta corriente para appa odontológica

El odontólogo requiere ver el monto adeudado por cada paciente (en forma individualizada), y registrar pagos del paciente. La deuda se genera a partir de cada propuesta que el paciente acepta y se cancela a partir de los pagos que este realiza. Antes de empezar a producir código, ¿me harías algunas preguntas a cerca del requerimiento y del diseño de varios aspectos del sistema?

Excelente requerimiento. Antes de escribir una línea de código, necesito entender varios aspectos clave para diseñar algo que realmente funcione en el contexto de tu clínica. Aquí van mis preguntas:

💰 Preguntas sobre el Flujo de Deuda y Pagos

1. Momento de generación de la deuda

¿La deuda se genera automáticamente cuando la propuesta cambia a ACEPTADA?
¿O el odontólogo debe "facturar" o "confirmar" la deuda manualmente después de la aceptación?
¿Qué pasa si una propuesta es aceptada pero luego el paciente no se presenta? ¿La deuda sigue activa?

2. Estructura de la deuda

¿Cada ítem de la propuesta genera una deuda individual, o la deuda es por propuesta completa?
Ejemplo: Propuesta con 3 tratamientos → ¿3 deudas independientes o 1 deuda total?
Si es por ítem, ¿el paciente puede pagar un tratamiento específico (ej: "extracción") y dejar otro pendiente (ej: "implante")?

3. Pagos y abonos

¿Se pueden registrar pagos parciales (abonos) sobre una deuda?
- Ejemplo: Deuda total $1000 → paga $300 hoy, $300 en 15 días, $400 al finalizar tratamiento.
¿Los pagos se asocian a:
- Una propuesta completa (pago general)?
- Un ítem específico de la propuesta?
- Una sesión/consulta particular?

4. Medios de pago

¿Qué medios de pago se registran? (Efectivo, tarjeta de crédito/débito, transferencia, obra social, etc.)
¿Necesitan diferenciar entre pago "en efectivo" y pago "por obra social"?
¿Registran cobros con tarjeta (con descuento por comisión)?

5. Moneda

¿Trabajan con una sola moneda (ARS) o múltiples monedas?
¿Los precios de las prestaciones son fijos o pueden variar según el paciente?

6. Obra social

Algunos pacientes tienen obra social. ¿Cómo afecta eso a la deuda?
¿La obra social cubre un porcentaje y el paciente paga el resto?
¿La clínica cobra directamente a la obra social o el paciente paga y luego se reintegra?

7. Estados de la deuda

¿Qué estados debería tener una deuda?
- PENDIENTE → Deuda activa sin pagos
- PARCIAL → Deuda con pagos parciales
- CANCELADA → Deuda totalmente pagada
- VENCIDA → Deuda con fecha de vencimiento pasada (si aplica)
¿Necesitan fechas de vencimiento por ítem o por propuesta?

8. Historial y conciliación

¿Necesitan un historial de todos los pagos registrados?
¿El odontólogo puede anular un pago mal registrado?
¿Necesitan un "saldo actual" que se actualice en tiempo real?

9. Relación con el tratamiento real

¿El pago se asocia al tratamiento realizado o al tratamiento presupuestado?
Ejemplo: El paciente acepta y paga una extracción, pero luego el odontólogo decide hacer un tratamiento diferente. ¿Cómo se ajusta la deuda?

10. Pantallas y UX

¿Dónde y cómo quiere ver el odontólogo la deuda del paciente?
- En la pantalla del paciente (dashboard individual)
- En la lista de pacientes (columna con saldo pendiente)
- En la pantalla de la propuesta
¿Cómo quiere registrar un pago?
- Desde la pantalla del paciente
- Desde la pantalla de la propuesta
- Con un botón "Registrar pago" que abre un modal/formulario

11. Reportes

¿Necesitan reportes de:
- Deuda total de todos los pacientes
- Deuda por paciente
- Pagos recibidos en un período (diario/semanal/mensual)
- Pacientes con deuda vencida

12. Integración con otras áreas

¿Esto se integra con la agenda? (ej: no atender si tiene deuda)
¿Esto se integra con el odontograma? (ej: marcar tratamientos como "pagados")

13. Múltiples propuestas por paciente

Un paciente puede tener varias propuestas aceptadas simultáneamente. ¿La deuda es la suma de todas? ¿Se pueden pagar propuestas por separado?

14. Responsabilidad

¿Quién registra los pagos? ¿El odontólogo, la recepcionista, o ambos?
¿Se necesita un sistema de permisos para registrar pagos? (ej: solo admins pueden registrar pagos)

15. Consideraciones legales

¿Necesitan emitir recibos/facturas por los pagos recibidos?
¿Se integra con algún sistema de facturación electrónica (AFIP)?

📋 Resumen de tus respuestas (para que me las envíes)

Para que no te pierdas, podés responder con un formato simple como:

1. Se genera al aceptar
2. Por ítem
3. Sí, pagos parciales
4. Efectivo y transferencia
...

Respondé las que puedas y las que no, las trabajamos juntos. Cuanto más claro tenga el flujo, mejor voy a poder diseñar la solución.

Se genera automáticamente. Si una propuesta es aceptada y luego el paciente no se presenta a la consulta la deuda sigue activa.
La deuda no es discriminada por ítem. La deuda integra una o más de una propuestas que haya aceptado el paciente.
Se puede ir haciendo pagos parciales. Los pagos son asociados a la cuenta de cada paciente, en donde todos los pagos que haya hecho este cancelan a todas las deudas contraídas por todas las propuestas que este haya aceptado.
El único medio de pago es efectivo.
Sólo pesos argentinos y precio fijo para cada prestación.
No se manejan obras sociales.
Están bien todos los estados, salvo que no debe haber estado VENCIDA pues no existe el concepto de vencimiento de una deuda.
No necesitan un historial de todos los pagos registrados. El odontólogo puede anular un pago mal registrado. No entiendo qué es un saldo actual que se actualice en tiempo real.
El pago se asociará a la cuenta del paciente, en donde se registrarán todas las deudas contraídas a partir de propuestas aceptadas y todas las cancelaciones de deuda a provenientes de pagos. Si el odontólogo decide hacer otro tratamiento, pasará esto: Cancelará la propuesta que ya estaba aceptada; se acreditará a la cuenta del paciente el valor de la propuesta; el odontólogo cambiará la indicación del tratamiento a realizar en el odontograma (esto ya está implementado) y lo incluirá en la propuesta (esto ya está implementado) junto con los otros tratamientos que hayan sido cancelados como parte de la cancelación de la propuesta (esto ya está implementado); el odontólogo generará una nueva propuesta (esto ya está implementado); al aceptar el paciente la propuesta se le debitará de su cuenta el nuevo valor de la propuesta; en la cuenta del paciente quedan registrado el movimiento de cancelación de la vieja propuesta y de aceptación de la nueva propuesta, con su correspondiente fecha e importe de crédito y débito respectivamente.
Habrá una pantalla de estado de cuenta y movimientos del paciente donde el formato será tal que se apreciará en primer lugar el saldo del paciente y en segundo lugar el detalle de los movimientos. Desde esta pantalla se podrá, tocando un botón, registrar un pago. Esta pantalla se podrá exportar a PDF.
El único reporte en PDF es el requerido en el punto 10.
No se integra.
Efectivamente puede tener varias propuestas aceptadas (esto ya está desarrollado así). La deuda es la suma de todas las propuestas aceptadas, como especifiqué en el punto 2 y 9. No se pueden pagar propuestas por separado, todo v a a una cuenta unificada por paciente.
Tanto el odontólogo como el/la recepcionista y el/la admin. pueden registrar pagos. No hace falta sistema de permisos para esto pues todos pueden registrar pagos.
Ni se necesita emitir recibo/factura ni se integra con AFIP ni nada por el estilo.

Te pido que antes de brindar una solución te cerciores de que las especificaciones y requerimientos son completos. Si no es así, podés seguir preguntándome.

Excelente, tengo un panorama mucho más claro. Las especificaciones son muy coherentes y el flujo está bien definido. Antes de empezar a diseñar la solución, tengo algunas preguntas de ajuste fino para asegurarme de que no falte nada:

🔍 Preguntas de Ajuste Fino

1. Saldo inicial y movimientos

¿El saldo de un paciente nuevo comienza en $0?
¿Se permiten saldos negativos? (ej: si se cancela una propuesta y el paciente ya había pagado, queda con saldo a favor)

2. Anulación de pagos

¿Cuando se anula un pago, se revierte automáticamente el saldo del paciente?
¿Se necesita un "motivo" o "observación" para anular un pago?
¿Se permite anular un pago de cualquier fecha o solo los recientes?

3. Cancelación de propuestas aceptadas

Cuando se cancela una propuesta aceptada (punto 9), ¿el crédito se aplica automáticamente a la cuenta del paciente?
¿La cancelación de una propuesta aceptada genera un movimiento en la cuenta (crédito)?
¿Quién puede cancelar una propuesta aceptada? ¿Solo el odontólogo o también la recepción?

4. Propuestas múltiples y orden de cancelación

Si un paciente tiene varias propuestas aceptadas y realiza un pago, ¿el pago se aplica a la deuda más antigua primero (FIFO) o se distribuye proporcionalmente?
Si se cancela una propuesta, ¿se cancela la más reciente o el usuario elige cuál?

5. Visualización del saldo

¿El saldo que se muestra en la pantalla principal del paciente es el saldo actual (deuda total - pagos)?
¿Se muestra en la lista de pacientes (ej: columna "Saldo") o solo en la vista individual de cada paciente?

6. Registro de pagos

Al registrar un pago, ¿se necesita:
- Fecha del pago (¿se usa la fecha actual o se puede seleccionar una fecha anterior?)
- Monto (obligatorio)
- Observación (opcional)
- ¿Quién registró el pago? (para auditoría)
¿Se pueden registrar pagos de $0? (no debería)

7. Movimientos en la cuenta

¿Qué tipos de movimientos deben registrarse?
- Débito: Propuesta aceptada (aumenta la deuda)
- Crédito: Pago registrado (disminuye la deuda)
- Crédito: Cancelación de propuesta aceptada (disminuye la deuda)
- ¿Algo más? (ej: ajuste manual)

8. PDF de estado de cuenta

¿El PDF debe incluir:
- Datos del paciente (nombre, documento)
- Saldo actual
- Lista de movimientos con fecha, descripción, débito, crédito y saldo acumulado
- Fecha de generación del reporte
- ¿Firma o sello del consultorio?

9. Integración con propuestas

Cuando una propuesta cambia de EMITIDA a ACEPTADA, ¿el movimiento se genera automáticamente o el usuario debe "confirmar" la aceptación?
Cuando una propuesta cambia de ACEPTADA a RECHAZADA (si es que eso puede pasar), ¿se revierte automáticamente el movimiento?

10. Concurrencia

¿Pueden dos usuarios registrar pagos para el mismo paciente al mismo tiempo?
¿Se necesita algún control para evitar inconsistencias (ej: usar transacciones DB)?

11. Auditoría

¿Se necesita saber quién registró cada pago y cuándo?
¿Se necesita un registro de quién anuló un pago o canceló una propuesta?

12. Redondeo y precisión

¿Los montos se manejan con 2 decimales?
¿Se permiten montos con más de 2 decimales? (ej: $1.234,56)

📋 Resumen de lo que entiendo hasta ahora

Aspecto	Decisión
Momento de generación de deuda	Al aceptar propuesta
Estructura de deuda	Cuenta unificada por paciente (no discriminada por ítem)
Pagos	Parciales, en efectivo, asociados a cuenta del paciente
Moneda	ARS, precios fijos
Obra social	No aplica
Estados	PENDIENTE, PARCIAL, CANCELADA (sin VENCIDA)
Anulación de pagos	Sí, con reversión automática
Cancelación de propuesta	Genera crédito en cuenta
Pantalla	Estado de cuenta con saldo + movimientos
PDF	Exportable desde la pantalla
Reportes	Solo el PDF de estado de cuenta
Permisos	Todos pueden registrar pagos
Facturación	No aplica

Respondé las preguntas que puedas y las que no las trabajamos juntos. Con esto ya puedo empezar a diseñar la estructura de datos y la lógica de negocio.

El saldo empieza en 0. Si ya había pagado una propuesta y la cancela le queda saldo a favor.
Cuando se anula un pago se revierte automáticamente el saldo del paciente. No se necesita un motivo ni observación. Se permite anular un pago de cualquier fecha.
Sí, el crédito se aplica automáticamente. Efectivamente, la cancelación de una propuesta aceptada genera un movimiento de crédito en la cuenta del cliente. La recepción también puede cancelar una propuesta.
No hay imputación de pagos a propuestas. Los pagos y las propuestas no tienen vinculación. Ambos afectan al saldo de la cuenta del cliente. Si se cancela una propuesta, el usuario elige cuál.
Efectivamente, se muestra el saldo actual. Con respecto al lugar en donde aparecerá este saldo, estamos hablando siempre de una pantalla de estado de cuenta (y movimientos) del paciente, eso lo especifiqué en el punto 10 de mi mensaje anterior inmediato. En la lista de pacientes no se muestra el saldo. La lista de pacientes ya la tengo implementada y no tengo la intención de cambiarla.
Se puede usar una fecha anterior. Efectivamente, se registra el monto (obligatorio), una observación (optativo), y quién registró el pago con tal de que sirva para auditoría. Pagos de $0 no se pueden.
Débito por aceptación de cuenta (aumenta la deuda), sí. Crédito por pago registrado (disminuye la deuda), sí. Crédito por cancelación de propuesta aceptada (disminuye la deuda), sí. Que haya un movimiento por ajuste manual.
Estoy de acuerdo con todos los items propuestos para incluir en el reporte. La firma y el sello del consultorio no está dentro del alcance del sistema, pero sí el nombre y la dirección del consultorio, que está en una tabla de consultorios del cual tengo a disposición para aportar en tanto que registro de diseño, la migración y el modelo.
El movimiento se genera automáticamente. Efectivamente puede pasar de ACEPTADA a RECHAZADA (eso vamos a tener que implementarlo), y no es que se "revierta" ningún movimiento, sino que se genera un nuevo movimiento (de crédito).
Sí, pueden. Sí, es necesario un control mediante transacciones de BD para asegurar la consistencia.
Los montos se expresan con 2 decimales y ninguno más.

Digo que tu resumen de lo entendido es correcto salvo que como expliqué en el punto 9, yo no quiero que se conceptualice la reversión como que se borra un movimiento, sino que incluso cuando es para cancelar algo, el procedimiento es siempre generar un movimiento nuevo.

Perfecto. Ahora tengo el cuadro completo. Las especificaciones son muy claras y el flujo está bien definido. Antes de pasar a la implementación, quiero confirmar un par de detalles finales:

✅ Preguntas Finales de Confirmación

1. Cancelación de propuesta aceptada (punto 9)

Confirmame el flujo exacto:

Odontólogo decide cancelar una propuesta aceptada
El sistema genera un movimiento de CRÉDITO en la cuenta del paciente por el monto total de esa propuesta
El estado de la propuesta cambia de ACEPTADA a RECHAZADA
El odontólogo genera una nueva propuesta (ya implementado)
El paciente acepta la nueva propuesta → se genera un movimiento de DÉBITO por el nuevo monto
El saldo final es: saldo anterior + crédito (cancelación) - débito (nueva propuesta)

Pregunta: ¿Cuando se cancela una propuesta, el crédito es por el monto total de la propuesta en el momento de la cancelación, o por el saldo pendiente de esa propuesta en particular?

Ejemplo: Paciente aceptó propuesta de $1000. Pagó $300. Ahora se cancela. ¿El crédito es por $1000 (total) o por $700 (lo que debe)?

2. Propuestas múltiples y cancelación

Si el usuario elige cancelar una propuesta específica, ¿se cancela una sola o puede seleccionar varias?
¿Se cancela desde la lista de propuestas del paciente o desde la cuenta?

3. Ajuste manual

Mencionaste "movimiento por ajuste manual". ¿Quién puede hacer ajustes manuales? ¿Solo administradores? ¿Se necesita un motivo obligatorio para el ajuste?

4. Reversión de pagos

¿Se puede anular un pago después de que se haya emitido una propuesta que lo "superó"?
Ejemplo: Pago $500, luego se cancela una propuesta y el saldo queda a favor. ¿Se puede anular ese pago original?

5. Movimientos en la cuenta

Confirmame los tipos de movimiento:

Tipo	Signo	Origen
`DEBITO`	+ (aumenta deuda)	Propuesta aceptada
`CREDITO`	- (disminuye deuda)	Pago registrado
`CREDITO`	- (disminuye deuda)	Cancelación de propuesta aceptada
`AJUSTE`	+/- (según corresponda)	Ajuste manual

¿Agregaría algún otro? (ej: ANULACION_PAGO que es un crédito que revierte un pago, o REVERSION_DEBITO por propuesta rechazada?)

6. Saldo a favor

Si el paciente tiene saldo a favor (ej: pagó $1000, luego se canceló la propuesta y solo debe $700), ¿ese saldo a favor se puede usar para pagar futuras propuestas?
¿El saldo a favor se muestra como un número positivo (ej: "+$300") o como un crédito disponible?

7. Campo "quién registró"

¿Se guarda el user_id del usuario logueado al momento de registrar el pago?
¿Se guarda también para las cancelaciones de propuestas y ajustes manuales?

8. Fechas en los movimientos

¿Los movimientos tienen dos fechas?
- created_at (fecha de creación en el sistema)
- fecha_movimiento (fecha que el usuario puede seleccionar, ej: pago realizado en efectivo el día 10 pero registrado el día 12)

9. Eliminación de movimientos

¿Se pueden eliminar movimientos directamente o siempre se usa el mecanismo de anulación/ajuste?

10. Tabla de consultorios

Para el PDF, ¿necesito los datos del consultorio desde la tabla consultorios?
¿Hay un consultorio por defecto o el sistema maneja múltiples consultorios?

📋 Resumen de lo que implementaremos

Componente	Descripción
Tabla `cuentas_paciente`	Saldo actual del paciente
Tabla `movimientos_cuenta`	Historial de movimientos (débito/crédito)
Modelo `CuentaPaciente`	Relación con Paciente, métodos para saldo
Modelo `MovimientoCuenta`	Tipo, monto, fecha, usuario, observación
Eventos	Disparadores automáticos al aceptar/cancelar propuesta
Pantalla	Estado de cuenta con saldo + movimientos
PDF	Exportable desde la pantalla

Cuando respondas estas preguntas, tengo todo para diseñar la solución completa.

Confirmo que entendiste bien el flujo y el cálculo del saldo final. Cuando se cancela una propuesta, el monto acreditado es por el total de la propuesta. Según tu ejemplo, el crédito será por 1000 (el total). Esto significa que le puede quedar saldo a favor al paciente.
Se cancela desde la lista de propuestas del paciente y se puede cancelar una a la vez.
Cualquier usuario puede realizar un ajuste en la cuenta y no se necesita un motivo para registrarlo.
Efectivamente. Los pagos y las propuestas se pueden generar y anular independientemente.
Que sean, no DEBITO ni CREDITO, sino: aceptación de propuesta (+), pago (-), rechazo de propuesta (-), ajuste (+/-), anulación de pago (+).
Efectivamente el saldo a favor se puede usar para futuras propuestas.
Sí. Sí.
Sí. Que como fecha de pago el sistema proponga la fecha actual y que el usuario la pueda cambiar.
Siempre se usa el mecanismo de anulación/ajuste. Los movimientos funcionan como un histórico inmodificable.
Necesitás el nombre y la dirección. El consultorio se selecciona manualmente y se mantiene en sesión de una manera muy similar al paciente, que creo que ya te he mostrado. No hay ningún consultorio por defecto.

Doy aviso de que leí el resumen y me parece todo bien. Sólo me generó inseguridad que los nombres de tablas que usaste (cuentas_paciente y movimientos_cuenta) confundan a Eloquent de modo que crea que son tablas de relaciones, cuando entiendo que son entidades y no relaciones. Pero si vos estás segura de que no se va a generar una confusión en Eloquent, vamos adelante con eso.

Perfecto. Tengo todo claro y las respuestas son consistentes.

Sobre tu inquietud de los nombres de tablas: no hay problema. Eloquent infiere nombres de tablas a partir del nombre del modelo en plural, no por la presencia de guiones bajos. CuentaPaciente → cuentas_paciente, MovimientoCuenta → movimientos_cuenta. Son nombres perfectamente válidos. Si querés evitarte cualquier duda, podemos usar cuentas y movimientos a secas, pero cuentas_paciente es más descriptivo. Vamos con cuentas y movimientos para mantenerlo simple y evitar cualquier ambigüedad.

🚀 Comencemos con la implementación

Acá comienza a salir material preponderantemente de código. Fin.

Programemos Cosas