Orders Module (Automatic interaction with wholesalers)
Hi everyone,
Boronia VC has been in discussion with Lyppards (one of our founding sponsors) for some time now about automating price updates and integrating our ordering and receipt of stock. Our hope is that in working this process through in the forums may create the opportunity to create a solution that will have application for other forward thinking veterinary wholesalers.
Understandably this interaction will end up requiring some fairly technical solutions between IT entities both within the Open VPMS community and the wholesalers themselves. For us users however, I am inviting discussion about what functionality we might hope for in this type of interaction.
This is potentially a huge topic. Open VPMS version 1.3 already has much of the required data in the product & orders section prepared for this type of interaction. So I am suggesting at this stage that we do our best to discuss procedures that utilise the existing product and orders framework within version 1.3 There was the option for OpenVPMS and Lyppards to create a solution behind the scenes, especially given the potential for complexity within this process. That is not the idea of development within our OpenVPMS community. So I am calling for all users of Open VPMS and especially those of you who are already Lyppards clients to make contributions to this topic.
Even if your contribution is just to indicate support for the process Lyppards is considering undertaking.
I am going to start the conversation with 2 broad aims;
- Ordering - Allow orders generated within OpenVPMS 1.3 to be submitted electronically or as a printed document to a wholesaler. Ideally electronic submission is ideal to allow automatic processing at the wholesaler end.
- Deliveries - Allow Deliveries to be automatically uploaded into OpenVPMS 1.3. This is intended to automtically update inventory and prices based on wholesaler list price.
I have one question to get the ball rolling; a) How will new products be handled? For example, if I want to order a product that my wholesaler does not yet have, how will I indicate that in my order?
Cheers, Matt C
Re: Orders Module (Automatic interaction with Lyppards Australi
That question is really a management one, not one to be dealt with via the software. The only way you can really deal with that situation is to get an order code from the supplier and add it to your system before ordering. Pretty hard to see how you can come up with a magic in the program to get around that.
From our experience (with another VPMS and another wholesaler, but really no different) is that you have to have the discipline to ban the staff from ordering anything other than via the electronic interface (we actually told the wholesaler not to accept phone or fax orders from us) so that the above has to happen. Everyone gets used to it and it is well worth it then.
Craig Challen Vetwest Animal Hospitals
Think before you print.
Re: Orders Module (Automatic interaction with Lyppards Australi
Matt C
Re: Orders Module (Automatic interaction with Lyppards Australi
_____________________________________________________ Craig Challen Vetwest Animal Hospitals
Re: Orders Module (Automatic interaction with Lyppards Australi
Tony another question or to those using/having used E-Order, how does the update occur? Are the invoices/files imported directly or via email?
Matt
Re: Orders Module (Automatic interaction with Lyppards Australi
Proprietary internet transport protocol initiated by Eorder application which is installed on a Pc or server. Most likely some form of secure http transport like web services but haven't investigated. Not email atatchments though ...
I believe Provet also provide an Application programming Interface that can be used by Windows based software to communicate to Eorder directly. I believe it can also load and dump xml style files.
So in many ways similar to way Eclinic operates ...
Cheers Tony
Orders/Deliveries with Provet
Orders Module (Automatic
The OpenVPMS architecture is based around java and webservices, so we really need an interface that is not COM nor GUI based.
Do you provide a SOAP or REST based interface?
-Tim
Orders Module (Automatic
Hi Tim
No we do not have a SOAP or REST based interface, which does rule out our solution in those clinics with no Windows PC's.
However I would point out that our interface has been used by other Web Applications and can be called by a Windows PC via Javascript.
Regards,
Bill
Orders Module (Automatic
Hi Bill,
Thanks for your great summary of your current interface and your offer to provide access to the specification of this interface to the OpenVPMS development community.
I think the OpenVPMS community philosophy on interfacing in general is to provide a standardised mechanism to allow any interested party to build a broad range of integrated solutions for OpenVPMS users but not to be responsible for each individual interface that uses that standard.
For example, if our interface is SOAP/REST based Provet would be responsible for building the necessary "middle ware" to talk between the eOrder COM interface and this "standardised" interface. The same would apply to Lyppards, Cenvet, an all the other wholesalers in Australia and Oversees.
Why ?
Well firstly being community funded OpenVPMS needs to make sure it gets maximum value from its development resources as these are being paid for by supscriptions and chip in $'s to specific projects. If we take on the responsibility of not only developing but the ongoing maintenance of specific interfaces for specific wholesalers I can see these resources being chewed up very quickly. Remember in an open source project some of these resources are contributed and are not infinite so something else would have to miss out.
Secondly we firmly believe in standards, whether its for B2B communications (XML, Web Services, etc), Health data interchange (HL7, DICOM) etc. Yes, there are disadvantages (time to develop, cost) but the advantages are we have systems that are "open" and who's specifications are controlled by governed industry bodies not by individual companies. This means no lock-in or lock-out which is a primary concern for the whole community.
So heres how we see this project progressing:
1. The veterinary community defines the type of functionality needed from this interface. The veterinary community includes wholesalers and we expect an active role by you guys in the discussions.
2. The developer community defines the standard interface architecture and writes the specification. The developer community also includes wholesaler IT representatives, implementers, integrators and OpenVPMS developers. So here you get an equal say in the agreed standard.
3. The project is costed, funded and built. I would expect wholesalers to chip in some funds to this part of the project but in essence it will be community funded.
4. Wholesalers build the necessary "middleware" to interface to their existing systems. They are free to utilise the community developer resources to help them through this process but they are completely responsible for all their own development costs and the ongoing upkeep of the interface.
Bill, given your knowledge and experience of the processes involved in wholesaler interfaces I am looking forward to your involvemnet in all of these stages. Same applies to other wholesalers who have expressed interest in this project.
I personally would like to see this project progress quickly as I think it has some huge advantages to all veterinary industry participants. My next post will concentrate more on the Use Cases based on the discussion by Matt C, Matt Y and Daniel D and discussions I have already had with some wholesalers. Hopefully this will help move quickly towards a specification and then some development. Lets keep pushing hard on this one :-)
Cheers
Tony
Orders Module (Automatic
Hi Everyone,
I am please to say the electronic ordering module discussions have progressed significantly to the point where we have been able to complete the interface design work and are ready to start developing the new module.
It has even had a name change to reflect the fact that it will eventually deal with a much broader range of interactions with suppliers. It is now called ESCI (Electronic Supply Chain Interface).
You can find more details about the project and links to the various JIRA entries on the project page here .
We are very excited that the project has reached this point but now we need the community to contribute to it so it can be developed, tested and released. We hope practices, wholesalers and other industry participants will get behind the project.
Tony
Orders Modules
Cath Colton Cenvet Business Services
Cenvet Australia Pty Ltd are pleased to pledge $5,000 and are looking forward to working with the OPENVPMS community
Cath Colton
Cenvet Business Services