[Php-avanzado] Para Leo: SRS Diego Gimenez

Diego Gimenez diegomartin.gimenez en gmail.com
Mie Dic 9 13:46:25 ARST 2009


Hola Leo, buen día.

Te adjunto la SRS con las correcciones y te comento algunas cosas debajo las
observaciones que me habías hecho.


> >         > Req03. El sistema debe gestionar Categorías.
> >         > Req03.1. Atributos de las Categorías:
> >         > Descripción
> >         > Categoría Padre
> >
> >
> >                Ok.
> >                Según esto las Categorías van a estar anidadas o, dicho
> >         de otra manera,
> >         son un árbol... pero no queda claro para 8 ni para el sistema
> >         en general
> >         qué significa esto.
> >
> > Lo imaginaba principalmente para dar la opción de que los gastos
> > puedan ser agruparlos dentro de categorias más específicas.
> >
> > Por Ejemplo:
> > AUTO
> >     Combustible
> >     Seguro
> >     Patente
> >     Mantenimiento
> >
> > Para el caso de punto 8, si el Jefe de Familia hiciera un presupuesto
> > para la categoría Combustible tendría en cuenta los gastos realizados
> > en esa categoría únicamente pero, si hiciera un presupuesto de la
> > categoría Auto, tendría en cuenta los gastos en todas sus categorías
> > hijas.
>
>         Se entiende muy bien, pero me deja una pregunta: por qué vas a
> trabajar
> en un árbol para los Presupuestos, si podrías trabajar en un árbol para
> el Plan de Cuentas, pero no lo hacés ahí, que es dónde se esperaría
> verlo??
>        Esta duda no es sobre este punto de la especificación, sino sobre lo
> que querés que haga el sistema, de lo cual opino constructivamente pero
> de esto no hay ni "bien" ni "mal", así que hacé lo que quieras.
>
>        La cuestión es que creo, IMHO. que si los ingresos y egresos tienen
> la
> forma de un plan de cuentas, se puede crear perfectamente la estructura
> Auto, que tiene adentro Combustible, Seguro, Patente, etc, y si le pido
> al sistema el "saldo" de la cuenta no imputable "Auto" en un rango de
> fechas, obtengo el mismo resultado que el que proponés con la Categoría,
> pero sin tener que escribirla!
>
>        Otra cosa es que me digas, con el mismo ejemplo anterior, que querés
> un
> resumen de "Seguros" que son un concepto dentro de muchas cosas como
> "Auto", "Casa", "Familia" y querés un informe transversal.
>        En este caso, si las imputaciones son a un Plan de Cuentas con forma
> de
> árbol, las Categorías pueden ser una lista plana y funciona
> perfectamente.
>
>        En resumen: si te vas a meter en la complejidad de mantener algo con
> forma de árbol, creo que vale más la pena que ese algo sea el Plan de
> Cuentas y no otra cosa.
>        De todas formas, para la interfaz de usuario, este elegirá de una
> combo
> dónde aparecerán todas las cuentas imputables, así que se verá como una
> lista plana aunque no lo sea!!!
>
>
Cambié la definición de "Cuentas" a "Cajas" para ver si ahí queda mas claro
lo quiero hacer con el sistema.
Como yo lo estoy pensando, "Seguro" o "Auto" son las categorias, o los
conceptos, a los cuales se hace referencia cuando se realiza un gasto y, por
ejemplo, "Sueldo" sería un concepto de un ingreso.


>
> >         > Req04. El sistema debe gestionar Transacciones en las
> >         cuentas de los
> >         > Jefes de Familia.
> >         >
> >         > Req04.1. Atributos de las Transacciones:
> >         >
> >         > Monto
> >         > Descripcion
> >         > Categoría
> >         > Cuenta
> >
> >
> >                Ok.
> >                Esto significa que una transacción dada en una Cuenta
> >         dada puede
> >         pertenecer a una Categoría, pero que otra Transacción igual en
> >         la misma
> >         Cuenta puede pertenecer a otra Categoría???
> >
> >
> > Si, pensaba dejarlo como una responsabilidad de quien realiza el
> > ingreso de los datos, pero se aceptan sugerencias... :)
>
>         Yo haría que la Categoría sea un atributo de la Cuenta y de ahí en
> más
> toda transacción a esa cuenta ya tiene su categoría definida.
>        Cargar este dato cada vez me da la sensación de fastidio en el uso.
> Este fastidio puede achicarse si mostrás preseleccionada la Categoría de
> la Cuenta en la Transacción, entonces si no todo nada, ya hace algo y no
> me obliga a pensarlo cada vez...
>
>
De acuerdo a lo que te puse en el punto anterior, creo que tengo que
continuar dejándolo como una responsabilidad de quien realice el ingreso de
los datos.


>
> >         > Req07. El sistema debe permitir realizar Transferencias
> >         entre cuentas.
> >
> >
> >                ... salvo que esto sea la solución para el problema
> >         anterior.
> >
> >
> > La idea seria que si el Jefe de Familia no crea ninguna cuenta, todos
> > los datos se cargan en una cuenta que el sistema tiene dada de alta
> > por defecto.
> > En este caso esta cuenta tendría tanto los ingresos como los egresos.
> > Si el Jefe de Familia diera de alta cuentas adicionales, debería
> > transferir, desde la cuenta donde se generan sus ingresos, los fondos
> > para cubrir las cuentas donde se generan sus gastos.
>
>         Ahh...
>        Yo había pensado que, por ejemplo, a principio de mes registro un
> ingreso en "sueldo" y de ahí uso ese valor para transferirlo a "seguro"
> el día que lo pago.
>        Esto implica que el sistema registre un egreso en "sueldo", porque
> si
> no registrás ingresos y egresos en las Cuentas, los saldos no dicen
> nada: el "sueldo" da cada vez más positivo y el "seguro" da cada vez más
> negativo.
>
>        Esto me lleva a otra cosa que me desconcierta un poco. En la
> Transacción, hay un "monto", en lugar para ingresar si es un ingreso o
> egreso. Esto implica que el usuario va a tener que cargar los egresos
> como negativos...
>
>
En cuanto a cargar los egresos como valores negativos voy a tratar de
manejarlo, lo mejor que pueda, desde la interfaz.

Gracias, Saludos.
Diego
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://www3.fi.mdp.edu.ar/cgi-bin/mailman/private/php-avanzado/attachments/20091209/73373056/attachment-0001.htm 
------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre     : Curso_PHP_Avanzado-SRS.odt
Tipo       : application/vnd.oasis.opendocument.text
Tamaño     : 18613 bytes
Descripción: no disponible
Url        : http://www3.fi.mdp.edu.ar/cgi-bin/mailman/private/php-avanzado/attachments/20091209/73373056/attachment-0001.odt 


Más información sobre la lista de distribución Php-avanzado