Ante todo, gracias a los dos por interesarse y responder.
Tendrias que, por lo menos, esplayar mas tu modelo o logica de datos. Pero si lo que queres es ir guardando un registro de cuotas mensuales podrias crear un tabla para las mismas. Usar un campo para el id de cliente, otro para el importe , otra para el mes, otro apra el año, y otro para el estado (pagado o impago). Yo use esta solucion. Lo bueno de este sistema es que por ejemplo todos los 1ro de mes as las 00:01AM podes correr un script (por medio de CRON) agregando a la tabla 'cuotas' los registros para cada cliente, correspondiente al mes que acaba de empezar. Y luego cuando registras un pago lo que en realidad haces es un UPDATE 'seteando' el estado de 'impago' (o false, o lo que sea xD) a pagado.
Otra cosa util de este sistema es que dia a dia te permite ir corriendo por emdio de CRON un script que calcule el interes (en caso de que apliques por demora de pago)
Espero que hayas entendido, sino te lo grafico mejor con imagenes y codigo
Saludos
Algo asi es lo que tenia en mente. Además es lo que tengo hecho ahora mismo, pero sin el campo del año y sin la solucion de correr un CRON. No lo mencione en mi primer post porque creia que era un poco de "cazurro" y creia que la gente usaria un campo DATE o similar aunque el dato del dia fuera innecesario.
Vamos lo que yo tengo ahora es un campo que pone el mes, y cuando alguien viene a pagarme, le sumo las cuotas que me pagan a ese campo de la db desde el movil con una pequeña aplicación. El problema es que esa solución se romperia cuando alguien trate de pagar mas meses de lo que comprende este año (valor 12 del campo mes) porque pasaria a poner 13, 14...
Pero como ya veo que es lo mas lógico, añadiré como dices otro campo para el año y con PHP mediante condicionales aré que se sume solo el campo del mes o del año también dependiendo del caso.
Lo dicho, gracias a los dos, y en especial a unsigned, que en tantas veces me ha ayudado en este foro, espero algún dia poderle devolver el favor
Autor
En línea
