[Php-avanzado] Consulta PHP, Nicolas Mozo.

[Nicolas Mozo]

Hola Leonardo, muchas gracias por su ayuda, ahora enseguida reformo el SRS y se lo vuelvo a enviar. 
Saludos cordiales. Nicolas Mozo



> > 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.


El empleado, tanto del laboratorio como de la farmacia, lo podria gestionar como Vendedor?. 

> >  >>  - 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.
Estados de Pedidos es lo mismo que Procesos de Pedidos.


> 
> 	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
> 
> _______________________________________________
> Lista de correo: Php-avanzado
> Mensajes a la lista: Php-avanzado en pato2.fi.mdp.edu.ar
> Administración Web: http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
> Desubscripción: php-avanzado-request en pato2.fi.mdp.edu.ar?subject=unsubscribe
 		 	   		  
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://www3.fi.mdp.edu.ar/pipermail/php-avanzado/attachments/20141105/0bb4ce7d/attachment.html>