[Php-avanzado] Consulta PHP, Nicolas Mozo.

[Leonardo Tadei - Pegasus Tech Supply]

Hola Nicolás!

El sáb, 08-11-2014 a las 13:44 -0300, Nicolas Mozo escribió:
> Muchas gracias aca le dejo mi respuesta, y enseguida le envio el SRS.
> Muchas gracias, saludos cordiales Nicolas Mozo.
> 

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


	Primero, documentar todo lo posible sin pensar para nada en cómo se va
a implementar.
	Segundo, tomar todos los datos del diccionario y aplicar las Formas
Normales al menos hasta la 3ra extendida.

	Haciendo esto te hubiera saltado que los usuarios de farmacias y
laboratorios son cosas distintas e independientes. (yo ya me sé el
final, por eso te lo cuento!)


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


	Pero este no es el proceso correcto para poder construir buen software!
	Tenés 2 caminos: uno es especificar solo lo que vas a hacer, y hacerlo;
el otro es especificar una cosa más amplia, y luego decidir no
implementar todos los RF.

	En la especificación funcional, como está ranqueada, te aparece el
orden de construcción del software, con lo que puede ser que haya cosas
que no pensaras implementar ahora pero que son necesarias para otras
cosas que sí vas a implementar.



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


	Pero si no especificás Pagos y Cobros, no podés hablar acá de "liberar
pagos", porque para liberar un pago hace falta registrar el pago!!!

	O le agregás los Pagos, o le sacás lo de liberar el cobro... y si le
sacás lo de liberar el cobro, tenés que ver cómo vas a tentar a que el
usuario marque el pedido recibido como satisfactorio, porque la gente no
suele hacer cosas que no le sirven para nada...



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


	Bueno, si no sabés como cobrar los gastos administrativos, no lo pongas
en la especificación. No podés construir un software que haga algo que
vos no sabés como se hace!!!


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


	Este sistema que estás especificando no puede analizar el stock de una
farmacia, porque no hay ningún mecanismo para que la farmacia de de baja
el stock.

	Si querés manejar stock, tenés que tener al menos un mecanismo de baja
y otro de alta...


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

	Capaz que no tenés que agregar vos los clientes de la farmacia, sino
que lo tenés que agregar es un "ticket de entrega" o algún comprobante
que, aunque no figure quien lo compre (el cliente), sirva para dar de
baja los medicamentos.

	Además, implementar clientes implicaría que las farmacias tengan que
anotar en TU software a SUS clientes, y capaz que no quieren.

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


	En realidad no: casi el único que existe se llama Pharmatronic, tiene
una interfaz DOS horrible y unas vueltas grandes para que funcione
decentemente.
	Este software lo sugieren los laboratorios (cuesta unos mangos por mes
por máquina, pero no mucho) y además de resolver la cuestión de stock,
pedidos y compras, maneja las liquidaciones a las obras sociales, hace
las autorizaciones contra cada una on-line, actualiza los precios de
costo directamente desde los laboratorios y maneja las ventas de queda
empleado de la farmacia. También hace cosas cuestionables, como reportar
basado en la matrícula profesional del médico todo lo que recetó en todo
el país, y en base a esto armar reportes para los laboratorios, que es
con lo que ellos "premian" a los médicos.
	Es un software de veras muy barato, porque es "subsidiado" en parte por
los laboratorios a cambio de la información sobre los médicos. No es
lindo para mi gusto, pero no es ilegal...


	Yo pensé que estabas armando más bien el software de una distribuidora,
en dónde recibías pedidos de varias farmacias, los concentrabas y hacías
pedidos de mayor volumen a los laboratorios. En este escenario el stock
era el tuyo, no el de la farmacia y toda la información era directamente
manejable por vos.

	Saludos cordiales

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