[Php-avanzado] Normalizacion

Mie Mayo 9 20:38:06 ART 2012

Hola Sergio,

El jue, 26-04-2012 a las 10:47 -0300, Sergio Marquez escribió:
> Buenas!
> SRS, Diccionario de datos y normalizacion corregios y aumentados!
> Una novedad: pase todo a HTML5, tiene cosas muy buenas, sobre todo el
> DOCTYPE jeje.

	Tal y como decís, HTML5 tiene cosas muy buenas.
	Independientemente del DTD que uses, acordate de que es importante
generar HTML válido.

> -----------------------------------------------------------------------
> 
> Requerimientos Empresariales:
>  
>  El sistema debe gestionar los movimientos comerciales de una
> veterinaria.
> 
> Requerimientos Funcionales:
> 
> 1. El sistema debe mostrar provincias argentinas.
> 
> 2. El sistema debe gestionar localidades con sus provincias.
> 
> 3. El sistema debe gestionar direcciones con sus localidades.

	En el diccionario de las Localidades, indicás que tienen
Cliente/Proveedor, lo cual no se corresponde con esto.
	Si tu planteo es una agenda que soporte múltiples direcciones, lo que
tenés que especificar es que un Cliente tiene Direcciones y que un
Proveedor también tiene Direcciones, pero no al revés como hacés acá.

> 4. El sistema debe mostrar tipos de telefono.
> 
> 5. El sistema debe gestionar telefonos con sus tipos.

	Idem que para las Direcciones.

> 6. El sistema debe mostrar las Condiciones de Responsable IVA.

	Para todo lo que especifiques como "mostrar", tenés que enumerar en el
diccionario todas las opciones que se verán.

> 7. El sistema debe gestionar los tasas de IVA de artículos.
> 
> 8. El sistema debe gestionar categorías de artículos.
> 
> 9. El sistema debe gestionar artículos con su categoría y tasa de IVA.
> 
> 10. El sistema debe gestionar clientes con su provincia, localidad y
> su tipo de responsable IVA.
>     10.1 El sistema debe gestionar tantos telefonos de cliente como se
> desee.
>     10.2 El sistema debe gestionar tantas direcciones de cliente como
> se desee.
> 
> 11. El sistema debe gestionar proveedores con sus direcciones,
> telefonos y su tipo de responsable IVA.
>     11.1 El sistema debe gestionar tantos telefonos de cliente como se
> desee.
>     11.2 El sistema debe gestionar tantas direcciones de cliente como
> se desee.
> 
> 12. El sistema debe asentar facturas de compra compra con su proveedor
> y artículos comprados.
>     12.1 El sistema debe permitir marcar la factura como paga o no
> paga.
>     12.2 El sistema debe modificar stock de artículos luego de la
> compra realizada.
>     12.3 El sistema debe asentar la deuda con el proveedor mientras
> las facturas de compra no se hayan pagado.
> 
> 13. El sistema debe asentar facturas de venta con su cliente y
> artículos comprados.
>    13.1 El sistema debe permitir marcar la factura como paga o no
> paga.
>    13.2 El sistema debe modificar stock de artículos luego de la venta
> realizada.
>    13.3 El sistema debe asentar la deuda del cliente mientras las
> facturas de compra no se hayan.

	En el diccionario de las Facturas de Compras y de Ventas mencionás
"Tipo IVA", pero si no entiendo mal esto es lo que más arriba
especificás como "Condiciones de Responsable IVA".

	Si es la misma cosa, llamalas de la misma manera. Si son cosas
distintas, contame qué es el "Tipo IVA" por si es relevante para tu
software.

