Hola, hace un tiempo realicé una aplicación para la administración de
un jardín de infantes. Como era para la facultad me hice el favor de
esquivar cosas que no sabía bien como hacer. Ahora quiero crearla de 0
ya que le voy a dar uso en un tiempo no muy lejano.

Lo primero que me propuse hacer es la relación de cada alumno con sus
cuotas, pero se me complicó a la hora de definir los campos de cada
tabla. Algunas características de las cuotas:

- A ciertos alumnos se les puede hacer una "atención" por lo que pasan
a tener una cuota especial.
- El monto de la cuota puede cambiar en el transcurso del año.
- La cuota se puede pagar un poco un día otro poco otro, por lo que no
le veo sentido a que cada cuota tenga un campo "fecha de pago".
- Se pagan por adelantado del 1 al 10 del mes en curso.
- Computación, taller, comedor se agregan al monto del valor de la
cuota base y son opcionales.

Por lo tanto, el campo monto de c/ Cuota depende de los campos de
Alumno. Si existe una cuota especial todo lo demás no importa, en otro
caso se hace la suma de valores.

Mis dudas al respecto son las siguientes:

-Como las cuotas se pueden pagar en diferentes días, para registrar
cada pago: ¿estaría bien crear otra tabla Pago, o hay algo que no
estoy viendo?
-Como yo lo pensé, los registros de las cuotas se deberían llenar
previamente al pago. De esta forma cuando un pago es realizado se
descuenta de la cuota determinada.
-No tengo bien en claro como llevar a cabo el punto anterior, cuando
crear las cuotas de cada mes.

Me parece que estoy haciendo difícil algo que debe ser fácil de
resolver pero la verdad que no se me ocurrió otra forma de hacerlo.

Si alguien quiere ver como es mi models.py por el momento les dejo el
link: http://pastebin.com/m5d9a0e8b.

Muchas gracias por su ayuda.

Yo quitaría los datos de las cuotas de los alumnos. Los modelos quedarían
así

(camel case para las variables y demás):

class Alumno(models.model):

#quitaria lo que está en los modelos actuales y, opcionalmente, pondría

descuentoPorDefecto #porcentaje o bonificacion por defecto que va a tener
ese

alumno.

class Actividades(models.model): #Una clase donde registrar las actividades

que se van a poder facturar

descripcion #Descripcion más o menos larga de la actividad: Computación,

comedor, etc.

importe #El importe a cobrar por esa actividad

fechaVigenciaDesde #Este campos sería opcional, por si queremos tener un

histórico de vigencias

fechaVigenciaHasta #Vinculado al anterior. Si está a nulo, el registro está

vigente

class Recibo(models.model): #El recibo mensual de cada alumno.

fechaRecibo #mes del recibo

alumno #el alumno al que le estamos generando el recibo.

Sería intersante que el recibo tuviese algunas propiedades como:

importeTotal

importePagado

class Conceptos(models.model): #Relaciona el recibo anterior con las

actividades

recibo

actividad

descuento #Porcentaje de descuento para esa actvidad. Se podría poner una
por

defecto en la tabla del alumno, que se volcaría aquí.

class Pagos(models.model):

recibo

importeCobrado

fechaCobro

El 20 de enero de 2010 03:13, mf <mf2...@gmail.com> escribió:

2010/1/19 mf <mf2...@gmail.com>:

Hola ¿mf?

Voy detallando algunas cosas y al final estaría mi propuesta de models.py.

Cabe aclarar que no sería la aplicación completa, habría que continuar
el trabajo de diseño.

Esto estaría resuelto con las "Listas de precio".

Esto estaría resuelto con las "Listas de precio".

Esto estaría resuelto con los "Comprobantes".

Se generaría un comprobante tipo "Recibo".

Cada cliente puede tener uno o más abonos asociados.

Los precios por lista de precio te podría solucionar esto.

Yo pondría, tal cual está en mi versión del models.py todo en una
misma tabla (Facturas y recibos). Luego a sacar cuenta para saber
saldos.

Habría que crea un proceso que automatice la creación de facturas
(Comprobantes tipo factura) basándose en los abonos que cada cliente
tiene "Activo".

De nada, espero que sirva el aporte.

