health-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Health-dev] Is the current version of Tryton far too complicated fo


From: Luis Falcon
Subject: Re: [Health-dev] Is the current version of Tryton far too complicated for GNU Health?
Date: Mon, 8 Sep 2014 11:56:39 +0100

Dear Axel, Carl and Andrew

On Mon, 08 Sep 2014 10:59:54 +0200
Axel Braun <address@hidden> wrote:

> Hello Carl,
> 
> Am Montag, 8. September 2014, 00:10:39 schrieb Carl-Johan Francke:
> 
> .....
> 
> > Thank you very much Luis for installing trytond_purchase on the
> > community database. Much appreciated for testing use cases.
> > 
> > I think that is a good idea to add tryton_purchase to gnuhealth. It
> > covers 99% of our needs.
> 
> A good point. An even better, if your below example is persistent in
> the demo database. (Can we use it with real supplier and product
> names?)
Axel, I have included Carl's data related to the meds supplier in the
health26 database. It is now persistent. This dump will be different
than the "standard" dump for the 2.6 series, since the latter
does not include these modules. We will make them default in the
upcoming GNU Health 2.8 .So, the community server demo DB will differ
slightly from the standard backup.

> > Going through our use cases, however I realized that we have some
> > few issues.
> > I have entered an example in the community database and described
> > it below.
> 
> Vers good, thanks for making this transparent!
> 
> > What I describe below are as far as I'm concerned tryton issues and
> > I suggest communicating the the tryton community to see if they
> > want to act. If they are not interested, I suggest starting a
> > health_purchase module which fixes these and any future issues we
> > might run into. I’m happy to contribute.
> 
> There were some discussion in the Tryton mailing list about purchase 
> functionality that could be improved. As all companies using Tryton
> can take advantage of it, it should ideally be in the core.
> Anyway, I could not grep how decisions, what comes into the core, are
> made, but I'm happy to learn....maybe on the TUL [1]?
> 
> > In case I have missed a way to solve the use case below, I'd be
> > grateful for suggestions.
> > 
> > What do you think about adding the Stock Supply module as well, so
> > that we can have order points?
> 
> Good point!
Done :)

Thanks all of you for your suggestions and contributions to enhance
the functionality in this important area of a health institution.

Best,
> 
> [...]
> 
> > When entering a purchase order
> > Supplier = "Virbac AG"
> > Supplier Reference = "Usecase"
> > and adding a purchase line for
> > product name = "[IVI-1561] Feligen CRP ad us. vet."
> > 
> > - current behavior: the pricing of the product supplier line with
> > the lowest sequence is used.
> > - wanted behavior: pop up a window asking for which product supplier
> > line to be used (if there is more than 1 product supplier line for
> > this supplier)
> > 
> > Further,
> > - Current behavior:  purchase line description = "[IVI-1561]
> > Feligen CRP ad us. vet.", i.e. our internal name
> > - Wanted behavior:  purchase line description = "[913-300392]
> > Feligen CRP 10er package", i.e. the name that the supplier uses
> 
> This should be in the communication with the supplier, not
> necessarily on our own view (might confuse a purchase clerk).
> Shipment costs and trading terms are as well to be specified.
> 
> Cheers
> Axel
> 
> 
> 
> [1] http://tul2014.tryton.org/
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]