[Php-avanzado] Requerimientos

Vie Oct 28 10:59:19 ART 2011

Hola Hernán,

El mié, 26-10-2011 a las 22:21 -0300, Hernàn Flecchia escribió:
> Hola Leo, gracias por la pronta respuesta, voy respondiendo a cada
> inquietud asi me queda como referencia a mi tambien

	Perfecto!

> > - como los Tipos de IVA [2] con fijos, podrías ahorrarte el ABM
> > especificando que "el sistema debe mostrar..." en vez de "el sistema
> > debe gestionar...". Se entiende la idea perfectamente, pero el nombre
> > correcto es "Categoría Impositiva".
> 
> Ok, le cambio el nombre. Con respecto al ABM, solo debería realizar altas
> por si en algún momento el gobierno decide agregar alguna categoría nueva ?

	Generalmente no, porque las Categorías Impositivas determinan qué parte
del código se usa (por ej, poner el precio IVA incluido o discriminarlo)
por lo que agregarlas sin relacionarlas con los algoritmos no tiene
sentido.

> > - por qué los RF5, 6, 7 y 9 tiene un atributo "activo"? Para qué
> > serviría?
> 
> La idea del atributo "activo" es para marcar en cada caso si el determinado RF
> ya no se utiliza por alguna razón y no puede ser eliminado porque se
> uso en algún
> momento.

	Si el almacenamiento está bien normalizado, las cosas se pueden borrar
sin afectar negativamente a otras cosas...
	(como vimos en las dos últimas clases)

> > - para ayudarme por mi desconocimiento de los detalles del tema, podrías
> > agregar dos o tres ejemplos de Tamaños de Productos?
> 
> Bien, un producto puede ser "Encore" de Tipo "Mandarina" con Tamaño
> "08" y Presentación
> "Cajon", otro producto puede ser "Encore" de Tipo "Mandarina" con
> Tamaño "09" y Presentación
> "Cajon", y otro "Encore" de Tipo "Mandarina" con Tamaño "10" y Presentación
> "Bandeja".

	Gracias!
	Por el tipo de dato, está correcto que sea una entidad aparte y no un
mero dato, tal y como especificaste.

> > - Los Items de Factura no hace falta que se especifiquen como un RF
> > aparte de la Factura. Creo que lo pusiste porque están pensando en las
> > tablas, que tendrán una forma parecida, pero esto se desprenderá de la
> > normalización. Sí es pertinente poner los Items como parte del
> > diccionario de la Factura.
> 
> Debajo pego el SRS corregido, así estaría correcto?

	Es correcto. Incluso podés sacar "items" del RF: una factura (de hecho
cualquier comprobante) es un bloque indivisible, y separarlo es una
cuestión de implementación, por lo que no se verá en la SRS.

	La SRS define qué se va a hacer, pero nunca cómo se va a hacer.

	La definición de cómo se va a hacer es el diseño del software, y el
diseño no puede ser validado por el cliente, pero la SRS es
indispensable que el cliente la valide.

> > - Suena raro (e ilegal) que se permitan modificar los datos de las
> > Facturas. A qué datos te referís? Porque si es solo anularlas, esto lo
> > estás poniendo perfectamente en el RF14. Lo mismo para los Romaneos.
> 
> En la introducción comento que las facturas no son generadas por el sistema
> sino que los datos de las mismas son cargados de las de papel
> generadas a mano, la
> idea es poder modificar los items en caso que se compruebe que se
> copio alguno mal,
> por algún error de tipeo o similar sin tener que anularlas y volver a
> ingresar todos los
> datos nuevamente .

	Te entiendo, pero esto genera un problema, que es independiente de si
la factura la genera el sistema o si se carga una factura generada de
otra manera.
	El problema es que del registro de las facturas, dependen los informes
de ventas e incluso las deudas. Por lo tanto, si cargo 3 facturas de
venta de $200.00 en un mes, el software debería decir que se vendieron
$600.00.
	Ahora, si tu software permite la edición, se podría por ejemplo
modificar estas facturas a $150.00 cada una, emitir el informe, que
ahora dará $450.00, luego volverlas a editar a $200.00 cada una, con lo
que tenés varias consecuencias indeseables:
1) el informe no conicide con las facturas cargadas, y te van a decir
que anda mal.
2) salvo que se miren las facturas una a una, no hay como detectar el
faltante de dinero.
3) hay un escenario peor, que es aumentar el importe de las facturas,
emitir un listado, cobrarle al cliente, y luego volver a ponerles el
importe original: todas las cuentas y la inspección manual dan bien,
pero tu sistema permitió cobrar de más y que no quede rastro de este
"error".

	A su vez, la situación que planteás de cargar mal un item no es tan
frecuente, porque mientras no se guarde, toda la factura será
modificable, con lo que un error de tipeo se soluciona en el momento.

	Si decidís implementar que las facturas se editen, vas a tener que
agregar 3 o 4 funcionalidades para controlar, o loguear, o restringir la
edición después de hecho algo...

> > - Las Liquidaciones se pueden registrar y luego editar o borrar? Suena
> > raro...
> 
> Tenes razón, en caso de error se deberían poder anular y realizar
> nuevamente pero no modificar.

	Yo ya ando necesitando un ejemplo de cómo es una liquidación, para ir
entrando en detalles... especificar la liquidación impresa o la pantalla
de liquidaciones sería bueno (como un apéndice de la SRS funcional)

> > - En la intro mencionás las Ctas Ctes de los Clientes, pero no las veo
> > especificadas... es posible que te falta además especificar la forma de
> > pago de las facturas [11].
> 
> Ambas cosas las llevo especificadas para mañana... si llego!!

	Mandame una versión nueva con los cambios y estas cosas agregadas, así