Adjunto un ejemplo de models.py (http://pastebin.com/f75ae270d) que no
está probado (puede contener errores).

# Ejemplos de listas de precio:
# * "Efectivo"
# * "Tarjeta de crédito"
# * "Tarjeta de débito"
# * "Atención por familia"
# * "Promoción Sumate Ya!"
class ListaPrecio(models.Model):
    descripcion = models.CharField("Descripción", max_length=50)

    def __unicode__(self):
        return self.descripcion

    class Meta:
        verbose_name = "Lista de precio"
        verbose_name_plural = "Listas de precio"

# Ejemplos de productos:
# * "Abono escolar"
# * "Computación"
# * "Taller"
# * "Comedor"
class Producto(models.Model):
    descripcion = models.CharField(max_length=50)

    def __unicode__(self):
        return self.descripcion

# Ejemplos de clientes:
# * "José Luis", "Efectivo"
# * "Natalia", "Atención por familia"
# * "Leslie", "Efectivo"
# * "Agustina", "Atención por familia"
# * "Valentina", "Promoción Sumate Ya!"
class Cliente(models.Model):
    # Datos generales
    ...

    # Esta seria la lista de precios a aplicar a un cliente en particular.
    # En el caso de los clientes con "Promociones" ciertos productos
podrían tener importe 0 (bonificados)
    lista_precio = ForeignKey(ListaPrecio)

# Ejemplos de abonos:
# * "José Luis", "Abono escolar", 2010-03-01, 2010-11-30
# * "José Luis", "Comedor", 2010-07-01, 2010-11-30
# * "Valentina", "Abono escolar", 2010-03-01, 2010-11-30
# * "Valentina", "Comedor", 2010-03-01, 2010-11-30
# * "Valentina", "Computación", 2010-03-01, 2010-11-30
class Abono(models.Model):
    cliente = ForeignKey(Cliente)
    producto = ForeignKey(Producto)
    vigencia_desde = models.DateField()
    vigencia_hasta = models.DateField()

# Ejemplo de precios:
# * "Efectivo", "Abono escolar", 2010-01-01, 120.00
# * "Efectivo", "Comedor", 2010-01-01, 35.00
# * "Efectivo", "Computación", 2010-01-01, 50.00
# Nótese que en la promoción siguiente el Abono escolar es un poco más
alto, pero incluye Comedor y Computación (están con importe en cero).
# * "Promoción Sumate Ya!", "Abono escolar", 2010-01-01, 150.00
# * "Promoción Sumate Ya!", "Comedor", 2010-01-01, 0.00
# * "Promoción Sumate Ya!", "Computación", 2010-01-01, 0.00
class Precio(models.Model):
    lista_precio = ForeignKey(ListaPrecio)
    producto = ForeignKey(Producto)
    vigencia = models.DateField()
    importe = models.DecimalField(max_digits=10, decimal_places=2)

# Esta tabla posiblemente no habría que editarla, si no entregarla
como parte de la aplicación ya cargada.
# Habría que confirmar con alguien que tenga conocimientos contables
mejores que los míos para corroborar si el DEB/CRED de cada tipo de
comprobante está bien especificado.
# Ejemplo de tipos de comprobantes:
# * "F", "Factura", "D"
# * "R", "Recibo", "C"
# * "D", "Nota de débito", "D"
# * "C", "Nota de crédito", "C"
class ComprobanteTipo(models.Model):
    DEBCRED_CHOICES = (
        ('D', 'Débito'),
        ('C', 'Crédito'),
    )

    id = models.CharField(max_length=1, primary_key=True)
    descripcion = models.CharField(max_length=50)
    debito_credito = models.CharField(max_length=1, choices=DEBCRED_CHOICES)

    def __unicode__(self):
        return self.descripcion

    class Meta:
        verbose_name = "Tipo de comprobante"
        verbose_name_plural = "Tipos de comprobante"

# Ejemplo de comprobantes:
# * "Factura", "C", 0, 1, 2010-03-01, "José Luis", 120.00, 2010-03-10
# * "Factura", "C", 0, 2, 2010-03-01, "Valentina", 150.00, 2010-03-10
# * "Recibo", "X", 0, 1, 2010-03-05, "Valentina", 150.00, Null
class Comprobante(models.Model):
    LETRA_CHOICES = (
        ('A', 'A'),
        ('B', 'B'),
        ('C', 'C'),
        ('X', 'X'),
    )

    tipo = ForeignKey(ComprobanteTipo)
    letra = models.CharField(max_length=1, choices=LETRA_CHOICES)
    sucursal = models.PositiveIntegerField()
    numero = models.PositiveIntegerField()
    fecha = models.DateField()
    cliente = ForeignKey(Cliente)
    importe = models.DecimalField(max_digits=10, decimal_places=2)
    vencimiento = models.DateField(null=True, blank=True)

    def __unicode__(self):
        return "%s-%s-%i-%i" % (self.tipo, self.letra, self.sucursal,
self.numero)

# Ejemplo de líneas de comprobantes:
# * "Factura-C-0-1", "Abono escolar"    # "Factura-C-0-1" -> tipo
"Factura", letra C, sucursal 0, numero 1
# * "Factura-C-0-2", "Abono escolar"
# * "Factura-C-0-2", "Comedor"
# * "Factura-C-0-2", "Computación"
class ComprobanteLinea(models.Model):
    comprobante = ForeignKey(Comprobante)
    producto = ForeignKey(Producto)

    class Meta:
        verbose_name = "Línea de comprobante"
        verbose_name_plural = "Líneas de comprobante"

--
---
José Luis DALLAPICCOLA
Neuquén Capital
Patagonia Argentina

mf

Alguna novedad sobre el problema?
Lo pudiste resolver?

En caso afirmativo: Querés compartir cómo lo implementaste?

Saludos.

--
---
José Luis DALLAPICCOLA
Neuquén Capital
Patagonia Argentina

Que tal José Luis. Primero agradecerles tanto a vos como a Db Pp por
la ayuda brindada. Estuve con otros compromisos y recién mañana voy a
poder dedicarle tiempo al proyecto. En cuanto tenga novedades por
supuesto las voy a postear.

Saluda atentamente,
Mariano.

On 30 ene, 18:19, Jose Luis Dallapiccola <jlda...@gmail.com> wrote:

No seria mas chevere que se presenten estos tipos de preguntas de
desarrollo, en modelos UML para entender un poco mejor, con respecto al
desarrollo del software pago de cuotas?
_________
@jonathanorlando
Linux user # 458151
Geek Emprendedor !!
Cucuta / Norte de Santander / Colombia

El 30 de enero de 2010 16:19, Jose Luis Dallapiccola
<jlda...@gmail.com>escribió:

2010/1/30 Jonathan Orlando <solosekenad...@gmail.com>:

Para el que sabe UML puede ser que sí. :-P

Saludos,

--
---
José Luis DALLAPICCOLA
Neuquén Capital
Patagonia Argentina

Actualizo los modelos que se me ocurrieron: http://pastebin.com/mfa3e2fb.
Lo que no se como hacer es determinar es en la tabla Servicio, el
valor default del importe ya que este depende de que tipo de servicio
se elija.

Espero sus opiniones sobre el modelo.
Muchas gracias,
Mariano.

Si necesitas tener un tipo de servicio, en mi opinión, deberías incluirlo en
una tabla de la base de datos, ya que si se necesita incluir un nuevo tipo
de servicio basta con añadirlo a la base de datos y no hay que tocar el
código de la aplicación. La tabla también podría tener un importe que sería
el que se grabaría por defecto, sobrecargando el método save de la clase
Servicio.

El valor por defecto puede estar asociado en una lista y se cogería a la
hora de grabar.

El 6 de febrero de 2010 00:06, mf <mf2...@gmail.com> escribió:

Hola mf

2010/2/5 mf <mf2...@gmail.com>:

La "tabla" TIPO_CHOICES tiene como clave un texto de solamente un carácter.
Pero... cuando hacés referencia a tipo en la clase Servicio lo definís
como CharField de 35.
Deberías convertir TIPO_CHOICES a una clase (tabla).

Saludos.

--
---
José Luis DALLAPICCOLA
Neuquén Capital
Patagonia Argentina

Ustedes dirían algo así?:http://pastebin.com/m49f65120 . Tendría que
ver bien el método Save para que funcione, lo puse a modo de muestra.

Muchas gracias por sus aportes, me son de mucha utilidad.

Ya está solucionado el problema, el método save() quedaria asi:

class ServicioSuscripto(models.Model):
        alumno = models.ForeignKey(Alumno)
        tipo = models.ForeignKey('TipoServicio')
        importe = models.DecimalField(max_digits=10, decimal_places=2,
blank=True)

        def save(self, **kwargs):
                if not self.importe:
                        self.importe = int(self.tipo.importe)
                super(ServicioSuscripto, self).save(**kwargs)

Sigo trabajando en el proyecto, si a alguien le interesa verlo o
participar visiten:

http://bitbucket.org/mf/alumnos/

Saludos!