[Php-avanzado] Normalización

[David Barraud]

Bien, entonces me faltaría una tabla en #solicitudes que me guarde los
insumos que se usan para cada solicitud y el cálculo del stock de los
insumos sería la sumatoria de las Alta de Stock - baja de stock - baja de
stock en las solicitudes.

Si estoy en lo correcto decime si estas tablas quedarían de esta manera:

*#solicitudes*

id_solicitudes

id_depto

id_estado

fecha_inicio

fecha_fin

problema

solución



*#RemitoBajaStockSolicitudes*

id_baja_solicitudes

id_solicitudes

id_producto

nombre

cantidad

Muchas gracias!



El 5 de julio de 2012 01:09, Leonardo Tadei - Pegasus Tech Supply <
leonardot en pegasusnet.com.ar> escribió:

> Hola David,
>
> El mié, 04-07-2012 a las 17:53 -0300, David Barraud escribió:
> > Hola Leo, ya voy entendiendo mejor lo de los remitos, vamos a la parte
> > de dar de baja el stock del insumo.
>
>         Veamos!
>
> > Voy a tener 2 mecanismos para dar de baja el stock:
> > 1. cuando se rompe o se tira algún insumo.
> > 2. Cuando se usa algún insumo en la solución de la solicitud de
> > trabajo.
>
>         Ok.
>
> > En el primer caso las tablas serían similares al remito de Alta de
> > Stock, salvo que se agregaría un campo con el motivo de su baja.
>
>         Estoy de acuerdo.
>         En este caso, agregá al diccionario del remito de baja el "motivo".
>
> > En el segundo caso la solicitud generaría un nuevo remito de baja del
> > stock. Estoy en lo correcto?
>
>         Es más simple!
>         La Solicitud de Reparación _es_ un comprobante de baja, y en su
> cabecera tiene todos los datos de la Solicitud...
>
>         De la misma forma por ejemplo, en un sistema comercial, el remito
> de
> compra tendrá en su cabecera todos los datos del proveedor, el nro de
> remito, la fecha en que fue emitido, etc.
>
>         Vos estás pensado en que la Solicitud genere un nuevo comprobante
> de
> baja, pero esto es más complicado, porque tendrías que discriminar los
> comprobantes según por dónde vienen para por ejemplo hacer un informe de
> los insumos usados (y no de los tirados).
>         Pero lo más importante no es que es más complicado, sino que sería
> un
> artificio que no refleja la realidad. La realidad sería imaginarte como
> sería esto si tuvieras que hacer comprobantes en papel para reflejar
> cada movimiento de stock... llegarías sin dudas a tener tres: el remito
> de alta (posiblemente incluyendo el proveedor por las garantías), el
> remito de baja por roturas en dónde en cada item habría lugar para poner
> el motivo, y la solicitud de reparación, que tendría una cabecera más
> grande y algunos renglones en blanco para poner los insumos que se usan,
> si es que se usan.
>
>         Cómo lo ves a la luz de esto que te cuento?
>
>
>
> > Si todo esto es correcto te paso la nueva normalización a ver qué
> > opinás.
> >
> >
> > Normalización
> >
> > #departamentos
> >
> > id_depto
> >
> > nombre
> >
> >
> >
> > #categorias
> >
> > id_categoria
> >
> > nombre
> >
> >
> >
> > #insumos
> >
> > id_producto
> >
> > id_categoria
> >
> > imagen
> >
> > nombre
> >
> >
> >
> > #RemitoAltaStock
> >
> > id_remito_alta
> >
> > fecha
> >
> >
> >
> > #RemitoAltaStockDetalle
> >
> > id_alta_detalle
> >
> > id_remito_alta
> >
> > id_producto
> >
> > nombre
> >
> > cantidad
> >
> >
> >
> > #RemitoBajaStock
> >
> > id_remito_baja
> >
> > fecha
> >
> >
> >
> > #RemitoBajaStockDetalle
> >
> > id_baja_detalle
> >
> > id_remito_baja
> >
> > id_producto
> >
> > nombre
> >
> > cantidad
> >
> > motivo
> >
> >
> >
> > #solicitudes
> >
> > id_solicitudes
> >
> > id_depto
> >
> > id_estado
> >
> > id_remito_baja
> >
> > fecha_inicio
> >
> > fecha_fin
> >
> > problema
> >
> > solución
> >
> >
> >
> > #estados
> >
> > id_estado
> >
> > estado
> >
> >
> >
> > En la tabla solicitudes el campo id_remito_baja sería un campo nulo ya
> > que en el caso de que la solicitud de trabajo no necesite insumos para
> > solucionar el problema, no es necesario generar un remito de baja de
> > insumo por lo que este campo no tiene ningún dato.
> > _______________________________________________
> > 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
>
> _______________________________________________
> Php-avanzado mailing list
> Php-avanzado en pato2.fi.mdp.edu.ar
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://www3.fi.mdp.edu.ar/pipermail/php-avanzado/attachments/20120705/dc605064/attachment.html>