> 14. El sistema debe presentar un gráfico mostrando el valor total de
> compras diarias en un determinado mes.
> 
> 15. El sistema debe presentar un gráfico mostrando el valor total de
> ventas diarias en un determinado mes.
> 
> Requerimientos no Funcionales
> 
>  1. El ingreso al sistema esta restringido por cuenta de usuario y
> contraseña.
>  2. El sistema debe gestionar usuarios de tipo:
>     2.1 Empleado: tiene acceso a todos los RF y no tiene acceso al RnF
> 2.
>     2.2 Administrador: tiene acceso a todos los RF y RnF.
> 
> ------------------------------------------------------------
> 
> Diccionario de datos
> 
> • Provincias: Nombre .
> • Localidades: Nombre, Codigo Postal, Provincia .
> • Direcciones: Direccion, Localidad, Cliente/Proveedor,
> Establecimiento .  //Establecimiento indica si la direccion perteneces
> a un Establecimiento Agropecuario.
> • Tipos de Telefonos: Nombre .
> • Telefonos:  Numero, Tipo, Cliente/Proveedor .
> • Categorias de Articulo: Nombre, Descripcion .
> • Tasas de IVA para articulos: Descripcion, Tasa .
> • Artículos: Nombre, Descripción, Categoría, Costo Unitario , Precio
> Unitario, Tasa de IVA, Stock .
> • Condiciones de Responsable IVA: Tipo .
> • Clientes: Razon Social, Direcciones, Telefonos, Email, Condicion de
> Responsable IVA, CUIT, Otros .
> • Proveedores: Nombre, Direcciones, Telefonos, Email, Sitio web,
> Condicion de Responsable IVA, CUIT, Otros.
> • Facturas de Venta: Numero, Tipo IVA, Fecha, Cliente, Descripcion,
> Importe Neto, Importe Iva, Pagado, Artículos, Cantidad de cada
> Articulo, Precio Unitario de cada Articulo, Tasa de IVA de cada
> articulo.
> • Facturas de Compra: Numero, Tipo IVA, Fecha, Proveedor, Descripcion,
> Importe Neto, Importe Iva, Importe IIBB, Pagado, Artículos, Cantidad
> de cada Articulo, Precio Unitario de cada Articulo, Tasa de IVA de
> cada articulo.
> • Tipos de Usuario: Nombre.
> • Usuarios: Nombre de Usuario. Nombre, Apellido, Contraseña, Email,
> Tipo, Ultimo Acceso.
> 
> ------------------------------------------------------------

	Sobre los campos: no pongas nada que sea gestionado como tinyint,
porque el usuario lo desborda muy rápido y le acortás inútilmente vida
útil al software. 
	Supongo que habrás pensado que nunca van a haber 128 Tipos de Iva, y
estoy de acuerdo con vos. Lo que pasa es que el que use el software sí
puede definir y borrar más de 128 tipos de IVA, haciendo pruebas,
jugando o lo que sea y con esta definición el almacenamiento fallará
cuando el ID sea 128.
	Ponele al menos int(11) a todo lo que sea gestionado.

