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;  

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

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Orders Module (Automatic interaction with Lyppards Australi

Hi Matt

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

Cool. Thanks Craig. Makes sense. Do I read between the lines that u have automatic updating already set up with a supplier?

Matt C

Re: Orders Module (Automatic interaction with Lyppards Australi

Affirmative, Provet E-Order through RxWorks. Changed our lives having the automatic incoming invoice entry.

_____________________________________________________ Craig Challen Vetwest Animal Hospitals

Re: Orders Module (Automatic interaction with Lyppards Australi

Looking forward to our lives changing also... :)

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

Hi Matt,

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

 

My name is Bill McGowan – I am the application development manager for Provet. Provet has an electronic ordering system that provides the functionality that you are requesting here and I have previously worked with the other major VPMS in Australia implementing this sort of system.
 
I would like to officially offer access to our e-Order Interface SDK and technical assistance to help your developer community implement electronic Order/Invoice exchange with Provet.
 
The e-Order Interface provides you the ability to seamlessly manage your inventory, ordering and stock tracking through your VPMS. This system will give you the ability to more simply and accurately manage the supply of the goods that you need to run your business. The e-Order Interface provides accurate pricing, and the ability to place orders/receive invoices electronically, all from the consistent User Interface of your system.
 
The e-Order interface provides 5 key services for your application:
·         Place Purchase Orders with Provet.
·         Receive Invoices from Provet.
·         Retrieve product and pricing information from Provet.
·         Receive order information from the e-Order Personal Data Terminal (PDT)
·         Receive stocktake information from the e-Order PDT.
 
The key tenants of the design of this interface were to make it simple to use and to seamlessly work with your system. We have used simple XML as our data exchange mechanism, and a COM interface to initiate the transfer of the information. We also provide the ability for your VPMS to communicate with Provet using pure COM, if you prefer not to use XML. Our system deals with all of the complexities of the Internet communication to our backend B2B System, and displays dialogs showing the status of the operation. So essentially all that is required in your system is to call a single method of our COM object and export or import an XML file.
 
To give you an idea of the development work involved in using our SDK, here is the code required to place an order in C#:
 

  int errorNo;
  var eoXML = new eorder4.XML();
  eoXML.SerialNumber = “YOURSERIALNUMBER”;
  OpenVPMSMethodToExportOrderAsXML(poFile);
  eoXML.SendPurchaseOrderFile(poFile, errorNo);
  //You may want to check the errorNo etc here
 

So that’s our solution in a nutshell – I can provide your developers extensive documentation and everything that they need to get this up and running if. Please let me know if you have any questions or if there is anything else I can do to assist.
 
Regards,
 
Bill

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

Syndicate content