[Php-avanzado] Consulta PHP, Nicolas Mozo.

[Nicolas Mozo]

Muchas gracias aca le dejo mi respuesta, y enseguida le envio el SRS. Muchas gracias, saludos cordiales Nicolas Mozo.
Hola Nicolás,



El mié, 05-11-2014 a las 21:07 -0300, Nicolas Mozo escribió:

> Hola Leonardo, agradezco su apreciación, aquí le dejo el nuevo SRS,

> con el arreglo de los Vendedores y Compradores. Cambien quería

> preguntarle el hecho de que yo en futuras versiones me gustaría

> implementar nuevas herramientas como por ejemplo, si una Farmacia

> quiebra o desea cerrar, permitirle abrir una especie de mercado, el

> cual pueda colocar lo que le quedo de Stock y venderlo a otras

> farmacias que lo requieran, en este tipo de casos se cambian los roles

> de Vendedor Comprador. En cuestion, mi pregunta seria, este sistema,

> así como esta implementado, es flexible a esta posible actualización

> futura?.



Sí, lo permite agregando solo una funcionalidad: la de convertir a un

comprador en vendedor y traspasarle el stock.

De todas formas, no sería correcto tenerlos todos juntos, ya que por

ejemplo un usuario de una farmacia haría referencia al ID de farmacia 3

y por ejemplo un usuario de laboratorio haría referencia al ID de

laboratorio 5, pero si no agregás más datos a los usuarios, no tenés

como saber a qué hacen referencia ese 3 o 5. La "solución" incorrecta
es

agregar otro campo para saber si es farmacia o laboratorio, y con esto

poder generar la query correcta para saber de dónde es el usuario. Eso

se llama "campo discriminador" y cuando aparece, es un indicador de
que

las tablas están mal normalizadas.





//Entonces la manera correcta seria?.



De todas formas, acá estás especificando, y si hay vendedores y

compradores, tenés que ponerlo, independientemente de cómo lo vayas a

implementar después.



> También quería brindarle a los usuarios de los laboratorios, un

> diagrama de Voguel, para que ellos que ventas son mas factibles y

> propensas a una mayor ganancia. 





 Vogel? El del cálculo de costos según las rutas de envío?
Si es ese, te harían falta las rutas para generarlo. Si no es ese

diagrama de Vogel, no lo conozco. Me enviarías un enlace para saber de

qué se trata?



//Sisi por eso mismo, era mas que nada para saber, es una funcionalidad futura,
y quería ir mas o menos sabiendo que funcionalidades o tablas iba a tener que
implementar o modificar.





> SRS Pharmar.

> 

> 

> 

> 1. El sistema debe gestionar Vendedores.

> 

> 

> 

> 2. El sistema debe gestionar Compradores.

> 

> 

> 

> 3. El sistema debe gestionar Farmacias con sus Compradores [ 2 ].

> 

> 

> 

> 4. El sistema debe gestionar Laboratorios con sus Vendedores [ 1 ].

> 

> 

> 

> 5. El sistema debe gestionar Familias, especifica a que enfermedades

> atienden dichos medicamentos.

> 

> 

> 

> 6. El sistema debe gestionar Tipo de Venta, que determinaran si un

> Medicamento es de venta libre o bajo receta.

> 

> 

> 

> 7. El sistema deberá gestionar una Presentación respecto a cómo vienen

> diseñados los medicamentos.

> 

> 

> 

> 8. El sistema debe gestionar medicamentos obtenidos de sus

> Laboratorios[ 4 ], con su Tipo de Venta[ 6 ], a que Familias[ 5 ]

> pertenece y su Presentación[ 7 ].

> 

> 

> 

> 9. El sistema debe indicar si el medicamento[ 8 ] se adquiere bajo

> receta o es de venta libre, este campo es necesario para la posterior

> venta de la farmacia a sus respectivos clientes. Cabe aclarar que

> clientes no se encuentra considerado en la Versión 1 de dicho sistema.



Este RF no hace falta: ya está contemplado en el RF 6.

A lo sumo, pasá la explicación al diccionario del RF 6.



> 10. El sistema debe gestionar pedidos.



Esto está incompleto: debería ser algo como "El sistema debe gestionar

Pedidos con la Farmacia que lo pide, los Medicamentos solicitados, el

Proceso de Pedidos actual etc, etc."



Implica que tenés que especificar los Procesos antes del Pedido.



> 11. El sistema debe gestionar compras de medicamentos[ 8 ], el cual se

> almacenaran en pedidos[ 9 ], que este a su vez contendrá a la Farmacia

> [ 3 ], con su Comprador [ 1 ], que adquirió el medicamento[ 8 ] y el

> laboratorio[ 4 ] que lo fabrica, con su Vendedor [ 2 ] .



No me queda claro...

Querés decir con esto que un Pedido de una Farmacia se transforma en

una o más Compras a cada Laboratorio, según los Medicamentos que se

hayan pedido???



> 12. El sistema debe gestionar Procesos de Pedidos [ 8 ], el cual se

> asignaran los procesos a los cuales se encuentren los Pedidos[ 8 ],

> por ejemplo, si el pedido está Confirmado, o rechazo y demás .



Este es el que pasa más arriba.



Los pasos que siguen, ponemos como subitems del Pedido, porque

especifican qué camino sigue un pedido (es decir, el proceso)



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



En este paso decís que el "usuario adquiere", pero si no entiendo
mal,

debería decir que el "comprador pide".

Esto es porque hay compradores y vendedores (pero no usuarios, lo cual

está perfecto) y porque si es el primer paso para hacer un pedido, se

está pidiendo (adquirir es más un sinónimo de compra, que será tu último

paso)



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



Acá hablás de pagos, que es algo que no aparece en tu SRS...

