|
Me tope con dos casos similares. En uno (gimnasio, colegio y
academias) se creaba varios registros relacionados al usuario/alumno en
base a una fecha de inicio y fin. En caso de un año de servicio, se
creaba 12 registros. Cada registro tenia fecha vencimiento, debe, haber,
saldo, descripcion/concepto. El otro modelo (condominios,
alquiler, renta) se generaba el registro para cada inmueble
mensualmente, en base a los gastos del periodo, con una estructura casi
identica a la anterior.
Para generar un reporte de cuentas por cobrar, una consulta que filtre los registros con saldo>0 con fecha igual o mayor a X. Para realizar pagos, se levantaba un formulario con los registros saldos>0. Se guardaba en una tabla de pagos los datos del mismo y en otra tabla, los conceptos asociados al pago.
Tu
tema me ha puesto a pensar y Hoy dia lo haria de una manera un tanto
distinta, utilizando la misma tabla inicial (como referencia la llamare Mayor), agregando un par de campos mas y descartando la tabla donde
introducia los conceptos afectados en el pago.
Estructura: Agregar una columna parentId, que tendra por defecto valor=0 para identificar los registros padres. Los registros padres solo deben tener valor en la columna Debe y cero en Haber. Agregar una columna pagoId para relacionar con la tabla de Pagos (un registro en Pagos puede tener varios registros en Mayor)
Cada vez que se realize un pago(se inserta en Mayor un registro Hijo), bien sea total o parcial, se introduce el registro colocando en esta columna el identificador (id) del concepto afectado(padre), colocando el monto en la columna Haber de manera de obtener el Saldo sumarizando la columna Haber de los Hijos y evitando tener campos calculados(Saldo). En la columna PagoId se debe introducir el indice generado en Pagos.
La relacion de Mayor es de union entre Clientes y Pagos. Un cliente puede terner varios registros en Mayor y un registro en Pagos tambien.
Para esta estructura sera necesario utilizar alguna funcion con recursividad para calcular saldos, reportes. Tambien debes contemplar casos como pagos anticipados que generan saldo a favor del Cliente, y en la medida que agregas nuevos cargos/conceptos(Hijos) relacionarlos con estos para ir rebajandolos (rayos!).
Un proceso para anular pagos, cargos por error, cheque rechazado. Los principios contables rezan que no se puede modificar, sino agregar contrapartidas. Este tema debes estudiarlo bien y documentarte al respecto para evitar tener que emparchar tu aplicacion lo menos posible. Atte Carlos
|