vemos de dar por finalizada esta etapa.

	Seguimos!

PD: acordate de que los activos no van acá seguro (es un detalle de
implementación) y que en la implementación no tienen sentido técnico...
habría que ver cada RF si se justifica o no por su funcionalidad.

> ------------------------------------------------------------------------
> 
> Gestión de Puesto de Frutas y Verduras en Mercado Procosud.
> 
> Introducción.
> 
> 	El puesto de frutas y hortalizas en cuestión, opera en el mercado
> frutihorticola Procosud S.A. sito en Ruta 226 Km. 7,5 de la ciudad de
> Mar del Plata. Realiza las operaciones de consignación,  compra y
> venta de productos frutihorticolas en soporte papel, por el momento no
> desea informatizar esa tarea pero si esperan poder volcar los datos
> registrados en los papeles a un sistema informatizado que le permita
> conocer en forma diaria, semanal, mensual y anual, cierta información
> de su operatoria,  la que a continuación se detalla.
> 
> Se quiere:
> Registrar las compras y las consignaciones de frutas y hortalizas.
> Registrar las ventas de las mismas consignaciones.
> Conocer el promedio de precios de ventas.
> Conocer cantidad de productos comprados, en total y por proveedor.
> Conocer cantidad de productos vendidos, en total y por cliente.
> Conocer la existencia de cada producto diariamente.
> Llevar el control de cajones vacíos afectados a la compra y venta de
> los productos.
> Realizar las liquidaciones de las consignaciones.
> Llevar el control del pago de las liquidaciones.
> Registrar Cta. Cte de cada cliente.
> 
> Requisitos funcionales.
> 
> 1. El sistema debe gestionar Localidades.
> 2. El sistema debe mostrar Categorías Impositivas.
> 3. El sistema debe gestionar Clientes con su Localidad [1] y su
> Categoría Impositiva [2].
> 4. El sistema debe gestionar Proveedores con su Localidad [1] y su
> Categoría Impositiva [2].
> 5. El sistema debe gestionar Tipos de Productos.
> 6. El sistema debe gestionar Presentación de Productos.
> 7. El sistema debe gestionar Tamaños de Productos.
> 8. El sistema debe gestionar Productos con su Tipo [5], Presentación
> [6] y Tamaño [7].
> 9. El sistema debe gestionar Tipo de Facturas.
> 10. El sistema debe registrar Facturas con su Tipo [9], Cliente [3] e Items.
> 11. El sistema debe registrar Romaneos con su Proveedor [4] e Items.
> 12. El sistema debe anular Facturas [10].
> 13. El sistema debe modificar Items de Facturas [10].
> 14. El sistema debe anular Romaneos [11].
> 15. El sistema debe modificar Items de Romaneos [11].
> 16. El sistema debe realizar consultas de las Facturas [10] por
> Cliente [3] en un rango de fechas.
> 17. El sistema debe realizar consultas de los Romaneos [11] por
> Proveedor [4] en un rango de fechas.
> 18. El sistema debe realizar consultas de la existencia diaria de los
> Productos [8]
> 18.1. Por  un Tipo de producto [5] o todos.
> 18.2. Por  un Producto [8] o todos.
> 19. El sistema debe realizar consultas de las ventas de Productos [8]
> en un rango de fechas.
> 19.1. Por  un Cliente [3] o todos.
> 19.2. Por  un Tipo de producto [5] o todos.
> 19.3. Por  un Producto [8] o todos.
> 20. El sistema debe realizar consultas de las compras de Productos [8]
> en un rango de fechas.
> 20.1. Por  un Proveedor [4] o todos.
> 20.2. Por  un Tipo de producto [5] o todos.
> 20.3. Por  un Producto [8] o todos.
> 21. El sistema debe calcular el promedio de precio de venta de un
> Producto [8] en un rango de fechas.
> 22. El sistema debe registrar Liquidaciones de los Romaneos [11].
> 23. El sistema debe registrar el pago de las Liquidaciones [22].
> 24. El sistema debe anular Liquidaciones [22].
> 25. El sistema debe registrar el pago de las Facturas [10].
> 26. El sistema debe contemplar el pago parcial de las Facturas [10].
> 
> Diccionario.
> 
> (1) Localidades: descripción, activo.
> 
> (2) Categoría Impositiva: descripción, activo.
> 
> (3) Clientes: nombre, apellido, razón social, dni, domicilio,
> teléfono, localidad, tipo de iva, cuit, activo.
> 
> (4) Proveedores: nombre, apellido, razón social, dni, domicilio,
> teléfono, localidad, tipo de iva, cuit, activo.
> 
> (5) Tipos de productos: descripción, activo.
> 
> (6) Presentación de productos: descripción, activo.
> 
> (7) Tamaños de productos: descripción, activo.
> 
> (8) Productos: descripción, presentación, tamaño, cantidad, tipo de
> producto, activo.
> 
> (9) Tipos de facturas: descripción, activo.
> 
> (10)  Factura: número, tipo de factura, total, fecha, cliente.
>      10.1 Items: cantidad, precio, factura, producto.
> 
> (11)  Romaneo: número, total, fecha, proveedor, valor del flete.
>      11.1 Items: cantidad, precio, romaneo, producto, promedio.
> 
> (22) Liquidación: número, total, comisión, fecha, romaneo.
> _______________________________________________
> Php-avanzado mailing list
> Php-avanzado en pato2.fi.mdp.edu.ar
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
> 

-- 
Leonardo Tadei
leonardot en pegasusnet.com.ar
Blog: http://blog.pegasusnet.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key