This document gives an overview of the posps interface design, the functionality and the basic interactions between server and client. After you have read the overview, you should read some examples to get a more detailed look at the interactions. The reference contains a complete guide to the web service operations and data types.
The posps web service defines an interface between a point of sale (POS) and the pharmacy system (PS) backend. The POSs act as clients which access the PS server. The web service is defined by the WSDL document posps.wsdl, which includes the XML schema type definitions in posps.xsd. (The posps-*.xsd schemata define the wrapper elements for the WSDL operation parameters, which have to be defined in separate namespaces.)
The aim of the web service is to reuse the business logic and data storage which already exist in the pharmacy IT systems for new kinds of POSs. A POS which is newly integrated into the pharmacy can thus present the full functionality and knowledge of the already installed pharmacy system for the pharmacist. There is no need to redundantly store and update data across systems and there is no danger of miscalculations due to different business rules implemented in the systems.
The posps web service interface supports two activities: sale and pickup. During a sale, the customer can choose interactively which articles he wants to buy. A pickup allows the customer to collect articles which he ordered earlier, possibly through a web shop, or which were not available when he last visited the pharmacy. The difference is that for a pickup the articles are put together by the pharmacist and are delivered all together or not at all.
The web service assumes the following division of tasks between POS and PS.
The PS
The POS
The diagram shows the use cases which are covered by the sale activity. Requests and searches for articles or persons are usually performed as part of a sale, but this is not required. The sell use case is realized by the operations of the Sale port type, search articles and persons by the Search port type and order articles by the Order port type.
Other functions offered by a PS (such as a sale history, reports, maintenance of the product and person databases, etc.) are not covered by the interface specification. They are expected to be implemented in proprietary PS client software which may be run in parallel with the POS client (but possibly on a different computer system).
The following activity diagram illustrates the workflow and the usual distribution of operations between POS and PS for a sale. It only shows the main operations.
All activities except calculate prices directly correspond to posps operations. When the POS signals a change in the sale, the PS recalculates the prices of the articles and the total and sends this information back to the POS. Once the POS is sure that there will be no further changes of the positions in the sale, it collects the total calculated by the PS from the customer and confirms the payment. After this point, no change to the sale that would change the positions is allowed.
This example shows the operations carried for a simple sale in which a single article is sold in self-service to a customer. The customer stays anonymous, his data is not recorded.
First, the POS starts a new sale. It searches for the article requested by the customer, takes the ArticleId from the search result and adds a position with the article to the sale. It then lets the customer pay the total which the PS has calculated. After successful payment, the POS orders the sold article from the PS. The POS tracks the delivery status, and once the article has reached the POS, it is handed over to the customer. The POS updates the delivery status of the position, confirms the payment, asks the PS to create the receipt data and prints it. Finally, the POS tells the PS that it can close the sale.
In this example, a customer brings a prescription which prescribes a single drug. The customer is served by the pharmacist.
The sales process is started by the POS. It searches for the entry describing the pharmacist who operates the POS and adds it to the sale. When the customer presents a prescription, the POS searches for the patient for whom the prescription is intended in the person database. It adds the person and then creates a prescription that refers to this person. Because the patient is also the customer, the POS sets the same person as customer. It then searches for the prescribed article and adds it to the sale. The pharmacist will want to supervise the delivery of the article before he allows the customer to pay. This is why the POS orders the article before payment. As soon as the article is delivered it updates the position with the delivery state. The POS lets the customer pay the entire amount and acknowledges the payment to the PS. Lastly the receipt is printed and the sale is closed.
The pickup use cases are similar to the ones of the sale activity. The pickup use case is realized by the operations of the Pickup port type, search for persons by the Search port type and request pickup order by the Order port type. Since the articles of a pickup are put together earlier, there usually is no need to search for them (unless the POS wants do display additional article information only available through the search).
The following activity diagram illustrates the workflow of a typical pickup. It only shows the main operations.
All activities except list articles directly correspond to posps operations. When the POS sends the pickup code entered by the customer, the PS sends the list of articles which belong to this pickup order to the POS.
The sequence diagram illustrates the operations carried out for a simple self-service pickup.
The POS starts the pickup process when requested by the customer. The customer enters his pickup code (which he has aquired earlier by some mechanism not specified in the interface), which the POS sends to the PS by a call to setPickupCode. The PS responds with the information of the articles belonging to the pickup and the price the customer has to pay (if he has not already paid when aquiring the pickup code). The POS lets the customer pay and then confirms the payment to the PS. After successful payment, the POS orders the pickup order and tracks the order until all articles belonging to the pickup order are delivered. It then dispenses the articles to the customer and confirms delivery and payment. Afterwards it asks the PS to create the receipt, prints it, and then closes the pickup.
