Service:posps

Adds a charge/rebate to the charges/rebates of this sale. If there already exists a charge of the given kind in the sale, the amount given is added to the existing amount. If no amount is given, the server is expected to add an amount configured on the server side, e. g. it could calculate shipping charges or use a preset night duty charge.

The person can either be a person already known to the server and referenced by a personId obtained by a person search or a new person with the data supplied by the client. It is up to the server to decide whether it should create a new entry in the server person store for a person supplied by the client. If it thinks the person data matches an existing entry, it might return the corresponding personId instead of creating a new entry.

The role the person plays in the sale depends on from where it is referenced. It might be the customer if it is referenced by setCustomer , a patient if it is referenced by a prescription, or a physician.

The server responds with the updated data model. Usually, it contains a new person element for the person and possibly an updated total entry. If the person with the personId has already been part of the sale, the existing person entry is updated if the person was changed by the operation.

The position describes the sale of an article with a given quantity. The articleId should be taken from an article search. The position can optionally reference a prescription which prescribes the article. After a position was created, the article cannot be changed.

The server creates a new positionId which is used to refer to the position. The positionId is only valid in the context of the current sale.

The server responds with the updated data model. Usually, it contains a new position element for the added position with a newly generated positionId and an updated total entry.

A prescription can be referenced by one or more positions meaning that the position is sold as indicated by the prescription. This can change the price the customer has to pay for the position according to local laws.

The prescription can reference to two person elements - to the patient and the physician.

The server responds with the updated data model. Usually, it contains a new prescription element for the new prescription.

Notification to the server about the payment process selected by the client for this sale. If the payment is canceled (the canceled parameter is true), the payment has been aborted and the customer has been given back his money. Otherwise (an "uncanceled payment"), the client has collected the total amount which the server has specified for this sale and this transaction cannot be undone any more. The client can confirm an arbitrary number of canceled payments, but once an uncanceled payment has been confirmed, there must be no more payment transactions.

After confirmation of an uncanceled payment the server will reject all changes to the sale that would change the total with a IllegalStateFault . If the receipt is to contain information on the payment type (as it is customary done), the payment must be confirmed before createSaleReceipt is called.

Deletes the charge of the given type from the sale.

If pickup is enabled, the client will be allowed to sell articles which it currently cannot deliver. The customer can return later to the pharmacy and pick up the articles which were not delivered. To allow this, createSaleReceipt will usually generate a receipt that contains some pickup information the customer can present to the pharmacist.

If the server allows pickup, it will set the pickup element in the returned data model . If the element is not set, pickup will not be allowed. It is the responsibility of the client to take this into account and to only sell deliverable articles.

The client can try to enable pickup at any time in the sale, as long it is not too late to roll back the transaction if the server does not allow pickup. If pickup is already enabled, the call will be ignored and the server should return an unchanged data model.

If shipment is enabled, the client will be allowed to sell articles which it currently cannot deliver. The pharmacist will send the undelivered articles to the person set by the operation. To disable shipment, pass a nil value for the personId.

If the server allows shipment, it will set the shipment element in the returned data model . If the element is not set, shipment will not be allowed. It is the responsibilty of the client to take this into account and to only sell deliverable articles. Shipment may incur shipping charges, in which case a total element including the charges is returned.

If there is not already a person element for the customer, the server will add it to the sale. Setting the customer is optional, for a simple sale no customer data is needed. If a customer is already set when the operation is called, the old customer will be overwritten with the new one. To delete the customer from the sale, pass a nil value.

The server responds with the updated data model. Usually, it contains a customer entry for the customer who has been set.

Setting the operator of a sale is optional since there is no operator in case of a self-service sale. If an operator is already set when the operation is called, the old operator will be overwritten with the new one. To delete the operator from the sale, pass a nil value.

The server responds with the updated data model. Usually, it contains an operator entry for the operator which has been set.

This is usually the first step when adding an article to a sale. The pharmacist searches for an article, and the articleId of the selected element of the search result is used to add the article to a sale.

If not all elements from the search result are returned, the remaining elements can be requested with getNextSearchResults using the searchResultId returned by this operation.

The server should try to stop the delivery of all packs that have not already been delivered. This will not always be possible since the server may already have sent an order to the robot. Since some articles may still be in delivery, the order can still be incomplete and has to be tracked to await completion. Packs which were not delivered due to the order being aborted are listed as failed articles with reason code aborted .

A call to abort on an already aborted order is ignored.

The server will try to deliver the articles to the output location configured for the client. The operation returns immediately, returning an orderId which the client can use to track the status of the order. The orderId may only be valid for the client that placed the order.

A client may place several orders at the same time that the server should handle in FIFO order. A server implementation should try to handle as many concurrent orders as possible, but if for some reason it currently cannot accept more orders, it raises a TooManyOrdersFault.

The server must guarantee that the article delivered for an articleId matches the data (especially product and price) that the server supplies for a sale position with the same articleId. The details which data must match is dependent on the regulations of the country in which the system is used. The PS must also try as far as possible not to deliver an article that has already expired.

A pickup order may consist of one or more articles. The server is responsible for assigning the pickupOrderId to the packages that have to be delivered. Either the pharmacist pre-packaged the articles into a single package or the PS orders the articles individually from the pharmacy robot. In both cases, the articles should be listed individually in the result to this call.

The server will try to deliver the pack(s) to the output location configured for the client. The operation returns immediately, returning an orderId that the client can use to track the status of the order. The orderId may only be valid for the client that placed the order.

A client may place several orders at the same time that the server should handle in FIFO order. A server implementation should try to handle as many concurrent orders as possible, but if for some reason it currently cannot accept more orders, it raises a TooManyOrdersFault.

If trackOrder is requested with orderId it returns a list with the current order statuses of the ordered packs.

If trackOrder is requested with saleId it returns a list with the current order statuses of all articles from this sale.

The client will poll until all packs of the order/sale have been processed (either delivered or failed).

The server may discard the orderId after the sale is closed or aborted.

Sets the customer-provided code which identifies a pickup order to the server. The customer must have earlier aquired the code by some means not specified by this interface.

The specification does not define how the code is to be generated. To prevent customers from picking up pickup orders that are not meant for them, it should not be easy to guess valid codes. On the other hand, codes should not be too long so that it is not too difficult for the customer to enter it.

Codes not accepted by the server (invalid format, unknown, etc.) are reported by UnknownPickupCodeFault . If the authentication is not accepted, it raises an AuthenticationRejectedFault . If the server accepts a pickup code, it sends back the data model containing the list of articles put together for this pickup, a pickupId with which the client can order the pickup order using the Order port, and possibly customer information with a person element. Once a pickup code is accepted, no further calls to setPickupCode are allowed for this pickup.

Setting the operator of a pickup is optional since there is no operator in case of a self-service sale. If an operator is already set when the operation is called, the old operator will be overwritten with the new one. To delete the operator from the pickup, pass a nil value.

The server responds with the updated the data model. Usually, it contains an operator entry for the operator which has been set.