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.

Sourcing

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.

Issues

• 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. 

Benefits

• 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.

Ordering

 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.

Furfilment

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.

Billing

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.

Implementation

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.