Electronic Supply Chain Interface Project (ESCI)

Donate to this project

Development Project Status: Completed

Total cost estimate (ex-Tax): 
Current Percentage Funded: 
Project description: 

For some time now, some veterinary wholesalers have been keen to investigate automating price updates and integrating ordering and receipt of stock. Our hope is that in working this process through in the Ope VPMS user community may create the opportunity to create a solution that will have application for other forward thinking veterinary wholesalers.

There are at the moment, 2 broad aims;

1. Ordering
- Allow orders generated within OpenVPMS 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. This is intended to automtically update inventory and prices based on wholesaler list price.


User forums:Current forum and Older associated forum


At this stage we believe we have enough information to turn this discussion into  a development project and start to seek funding. 

We have created an overall project JIRA for what we have now called the Electronic Supply Chain Interface project (ESCI).  You can find it here https://openvpms.atlassian.net/browse/ESCI-1 .  We will divide the overall project into a number of smaller sub projects so we can manage releases and funding better.  Our intention is to build up the complete ESCI over time using a number of these sub projects according to priorities based on community input.  

The first sub project will deal with developing the interface used to send Orders to and receive Order Responses from suppliers.  We have called this Simple Ordering Services (https://openvpms.atlassian.net/browse/ESCI-2)  as it only deals with sending of orders and receiving simple accept and reject messages.  It does not deal with the more complex process of order changes and cancellations. This sub project includes developing the definitions of all the documents that will be transmitted between supply chain partners , the development of the interface components and also development of a test application.Once completed suppliers can use the provided documents and applications to start building and testing their side of the interface. 

The second sub-project deals with integrating the Simple Ordering services with OpenVPMS (https://openvpms.atlassian.net/browse/ESCI-3).  It will utilise the interfaces we developed above and per supplier configuration information to send orders from the Orders Workspace , manage Order status and provide notifications to users on any order status changes.  The reason we have decided to separate this from the development of the core ordering services is it will hopefully speed supplier development and adoption. 

Estimated times to deliver these two sub-projects have been provided in the JIRA's noted above.  Aproximately 30% of this time will dedicated to elaborating the specifications for the projects and building common components that will be utilised in subsequent ESCI projects such as deliveries, invoices and catalogue requests.

We are now looking for funding to get development of these first projects underway. We look forward to your involvement and contributions.


Comment viewing options

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

Automatic ordering with invoice confirmation parsing

This comment was made by ddricot:

I've already have some discussions with some vets about some the usability of some technicaly feasable solutions for automatic import of the orders made with their wholesalers.

Of course, I don't know the functionalities proposed by all the wholesalers, but with those we know, we prefer this kind of solutions:

1. Keep using the Internet Site (or the phone, fax) for ordering. By keeping the direct usage of the wholesaler site, the user can get some extra informations that are not available through API like special prices, new products, ....
2. Receive the ordering confirmation by Email. This Email contain all the informations we need to import the product automaticaly (at least for already known products)
3. Automaticaly import the Email in VPMS by parsing its contents. Moreover, in Belgium, it is legaly compulsory to keep this Email during 10 years

For deliveries, we think that a simple bar code scanning of all the received products is more reliable then a automatic update based on a document.

Daniel Dricot

Automatic interaction with wholesalers

Hi Daniel,

Thanks for your input and the European perspective.

We had a meeting with one of our wholesalers, Lyppard Australia (one of a founding sponsors) today which was really helpful. Several key issues were raised and I would welcome discussion of some in these forums to get a broad perspective on how people see they may be resolved.


First afew points raised by Daniel,

Mode of electronic communication

"Receive the ordering confirmation by Email. This Email contain all the informations we need to import the product automaticaly (at least for already known products)"

I'm probably not the right one to comment here but my understanding is that relying on email can make the data exchange less robust when considering the diverse environments that the solution may need to be deployed. I think that other modes of data exchange can still meet the legal requirements of a recorded transfer of data and still allow a user to check backwards through the various orders and delivieries, but I'll defer to the experts on this one.

Receipt of delivery

"For deliveries, we think that a simple bar code scanning of all the received products is more reliable then a automatic update based on a document."

I think any automatic updating of prices and stock quantities should indeed be manually reconciled. Whether scanning the received products using a bar code scanner or checking and if needed modifying the quantities manually via a workspace populated by the delivery data.

Rich exchange of data

"By keeping the direct usage of the wholesaler site, the user can get some extra informations that are not available through API like special prices, new products"

An excellent example of where the standard automatic updating of prices might need to be more flexible? Can the developers think of a way to handle things like prices that may only exist for a specified period of time (specials)?  Perhaps this specific example is not that important given that most practices do not vary their retail prices based on specials on list prices.  But what about volume discounts? As for new products, I will reserve discussion for the next point - "product matching", which was raised today by Lyypards.


The following points arose from our discussions with Lyppards today.

Product matching

How should we create the links between a wholsalers product catalogue and our own? One idea that we had today was that we could have an workspace that allowed us to use search critieria such as trade name or active ingredient to match products in our own product database with those in the wholesalers. Once the two are linked, the workspace could populate all the Supplier fields that currently exist in our Products. 

Another idea that came up was that rather then doing this process gradually on receipt of each delivery, that if we could have just match all those products that we had ordered within a defined period of recent history (say 6 months) by uploading a data file provided by our wholesalers, it would mean we would only have to "map" or "link" those products we use in our individual clinics.


New Products

This was discussed by Craig in another forum post. He suggested that in his clinic, if it is not listed, they can't order it until it is. He suggested that it just saved confusion and streamlined the advanatges of e-ordering in the first place. But would it be a good option that as the wholesalers list a new product, that OpenVPMS users might be able to "import" the new product, straight into OpenVPMS, complete with all supplier links? Once in the Products section, we could then edit it to suit our own habits but the links would remain. This is especially important from the efficiency of both the vet and wholesaler end. If we can limit those items that are allowed to appear within the order for a specific supplier, then the supplier doesn't need to worry about calling the clinics to match items and the vet knows that what they are ordering is what they matched in the first place.

However the wholesaler still needs a mechanism to handle incorrect codes, despite them theoretically never happening in the above model.


Back ordering

How do we expect those items ordered but placed onto back order? Most of us would like the item to remain on back order until it becomes available. But what if we want to cancel that standing order? How does the individual item ordered reconcile? And what happens if only a partial quantity can be delivered? Does that order item remain with an altered quantity? How is the transaction history for that order item recorded?



Thats all I can think of for now. I expect to see some vigorous discussion based on this post. Everyone is welcome to attack the points I've made and criticise my logic... just be nice please :)


Matt C



Automatic interaction with wholesalers

Hi everyone,

This project was slated for end of discussion today but given the discussion has principally been one sided I have extended the discussion time.

With stocktake fresh in our minds, is the appeal of not having to receive stock and then manually update prices and quantities not appealing to you all?


Matt C

Automatic Ordering: How do split orders get handled?

Hi everyone,

I was wondering how the following scenario might be handled.


1. Clinic X orders the following;

Order #1

10 x Drug A

10 x Product B


2. The order arrives with the following;

Delivery #1

5 x Drug A

10 x Product B

(5 x Drug A on backorder)


When reconciling Order 1 with Delivery 1, how does it handle the the incomplete quantity? When the backorder arrives in Delivery #2 how will the extra quantity be handled given it will not have appeared in the subsequent order?

And even  more tricky what about this scenario?


3. Order # 2

10 x Drug A


4. Delivery

15 x Drug A


Here the backorder quantity has been added to make up to a total that does not agree with Order #2. 


Matt C

Automatic interaction with wholesalers

Hi Matt,

just a few comments.


re: special prices

Could specials be given a new field that is not a required one? So that the normal list price is listed in one field and the special price in another field. The user could then set their preference as to what to do with a special price ie. whether to determine sales prices based on the special price or the normal list price.


re: product matching

Would barcodes be a good independant way of matching up products. Most products these days have a barcode. This is independant of the wholesaler. Barcode scanners can be bought really cheap and it would make it alot easier to add missing data.

If the data could be exported/imported in CSV format it could be manipulated externally in a spreadsheet to add barcodes and then match the barcodes with supplier specific codes. It would be much easier to do then updating via the interface.

Once orders are generated if they were exported in csv format it could then be up to the wholesalers to determine how to get the order into their own system. 

The same csv format could be used to update prices, add new products and add specials.

What if there was a place in one of the workspaces where updates, specials, etc were sent to? They could be imported via csv from a folder similar to the way investigations are imported. I think it's important to have some form of manual intervention in this workspace though, ie. changes would need to be approved before being applied to the system.



Matt Y. 

Automatic Ordering/Stock Control

I hope this does not fall off the list as it is a very time consuming or neglected part of practice.

Keeping it simple for the start by simply adding the ability to order and receive stock using a bar code reader plus maybe adding trigger amounts to generate orders would be a huge advantage.

I would be prepared to contribute a reasonable amount as I feel I would save thousands of dollars by having a good stock control system by time saving, minimising wastage and keeping track of unbilled items


Electronic Supplier Interface

Hi Everyone,

Sorry for the lack of response on this project.  We have been working in the background to get information from suppliers and users about what is required and had neglected to do a catch up on the web site.

Hopefully the following will get everyone up to date with our discussions and thoughts and answer some of the questions above.

From our research of existing existing electronic business to business supply chain management systems (yes thats the formal name of the project we are looking at) the electronic processes are split up into the following categories.


This is where a buyer gets information about products and prices from a seller and is subdivided into Catalogues and Quotations.

Catalogues provide a means for a supplier to send product information to a customer whether initiated by the seller or by the customer.  Electronic catalogues can be requested , rejected, updated and deleted.

Quotations provide a mechanism to request a quoted price on one or more products based on already setup contract terms and pricing breaks.

As mentioned in many of the posts above one of the major issues in a electronic relationship between a supplier and the vet practice is how to link a practices product listing to a suppliers products.  In order for electronic ordering to occur this is paramount.   For many existing relationships the practice has gone through the pain of making these links by entering product supplier information such as reorder codes, pack sizes, bar codes etc.  But as new products are introduced and old ones phased out this is a ongoing maintenance task. 

In some software systems the answer to this is they provide these links as long as you maintain a common product list so they can upload new products and prices.  This system breaks down if you add you rown products or decide to order from an alternative supplier which does not have a relationship with the software supplier and hence no preloaded product details.

There was also some suggestion that the common identifier for products was a unique bar code but again this does not seem to be common in the vet industry.  Suppliers have be known to implement their own bar code to over come this limitation but again this is supplier specific and does not resolve the problem.

I believe we can utilise some of  the standardised B2B supply chain process's above to overcome this.  Heres how.

During ordering we can provide a query option that will allow users to search the selected suppliers product listing by any combination of brand/generic name, reorder code.  The request will be forwarded to the suppliers interface (lets not worry about how this will happen yet  but each supplier can have their own implementation) and a list of matching products returned. Essentially this is a request to the supplier from the customer for a partial catalogue.  Note this search will only need to be done on products that have no stored supplier information for the particular supplier and product. 

The customer can select a product from the listing which will initiate a quotation request to the supplier for the specific product details.  This request may include quantities required and will return product details (reorder code, descitpion, package sizes etc) and specific prices for that customer and quantity.  

This information is then stored against the customers product for subsequent orders as what happens now in the ordering workspace.


  • Suppliers need to implement this type of electronic catalogue.  I believe some already have this either in theri existing interface software or on web sites.
  • Pack Sizes.  From my discussions with suppliers few if any hold the practices minimum selling unit information which is necessary for automatic price updates(i.e supplier sells in minimum selling unit of box of 24 vials  - pack size = 1, practice minimum selling unit is vials so pack size = 24).  Often this information is held in the products reorder description but this is difficult if not impossible to extract from the text. 


  • No need for mass catalogue updates which may include many products not used buy the practice.
  • No need for locked product lists.
  • Ability to get on the fly updates and price changes.
  • Additional information cna be provided such as specials, usage notes, etc.


 Electronic ordering has been used in the vet industry for some time.  Various software systems have implemented various ways to acheive this but in general it involves generating a proprietary file format and sending this to the supplier for processing.  Pretty straight forward and common approach which we could emulate.

The problem is this represents only a part of the ordering process. What happens if the supplier gets the order and can't supply a product or finds the practice has used an old product code etc.  Essentially the supplier goes through an order validation process that can often be manual and require some interaction with the practice.  Can we supply this instead ?  Did you mean 10 boxes or 10 tubes ? etc

At the end of this validation process the order can be modified, rejected or accepted as it is. The issue is how do we communicate these changes electronically between the two parties involved.  If this is a manual process .. i.e I will change this on my system just make sure you change the same things on your system so we agree, errors can occur.  What thsi can mean is one system may think a product is on back order where the other does not affecting subsequent orders.  

Any electronic ordering system must cater for this by supporting order cancellation and changes from both sides and electronic order acceptance responses so both parties know that the oorder content has been agreed.

So the simplest case woudl be a practice sends an order  and after validating the order the supplier sends a response back saying the order has been accepted in full.

Another scenario is the supplier receives the order and rejects it completely based on inabaility to supply.  The sending practices system should receive this reponse and indicate the order has been rejected in the ordering workspace.

 A more complicated scenario is the supplier receives the order and modifie sit it suggest alternative products (may or may not be based on some human communication between supplier and customer) and sends a response with the suggested changes back to the practice which then have the opportunity to accept, reject or modify the order.

Another scenario is a request to cancel can be sent from the practice to the supplier. 

We envisage the OpenVPMS ordering workspace would be modified to reflect the various status's of the order through the process as well as to sedn and reciev the various responses.

 Of course if a supplier doesn't support the additional electronic messages involved they can only send back simple acceptance and rejection messages.


This is the process by which an accepted order is furfilled and dispatched to the customer.  many of th eprocesses here ar enot specific to the vet practice but ar eused to communicate electronically to the transport/dispatch companies.  

One process that may be required is the sending of dispatch advices from the supplier to the practice.  Essentially this is a electronic delivery docket indicating this is what has been sent to you.  This can be used by the

practice to cross check the products actually delivered and to return a receipt advice back to the supplier indicating acceptance of the deleivery or providing information about discrepancies or damaged goods.

I am not sure how many suppliers utilise this approach or just dispatch the goods with an invoice which acts as a dispatch advice and invoice in one.  Despite this the proces sof being able to indicate non delivered or damaged goods seems a worthwhile one but may need more discussion.

Some form a advice will be required to indicate delivery so orders can be marked delivered in OpenVPMS and back orders managed.

In regards some of the issues raised concerning hwo to match deliveries against orders it is important to note that OpenVPMS can cope with deliveries of the same product against mutliple orders and maintains an ordered quantity, deleivered quantity and cancelled quantity against each product ordered.  This is how it works out what is on back order.

The issue for some suppliers is when an ordered product goeson back order it can often lose the reference to the original order in the suppliers system which means when it is eventually delivered the electronic advice has no reference to an order for OpenVPMS to update the delivered quantity.  I would suggest this is a supplier issue that needs to be addressed in order for any electronic system to work.


Once everyone agrees with what has been delivered the ability to send an electronic invoice and or credit note for returned goods is required.  As mentioned above this may also be used as a dispatch advice so may include the same processes such as sending  receipt advices indicating inconsistencies in delivery and initiating credit notes etc.

The current process in OpenVPMS is a user can enter a delivery which may include products from multiple orders and then once completed can turn this delivery into an invoice.  I believe this process would remain the same but a delivery may be initiated from an electronic  dispatch advice or invoice.  The former would only create a delivery the later a delivery and an invoice. Alternatively we may ask the supplier to sedn both a deleiveryadvice and invoice which would adhere more to the standards.


As mentioned in a number of posts about this project we believe in using existing standards where available and applicable.  Based on our research the standard most applicable is Unified Business Language (UBL) which is a XML based standard for electronic supply chain communication.  For those who are interested you can find more information about this standard here http://docs.oasis-open.org/ubl/cs-UBL-2.0/UBL-2.0.html.

The standard is very comprehensive and definitely goes beyond our current needs.  As such we would only implement of a fraction of the defined documents and processes.  Here is the initial list of processes and document we would look to implement.

Process UBL Document Description
 Request Catalogue  CatalogueRequest Practice requests product information from supplier  Practice
 Reject Catalogue Request  ApplicationResponse Supplier rejects request for product information.  Supplier
 Accept Catalogue Request  ApplicationResponse Supplier accepts Catalogue Request  Supplier
 Send Catalogue  Catalogue Supplier sends catalogue information  Supplier
 Request Quote  RequestForQuotation Practice requests a quote on one or more supplier products  Practice
 SendQuote  Quotation Supplier sends quotation  Supplier
 Send Order  Order Practice Sends Order  Practice
 Accept Order  OrderResponseSimple Supplier accepts order as is  Supplier
 Reject Order  OrderResponseSimple  Supplier rejects order  Supplier
 Request Order Change  OrderResponse  Supplier Requests change to order  Supplier
 Change Order  OrderChange  Practice Requests change to order  Practice
 Cancel Order  OrderCanellation  Practice Requests cancellation of Order Practice
 Send Dispatch Advice  DespatchAdvice  Supplier sends dispatch advice  Supplier
Send Receipt Advice ReceiptAdvice Practice sends recedipt advice Practice
Send Invoice Invoice Supplier sends invoice to Practice Supplier
Send Credit Note CreditNote Supplier sends credit note to Practice Supplier
Send Account Response ApplicationResponse Practice sends response to Supplier concerning received invoice or credit note Practice




Automatic ordering

Hi everyone,

Thanks Tony for that update. It seems that the process has been very comprehensively thought out.


A query about the exchange that occurs between the supplier and practice when an order is to be modified.

Scenario 1: Say a supplier cant provide 20 of a order item and instead will send 10. Would the supplier have to "Request Order Change" for any change in quantity? Does this mean the practice would need to "approve" the change somehowbefore the order as a whole is actioned? If so how will this sort of notification be handled in OpenVPMS (Messaging/SMS/email)?


Price updating

I might have got this wrong but the list price validation/request in the above model occurs during order item entry? So for example, say the order item entered requests its Catalogue information and it returns that the list price has changed. Will OpenVPMS trigger a prompt to price update at that time?

We foresee that we will have a "working" order that any staff can add too and that the person charged with sending the order validates it prior to being sent (we imagine a new role being created in OpenVPMS for this). Could list price updating/prompting occur at order submission rather then item entry?


Despite most of it being over my head, I think it looks very encouraging. A well thought out methodology based on international standards.


Matt C

Automatic ordering

Hi Matt,

Firstly apologies for site formatting issues.  Seems inclusion of tables on site mucks up page formatting.  We will see if we can rectify as table sometimes handy to display information.

Order Changes.  The process you describe is essentially how it will occur.  As part of the new feature Tim and I discussed including a notifications area to alert users to order change events as well as other events such as messages etc.  The changed order would also be flagged in the order workspace via a different status as in essence it is not finalised yet.

The catalogue/quotation process is used during ordering to provide the correct supplier identifiers and indicative pricing  for the order but does not trigger price change events.  These are triggered during the delivery/invoice process.



Syndicate content