Parece que es algo que falta, porque si no hay un registro de un pago,

no hay pago que liberar.



//El tema de los Pagos, no lo especifique, porque no me puse a ver como se
manejan los sistemas de pagos/cobros por internet, y primero quería hacer bien
el esqueleto del sistema para después poder agregarle lo de pagos/cobros.


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





Entonces también te faltan especificar los gastos administrativos,

porque si no, no podés calcular esto.





//Gastos administrativos, tampoco se como calcularlo, se que por lo menos una
sanción tiene que haber con respecto a la farmacia, pero no se como llevarla a
cabo, si hacerlo por un monto de dinero o implementar un sistema de valoración y
que ese envio cancelado les juegue en contra, estoy medio en la nebulosa con
ese tema.


> - Cuarto paso, una vez confirmado el envió, ahí recién se almacena
en

> Stock para su futuro gestionamiento.



Cuando todo termina, los Medicamentos aumentan el stock de la farmacia,

que es la que recibe el pedido???





//Si, o sea, el sistema analiza si en el Stock de la farmacia que
adquirio los medicamentos, si el medicamento existe, entonces se le sumaran la
cantidad correspondiente, es decir, medicamento_stock +
medicamento_pedido_entrante, y en el caso de no existir ese medicamento en el
stock, se insertan los datos del medicamento_pedido_entrante.



> 13. El sistema debe gestionar Stock teniendo en cuenta el dar de alta

> un medicamento cuando concluye todos los Procesos de Pedidos[ 12 ], y

> la baja de medicamentos cuando se produce una venta.



Y dónde está el registro de las ventas de los medicamentos???

Sin el registro de las ventas te falta el mecanismo de baja de stock!!!





//Claro, cuando un cliente de una farmacia compra los medicamentos, se
van dando de baja con respecto a la compra que haya efectuado el cliente,
escribiendo esto, me doy cuenta que tendre que agregar una funcionalidad de “gestionar
clientes…”, o no?



> 14. El sistema deberá generar un informe, en el cual se especificaran

> todos los Pedidos[ 9 ] en todos us procesos concluyentes.

> 

> 

> 

> 

> 

> 

> 

> DICCIONARIO:

> 

> 

> 

> Compradores = Usuario, adherido a Farmacias, el cual está encargado de

> comprar/adquirir los medicamentos elaborados por los laboratorios.

> Atributo: nombre, nombreUsuario, contraseña, email, representante.

> 

> 

> 

> Vendedores = Usuario el cual esta encargado de la venta de los

> medicamentos sustraídos de los Laboratorios. Atributo: nombre,

> nombreUsuario, contraseña, email, representante.

> 

> 

> 

> Farmacias = Tipo de usuario que posee una farmacia física. Atributo:

> nombre, nombreUsuario, contraseña, email, representante.

> 

> 

> 

> Laboratorios = Tipo de usuario que posee un laboratorio físico, y

> desea gestionar sus productos a las diferentes Farmacias registradas

> en la web. Atributo: nombre, nombreUsuario, contraseña, email,

> representante.

> 

> 

> 

> Familias = Tipo de familia a la que corresponde el medicamento, es

> decir, al tipo de enfermedades a la que dicho medicamento se aplica.

> Atributo: nombre.

> 

> 

> 

> Tipo de Venta = Tipo de venta que determina en que forma se adquiere

> el medicamento, ya sea de Venta Libre o Venta Bajo Receta. Atributo:

> nombre.

> 

> 

> 

> Presentacion =Tipo de forma en la que viene diseñado los medicamentos.

> Atributo: nombre.

> 

> 

> 

> Medicamento = Medicamento desarrollado por los laboratorios. Atributo:

> nombre, precio, tipoDeVenta, ID_familia, ID_laboratorio.

> 

> 

> 

> Pedidos = En esta sección se controlan las ventas de los productos.

> Atributo: ID_medicamento, ID_farmacia, ID_laboratorio, cantidad,

> ID_proceso, precioPorUnidad, precioTotal.

> 

> 

> 

> Procesos = Se detallaran en que situación se encuentra el pedido, por

> ejemplo si esta confirmado por el Laboratorio, si lo rechazo, si se

> envió y demás. Atributo: proceso.

> 

> 

> 

> Stock = Espacio virtual en la cual llevamos un conteo de los productos

> que se encuentran en cada farmacia, es decir, donde se almacenan

> todos los pedidos que se realizaron con éxito, a demas se podrá

> gestionar todos estos productos desde la web. Atributo:

> unidadesStock, unidadesVendidas, importe, farmacia, laboratorio,

> medicamento.





Tu definición de stock me confunde mucho: el planteo del sistema parece

ser para alguien que conectará Farmacias con Laboratorios y va a

intermediar en el proceso que acá llamás "nuestro establecimiento"
(por

eso cobra gastos administrativos).

Si esto es así y como decís más arriba el Laboratorio manda el Pedido a

la Farmacia, los medicamentos jamás pasan por tu propio depósito y no

tenés como contarlos físicamente.

Esto es una contradicción...





Te hago varias preguntas intercaladas con la SRS. Por favor,

respondelas junto con la nueva versión.





Si por una de esas no podés revelar detalles del negocio por esta lista

que es pública, no podremos hacer esto por esta vía... con información

incompleta es inviable poder llegar a una buena solución.





//Con eso no hay drama, deben existir muchísimos sistemas de gestión como
este, tal vez yo por presentar los SRS a las apuradas se me saltean algunos
datos, pero no tengo ningún problema en darlos a conocer en publico.



Saludos! 		 	   		  
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://www3.fi.mdp.edu.ar/pipermail/php-avanzado/attachments/20141108/89c51c03/attachment-0001.html>