Tony De Keizer updated ESCI-1: ------------------------------

Description: This new feature request is based on the web site discussions on Automatic ordering interfaces. http://www.openvpms.org/project/orders-module-automatic-interaction Each of these features will be delivered in stages according to OpenVPMS community priorities and funding. As features are defined and specified they will be created and linked to this primary feature request which will then be elaborated, and developed as independent development projects.

To summarise this feature will allow electronic communication of supply chain documents between practices utilising OpenVPMS and their supply chain partners. These partners are typically veterinary wholesalers but this feature does not preclude supply chain communication with any business entity.

The scope of this feature is limited to four(4) main areas of communication.

1. Sourcing. The exchange of documents concerning product information and pricing. This includes catalogues and quotations. 2. Ordering. The exchange of documents relating to ordering. This includes orders, order responses, order cancellations and changes. 3. Fulfillment. The exchange of documents relating to the delivery of ordered goods. This includes delivery and receipt notifications and responses. 4. Billing. The exchange of financial documents relating to delivered goods. This includes invoice and credit documents.

Based on our technical discussions the key architecture principles for this feature are:

1. UBL. Use of the Universal Business Language (UBL) as the basis for all business documents being exchanged. 2. SOAP. Simple Object Access Protocol (SOAP) based web services. 3. Security. Use of security standards such as ws-security. 4. Supplier Independence. The architecture will be independent from any specific supply chain partner implementation. 5. Open Source. The solution will utilise open source standards and software. 6. Extensible. The architecture will be implemented in a plugin based structure to facilitate extension by external organisations. 7. Deployment. The architecture will facilitate minimal deployment complexity from both the customer and supplier perspective. 8. Testing. The development project will provide testing tools and processes to assist external development teams to build suitable interfaces into their systems.

It is envisioned that each supply partner will need to provide a level of client side interface software to facilitate communication between the OpenVPMS interface and with their existing electronic ordering systems. This interface software would need to perform the necessary document transforms to and from the defined UBL format. They may also need to transform the incoming web service based requests to their own communication standard (email, ftp, SOAP,REST etc). This development work is outside the scope of this project.

OpenVPMS will define and develop the required interface classes and a default implementation of the interfaces. The default implementation will also support:

1. UBL. Documents as defined by each feature component linked to this project. 2. Services. Incoming and Outgoing SOAP service definitions including the relevant wsdl documents specified for each feature component. 3. Polling Services. A polling service to allow OpenVPMS to initiate incoming communicate with the supply chain partner. We believe this will greatly simplify deployment as each supplier will not need to build client side polling solutions and/or setup per customer SOAP URL's with the subsequent technical issues of firewall setup etc. 4. Asynchronous and Synchronous Messaging. This will allow suppliers to provide instant message responses and/or if their internal processes require manual or extended verification of requests allow responses to be sent independent of the request either directly from the supplier or when polled by the customer. 5. Message queue management. This will provide a mechanism to properly manage message delivery despite potential transient communication issues. 6. Notifications. Incoming and Outgoing message notification management to provide feedback to OpenVPMS application users of incoming messages and message delivery issues.

The current tasks and priorities associated with this project are as follows.

1. Specify the simple ordering interface (Order submission and simple responses) including UBL document standards and examples. 2. Develop simple order interface and implementation. 3. Develop a test order client application to allow interface developers to simulate order generation and responses. 4. Integrate simple order interface with OpenVPMS application 5. Specify invoicing interface including UBL document standards and examples. 6. Develop invoice interface and implementation 7. Develop a test invoice client application. 8. Integrate invoice interface with OpenVPMS application.

Once these have been completed we can move forward on extending the interface to support additional ordering, fulfillment, billing and sourcing use cases.

was: This new feature request is based on the web site discussions on Automatic ordering interfaces. http://www.openvpms.org/project/orders-module-automatic-interaction Each of these features will be delivered in stages according to OpenVPMS community priorities and funding. As features are defined and specified they will be created and linked to this primary feature request which will then be elaborated, and developed as independent development projects.

To summarise this feature will allow electronic communication of supply chain documents between practices utilising OpenVPMS and their supply chain partners. These partners are typically veterinary wholesalers but this feature does not preclude supply chain communication with any business entity.

The scope of this feature is limited to four(4) main areas of communication.

1. Sourcing. The exchange of documents concerning product information and pricing. This includes catalogues and quotations. 2. Ordering. The exchange of documents relating to ordering. This includes orders, order responses, order cancellations and changes. 3. Fulfillment. The exchange of documents relating to the delivery of ordered goods. This includes delivery and receipt notifications and responses. 4. Billing. The exchange of financial documents relating to delivered goods. This includes invoice and credit documents.

Based on our technical discussions the key architecture principles for this feature are:

1. UBL. Use of the Universal Business Language (UBL) as the basis for all business documents being exchanged. 2. SOAP. Simple Object Access Protocol (SOAP) based web services. 3. Security. Use of security standards such as ws-security. 4. Supplier Independence. The architecture will be independent from any specific supply chain partner implementation. 5. Open Source. The solution will utilise open source standards and software. 6. Extensible. The architecture will be implemented in a plugin based structure to facilitate extension by external organisations. 7. Deployment. The architecture will facilitate minimal deployment complexity from both the customer and supplier perspective. 8. Testing. The development project will provide testing tools and processes to assist external development teams to build suitable interfaces into their systems.

It is envisioned that each supply partner will need to provide a level of client side interface software to facilitate communication between the OpenVPMS interface and with their existing electronic ordering systems. This interface software would need to perform the necessary document transforms to and from the defined UBL format. They may also need to transform the incoming web service based requests to their own communication standard (email, ftp, SOAP,REST etc). This development work is outside the scope of this project.

OpenVPMS will define and develop the required interface classes and a default implementation of the interfaces. The default implementation will also support:

1. UBL. Documents as defined by each feature component linked to this project. 2. Services. Incoming and Outgoing SOAP service definitions including the relevant wsdl documents specified for each feature component. 3. Polling Services. A polling service to allow OpenVPMS to initiate incoming communicate with the supply chain partner. We believe this will greatly simplify deployment as each supplier will not need to build client side polling solutions and/or setup per customer SOAP URL's with the subsequent technical issues of firewall setup etc. 4. Asynchronous and Synchronous Messaging. This will allow suppliers to provide instant message responses and/or if their internal processes require manual or extended verification of requests allow responses to be sent independent of the request either directly from the supplier or when polled by the customer. 5. Message queue management. This will provide a mechanism to properly manage message delivery despite potential transient communication issues. 6. Notifications. Incoming and Outgoing message notification management to provide feedback to OpenVPMS application users of incoming messages and message delivery issues.

The current tasks and priorities associated with this project are as follows.

1. Specify the simple ordering interface (Order submission and simple responses) including UBL document standards and examples. 2. Develop simple order interface and implementation. 3. Develop a test order client application to allow interface developers to simulate order generation and responses. 4. Integrate simple order interface with OpenVPMS application

Once these have been completed we can move forward on extending the interface to support additional ordering, fulfillment, billing and sourcing use cases.

-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://openvpms.atlassian.net/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________ OpenVPMS Developers Mailing List developers@lists.openvpms.org To unsubscribe or change your subscription visit: http://lists.openvpms.org/listinfo/developers Posts from this mailing list can be viewed online and replied to in the OpenVPMS Developer's forum- http://tinyurl.com/openvdf