> ARTICULOS (
> ID int PK,
> IDTIPOIVA tinyint ,
> NOMBRE varchar(100) ,
> IDCATEGORIA int ,
> COSTO decimal(10,4) ,
> PRECIO decimal(10,4),
> DESCRIPCION TEXT 
> )
> 
> ART_TIPOIVA (
> ID tinyint ,
> TIPOIVA varchar(50),
> TASA float (2,4)
> )
> 
> ARTICULOS_CATEGORIAS (
> ID int PK ,
> CATEGORIA varchar(100) ,
> DESCRIPCION TEXT
> )
> 
> CLIENTES (
> ID int PK ,
> RAZON varchar(100) ,
> IDCONDIVA tinyint ,
> CUIT varchar(50),
> EMAIL varchar(100) ,
> OTROS TEXT
> )
> 
> CLI_DIRECCIONES (
> ID PK ,
> DIRECCION varchar (50) ,
> IDLOCALIDAD int ,
> IDCLIENTE int
> )
> 
> CLI_TELEFONOS (
> ID int PK,
> IDTIPO tinyint,
> NUMERO varchar(50) ,
> IDCLIENTE int(10)
> )
> 
> PROVEEDORES (
> ID int PK ,
> RAZON varchar(100) ,
> EMAIL varchar(100) ,
> WEB varchar(100) ,
> IDCONDIVA smallint ,
> CUIT varchar (50),
> OTROS TEXT
> )
> 
> PRO_DOMICILIOS (
> ID int PK ,
> DIRECCION varchar(50) ,
> IDLOCALIDAD int ,
> IDPROVEEDOR int
> )
> 
> PRO_TELEFONOS (
> ID int PK ,
> IDTIPO tinyint ,
> NUMERO varchar(50) ,
> IDPROVEEDOR int
> )
> 
> FACTURAS_CLI (
> ID int PK ,
> NUMERO varchar(50),
> IDCLIENTE int(10) ,
> RAZON varchar(100) ,
> IDCONDIVA tinyint ,
> CUIT int ,

estás poniendo la CUIT como VARCHAR en el Cliente y el Proveedor, pero
acá aparece como INT... ponela igual en todas las tablas.

> TIPOIVA  char(1) ,

	un CHAR(1) no parece adecuando para guardar el Tipo de Iva.
	Pareciera que estás mezclando los Tipos de IVA con la letra de la
factura.
	Con la condición Impositiva del Proveedor y del Cliente y la de la
empresa que usa el software, podés determinar las letras válidas para
una factura, pero lo importante es no mezclar una cosa con la otra.

> FECHA datetime ,
> DESCRIPCION TEXT ,
> PAGA bool
> )
> 
> FACTURAS_PRO (
> ID int PK ,
> NUMERO varchar(50),,
> IDPROOVEDOR int ,
> RAZON varchar(100) ,
> IDCONDIVA tinyint ,
> CUIT int ,
> TIPOIVA char(1) ,
> FECHA datetime ,
> IVA decimal(10,4) , 
> IIBB decimal(10,4) ,
> NETO  decimal(10,4) ,

	El neto debería ser siempre la suma de los Items, y por tanto se puede
calcular... el IVA y los IIBB están bien acá, porque si te los emiten
mal, tenés que registrar lo que te hayan dado aunque estén mal
calculado.

> DESCRIPCION TEXT ,
> PAGA bool
> )
> 
> FACTURA_CLI_ITEMS (
> ID int PK,
> IDFACTURA int ,
> IDARTICULO int ,
> DESCRIPCION varchar(100) ,
> CANTIDAD int,
> UNITARIO decimal (10,4)
> IVA decimal (10,4),
> )
> 
> FACTURA_PRO_ITEMS (
> ID int PK ,
> IDFACTURA int ,
> IDARTICULO int ,
> DESCRIPCION varchar(100) ,
> CANTIDAD int,
> UNITARIO decimal (10,4)
> IVA decimal (10,4),
> )
> 
> LOCALIDADES (
> ID int PK ,
> NOMBRE varchar(50) ,
> CP int(4) ,
> IDPROVINCIA int
> )
> 
> PROVINCIAS (
> ID int PK ,
> NOMBRE varchar(50)
> )
> 
> CONDIVA (
> ID int PK ,
> CONDICION varchar(50)
> )
> 
> TELEFONO_TIPOS (
> ID tinyint ,
> TIPO varchar(50) ,
> )
> 
> USUARIO_TIPOS (
> ID int PK ,
> USUARIO varchar(50) ,
> PASSWORD varchar(100) ,
> NOMBRE  varchar(100) ,
> APELLIDO  varchar(100) ,
> EMAIL varchar(100) ,
> ACCESO datetime
> )

	Pareciera que USUARIO_TIPOS tiene datos de más... no debería tener solo
un ID y una descripción?

> USUARIOS (
> ID int PK ,
> USUARIO varchar(50) ,
> PASSWORD varchar(100) ,
> NOMBRE  varchar(100) ,
> APELLIDO  varchar(100) ,
> EMAIL varchar(100) ,
> ACCESO datetime
> ) 

	Sacando la posible confusión de las letras de las facturas y las
categorías impositivas, todo lo demás es leve...

	Resolvamos estos detalles y sigamos adelante!

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