XML Schema Documentation

• Global element and attribute declarations belong to this schema's target namespace.
• By default, local element declarations have no namespace.
• By default, local attribute declarations have no namespace.

Articles are the items which are sold by the POS. The client gets ArticleIds as result of a searchArticle call. It usually uses the ArticleIds in positions it adds to a sale using addPosition and then orders the matching packs to be delivered from the pharmacy robot by calling requestArticles when the sale is processed.

Several different packs stored in the pharmacy robot, which delivers the packs to the client, will usually be referred to by the same ArticleId. The matching of ArticleIds to packs ordered by the client via the Order port type is up to the server (which might leave the decision to the pharmacy robot).

This specification makes no assumptions about ArticleIds other than that ArticleIds used in the Search, Sale, and Order port types refer to equivalent articles. An article delivered for an order is equivalent to the article of a sale position or search result if the delivered pack is the same product and may be sold under the same conditions (e.g. price) that the server has reported for the position or search result entry respectively.

IDs are used to refer to various entities (such as persons, sales, etc.) passed between client and server. For each kind of entity there is a subtype of Id. This helps to avoid accidentally using an ID of type A to refer to an entity of type B, and to avoid clashes if two entities of different types have the same ID code.

IDs are generated by the server. There are no restrictions to the form of an ID other than that the code is of the base type xsd:token . Subtypes of ID make further restrictions on the scope and usage of their particular IDs.

Note: The reason for defining Id as a complex type with a code attribute instead of directly restricting xsd:string is that many wsdl-to-sourcecode translators do not create their own types for schema types derived from simple types, thus preventing compile-time type checking of IDs.

Notes may be generated by the server in reaction to changes of the sale. They are shown to the pharmacist who serves the customer, not the customer himself. It is intended to give additional information based on the knowledge of the server about specific articles, article combinations or the customer's sale history.

A note may reference the positions and the person which it refers to. The client is responsible to bring this reference to the user's attention.

Other than most other ID types, the content of the code attribute is not generated by the server, but chosen by the client. It is only meaningful to the client and sent to the server for documentation purposes.

An OrderId is generated by the server when the client calls the requestArticles operation. It is unique for the client in that the same ID is never used by the server to refer to different orders if used by the same client. It may only be valid for the client that placed the order. If a different client uses the ID the server may raise an UnknownIdFault or interpret it as referring to a different order. The server may invalidate the OrderId if the ID is not used for some time (if, for example, the client has quit unexpectedly and forgotten about the order). In this case, the server must raise an UnknownIdFault if the client uses the ID again. IDs may also become invalid when the client calls certain operations. See the operation documentation for details.

Other than most other ID types, the content of the code attribute is not generated by the server, but chosen by the client. It is only meaningful to the client and sent to the server for documentation purposes.

It is the clients responsibility to collect the amount of money the server has specified in the total element from the customer. When the money is collected, the data of the payment is stored in an element of the type payment. It is not possible to do a partial payment, the sum collected must always be the total sum.

Since there are different ways the money can be collected (cash, card, etc.), Payment is an abstract type. The client will decide which subtype is actually used depending on the payment mode.

Persons can currently appear in the role of customer, patient, or physician. Other roles might be added later. A person may have more than one role depending on the context in which he is referred to. For example, in a sale with a prescription, the customer might also be the patient referred to by the prescription.

A PickupId is generated by the server when the client calls the startPickup operation. It is unique for the client in that the same ID is never used by the server to refer to different pickups if used by the same client. It may only be valid for the client that started the pickup. If a different client uses the ID the server may raise an UnknownIdFault or interpret it as referring to a different pickup. The server must invalidate the ID once the pickup is closed by a call to closePickup and may invalidate it if the ID is not used for some time (if, for example, the client has quit unexpectedly and forgotten about the pickup). In both cases, the server must raise an UnknownIdFault if the client uses the ID again.

A PickupId may be seen as the "Session ID" of a typical web application. The client starts the session with startPickup , and the session is either closed regularly with closePickup or it expires when the ID is not used by the client for some time.

For pickup deliveries the pharmacist puts together the packs belonging to a pickup into a single pickup order. The pickup order is requested through the Order interface as a whole. The PS is responsible for maintaining the pickup orders and matching the pickupOrderIds to packs that have to be ordered.

This ID is used to distinguish between several POSes which are connected to a single PS. If PosIds are used to identify the POS, they are transmitted by the POS in every web service call where the caller identity cannot be derived from another ID.

Other than the other ID types, the content of the code attribute is not generated by the server, but must be previously agreed upon between client and server. It is usually stored in the configuration files.

Note that using the PosId type does not really provide authentication. To securely establish the identity of the client (and server) other mechanisms like TLS on the transport level or WS-Security should be used.