[Php-avanzado] Consulta PHP, Nicolas Mozo.

[Leonardo Tadei - Pegasus Tech Supply]

Hola Nicolás,

El mié, 05-11-2014 a las 08:38 -0300, Nicolas Mozo escribió:
> 
> Hola Nicolás,
> 
> 
> estuve ojeando la SRS...
> 
>  >> - Las farmacias no tienen nombre al menos? Cómo sabés qué farmacia
> es
>  con esos datos?
> 
> Ahh, yo manejaba a las farmacias con el nombreUsuario, tendré que
> agregarle un nombre ( de perfil ).


	No conozco la especificación del problema, pero lo más habitual es que
la farmacia sea una cosa, y que el empleado de la farmacia que se
conecta sea otra. Esto permite habilitar varios usuarios para cada
farmacia, cosa habitual en las que tienen sucursales.


>  >>  - Al Laboratorio parece faltarle el nombreUsuario en el
> diccionario.
> 
> 
> Si discúlpeme, se me paso de largo.


	Ok. Igual, también es lo habitual hacer lo mismo que te digo con las
farmacias: los Laboratorios son una cosa y las personas que entran son
otra cosa.

>  >>  - Los Precios no son una funcionalidad aparte, si son solo un
> atributo
>  del Medicamento.
> 
> 
>  >> - Respecto a tu pregunta sobre el Medicamento, lo correcto es
> poner
>  Laboratorios (en plural según tu SRS); si es ID_nosequé u otra cosa
>  será una cuestión de implementación. También Familias va en plural,
>  porque decís que un Medicamento puede pertenecer a varias Familias.
>  No me cierra algo: no existen dos medicamentos con el mismo nombre
> (ni
>  código, que no existe en tu problema) que sean de más de un
> Laboratorio,
>  por una cuestión de marcas registradas. Es decir, a la Bayaspirina la
>  fabrica únicamente Bayer; otros laboratorios también fabrican
>  comprimidos con ácido salicílico, pero nunca pueden llamarse
>  "bayaspirina".
> 
> 
> Si es correcto lo que dice usted, pero yo esta funcionalidad ya la voy
> reservando para la V2 del sistema, ya que voy a implementar vendedores
> de laboratorios, el cual de un laboratorio voy a tener mas de un
> vendedor con el mismo nombre de medicamentos.


	Pero Nicolás! Esto no cambia la especificación!
	En tal caso en la versión 2 se agregarán Vendedores, pero con esto el
producto no debería sufrir cambios.
	Tu error es pensar ahora que esto del precio será así, lo que es un
error evidente, porque implicaría que tendrías repetidos los productos,
uno por cada vendedor, lo que sin dudas estaría mal normalizado.


>  >>  - Venta libre o bajo receta son Tipos de Venta, y como son datos,
> no se
>  especifican por separado. Es como que especifiques Familias y más
> abajo
>  pongas varias familias como ejemplo...
> 
> 
> No pueden ser Tipos de Venta, porque ese campo ya lo tengo asignado a
> otra funcionalidad.


	Si los Tipos de Venta son jarabe, comprimidos, pomada, etc, te falta
especificar qué es esto de venta libre o venta baja receta, porque no
aparece como algo de la especificación.
	Se menciona en el RF6, pero sin hacer referencia a la cosa.
	Yo creo que tenés mal los nombres: el Tipo de Venta es "libre" o "Bajo
receta" y si es jarabe, comprimidos, pomada, etc, es la Presentación.

	Luego, tenés que agregarle la Presentación al Medicamento.

	

>  >>  - Si no especificás como funciona el RF10, qué querés que hagamos
> para
>  ayudarte???.
> 
> 
>  >>  - El mecanismo para dar de baja el stock es el Pedido. Te falta
> un
>  mecanismo para dar de alta stock! Podrían ser Remitos de Compra...
> 
> 
> Paso a explicarle como funcionan los Procesos de Pedidos, para poder
> entender mejor el sistema:
> 
> 
> - Primer paso, el usuario adquiere un medicamento de un laboratorio
> ( PEDIDO SIN CONFIRMAR, ya que el laboratorio tiene que dar el "OK" de
> que podrá brindarle el producto ).
> - Segundo paso, acá el laboratorio tendrá dos posibilidades, o acepta
> el pedido o lo rechaza ( en ambas se notificara a la Farmacia ), en el
> caso de aceptarlo se procederá al tercer paso, y si se rechaza, todo
> termina ahí.
> - Tercer paso, una vez aceptado  ( CONFIRMADO ), el pedido pasara a
> estar en un proceso de ENVIO, el cual el usuario de la Farmacia, una
> vez recibido el producto, tendrá que confirmar el envió satisfactorio
> para liberar el pago al Laboratorio. En este punto la Farmacia también
> podrá cancelar el envió, en este caso se le cobrara un importe por
> gastos administrativos y dependiendo por donde vaya el envió
> ( Procesos de Envio, es algo que buscare implementarlo en una V2, pero
> igualmente se lo comento ). 
> - Cuarto paso, una vez confirmado el envió, ahí recién se almacena en
> Stock para su futuro gestionamiento.


	Ok. Entonces te hacen falta especificar los Estados de Pedido, y como
subrequerimiento de ese RF poner esta explicación, que son las reglas de
paso de un Estado a otro.

	Esta es la omisión que te estaba haciendo poner varios datos en un
mismo campo: no habías descubierto el Estado de Pedido como una entidad
independiente.

	Seguimos!



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