[Php-avanzado] Consulta PHP, Nicolas Mozo.
Leonardo Tadei - Pegasus Tech Supply
leonardot en pegasusnet.com.ar
Lun Nov 10 10:40:41 ART 2014
Hola Nicolás,
El sáb, 08-11-2014 a las 21:38 -0300, Nicolas Mozo escribió:
> Buenas tarde Leonardo, disculpe la tardanza, tuve unos problemas con
> internet.
>
>
> Dudas:
> - No se si implementar los Compradores[ 2 ], por el hecho que el
> sistema lo veo mas fiable en la relacion
> Farmacias->Vendedores->Laboratorios. No se usted que opina?.
Quienes son los vendedores?
Me ayudaría saber si estás pensando este software para que lo usen las
farmacias o te estás poniendo en el rol de una distribuidora que hará de
nexo entre las farmacias y los laboratorios.
Definir esto me parece decisivo para poder acotar el problema.
Respondeme esto antes de seguir porque es un contexto necesario para
saber desde qué punto se vista se enfoca la cuestión.
> - Modelo de pago/cobro, no se como especificarlo en el DICCIONARIO,
> por el hecho de que todavia no se que argumentos tendra, me tendria
> que poner a analizar las APIS.
Uy Nicolás, esto no tiene nada que ver.
En una SRS, vos tenés que poner qué es lo que el software va a hacer, y
nunca cómo lo va a hacer. En la parte de los pagos y cobros, tenés que
especificar el funcionamiento y el diccionario con los atributos que vos
necesitás.
Si más adelante una pasarela de pagos requiere algún dato más o menos,
será un problema de implementación a resolver, pero nunca un problema en
la especificación.
Si el cobro será vía entidades externas, sí está bueno documentarlo en
el diccionario, pero esto no debería afectar a la funcionalidad.
> - Generar ticket de pago, lo tengo que poner como una funcionalidad
> aparte?.
Todo lo que quieras que el sistema haga tiene que estar especificado en
alguna funcionalidad.
El ticket es claramente una cosa diferente de todas las otras y que
existe por sí mismo, así que seguro que será una funcionalidad aparte.
Pasemos a tu SRS:
- El RF13 sigue sin poderse implementar, porque seguís mencionando una
baja del medicamento que no está especificada. Especificá antes la baja
del medicamento y acá hacé referencia a ella como ahora hacés referencia
al pedido.
- El RF15 tampoco se puede implementar, porque no tenés especificados
los recorridos de logística de los productos. Sin recorridos no hay
Vogel (va sin la U pero se pronuncia como si la tuviera)
Saludos!
>
> 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 gestionar un modelo de pagos/cobros, utilizando
> alguna API de los medios de pagos disponibles en Argentina.
>
>
>
> 10. El sistema debe gestionar Procesos de Pedidos, el cual se
> asignaran los procesos a los cuales se encuentren los Pedidos, por
> ejemplo, si el pedido está Confirmado, o rechazo y demás .
>
>
>
> a) Primer paso, el comprador pide un medicamento de un
> laboratorio ( PEDIDO SIN CONFIRMAR, ya que el laboratorio tiene que
> dar el "OK" de que podrá brindarle el producto ) a través del modelos
> de pagos/cobro[ 9 ].
>
> b) 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í.
>
> c) Tercer paso, una vez aceptado ( CONFIRMADO ), el
> pedido pasara directamente a stock para su posterior comercialización.
>
>
>
> 11. El sistema debe gestionar Pedidos con sus Proceso de Pedido[ 11 ].
>
>
>
> 12. El sistema debe gestionar compras de medicamentos[ 8 ], el cual se
> almacenaran en pedidos[ 11 ], 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 ] .
>
>
>
> 13. El sistema debe gestionar Stock teniendo en cuenta el dar de alta
> un medicamento cuando concluye todos los Procesos de Pedidos[ 9 ], y
> la baja de medicamentos cuando se produce una venta. Una vez hecha la
> venta del producto se generara un ticket de pago, el cual la farmacia
> se lo proporcionara a su cliente ( cliente no es tenido en cuenta en
> el sistema, es para explicar el funcionamiento unicamente ).
>
>
>
> 14. El sistema deberá generar un informe, en el cual se especificaran
> todos los Pedidos[ 11 ] en todos sus procesos concluyentes.
>
>
>
> 15. El sistema deberá gestionar un sistema de Voguel el cual
> proporcione a los laboratorios[ 4 ] un diagrama de que productos y en
> donde los debe vender para lograr una mayor ganancia.
>
>
>
> 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.
>
>
>
>
> _______________________________________________
> 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
--
Leonardo Tadei
leonardot en pegasusnet.com.ar
Web: http://leonardo.tadei.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key
Más información sobre la lista de distribución Php-avanzado