Transaction management includes all tasks which involve moving a unit from or to a collection or subcollection. This includes loans, permanent loans, gifts (also in exchanges), staff collections, and purchase or sale of units. The data structure supports the tracking of units, reminders, statistics, etc. which are to be implemented by the application program.
The Transfer Event (see Diagram 21) includes the data of the actual shipping and receipt of the material. A single transfer event may handle a mixture of sent and returned or partially returned loans as well as permanently transferred materials. The de-facto many-to-many relationships with the unit entity is resolved by means of the entity Unit Transfer.
Charges for sending, purchases, handling fees, etc. may accompany the event or even single unit transfers. However, the (super-) entity Accounting Mechanism is not further treated in this model. Fortunately, many collections do not use it; those which do, implement widely differing systems.
Diagram 24: Transaction data for loans and permanent transfers
Permanent transfers include gifts, exchange, purchases, sales, and permanent loans of units. Every permanent transfer of a unit from one collection to another has to trigger a derived unit creation event. Once a unit has been stored in the system, it should remain there. A unit which has been lost, given away, or destroyed is marked respectively (attribute availability, see under Units, Definition) but retains its link to the storage location.
The application software has to ensure that in a transfer event ensemble sets are kept together.
Diagram 24 specifies the data involved in transactions of units. The entity Transfer Event can be visualized as a box containing one to several units, transferred by a carrier from a sender to a recipient. All three are PICOs (see above), which also provides a link to address information. The carrier specifies a transport agency, a broker, or a private person who is assigned temporary responsibility during the transport. The postage charged may be important for accounting purposes. The box is sent and received at a certain date, respectively. Free text notes may be made upon sending it and/or upon receipt, and the receipt may be acknowledged by the recipient.
The Unit Transfer describes the context of the event. We distinguish the following transfer types: staff collection, loan sent, loan received, loan return sent, loan return received, gift or exchange sent, gift or exchange received, purchase received, sale sent, permanent loan sent, and permanent loan received. Permits may be required for the transfer of units. The permit type describes standard permits (e.g. those required by CITES or export permits needed in international transfers). The permit number and the permit description may be used to further specify the permit, which is given by a permit issuing authority. Permanent transfers are usually based on some kind of agreement, e.g. a sales contract or an exchange agreement.
Loans need a number of specific attributes. Institutes generally separate the management of loans received from that of loans sent. However, the data strongly overlap and have therefore not been separated in this model. A requesting person or person team may be recorded. The received loan in-house responsible person may be different from the requesting person. Usually, a deadline is set for the return of the material, and, in case that the deadline was not met by the recipient, reminder letters may be sent. This free text attribute allows to enter references to several reminders, specifying the circumstances and dates. Sender as well as recipient may assign a loan identifier (number or code). Because of the frequent occurrence of partial loan returns, the loan status must be calculated by the application. For each unit transfer with type "loan sent" a corresponding unit transfer with type "loan sent returned" must be present. The loan completely returned flag is a calculated attribute included to simplify management of loan data.
In a derived unit creation event, the unit becomes a unit assigned to the new owner (and receives an accession code etc.). For permanent international transfers an export permit is required by many countries. For the export and import of protected species, a CITES permit is required by international law. In an implementation, these attributes may take the form of a link to a correspondence filing system.
Usually herbarium exchange programs are not related to single units but an agreement exists to exchange a certain number of units within a time period. Such an agreement can therefore be controlled by the application, comparing the number of items send as gift and received as gift. No additional data elements are necessary.
In exchange and loan transactions the intra-institutional responsibility for certain groups of organisms may be important. This should be recorded where needed in a table which is linked to Taxon and Unit (via the preferred determination or the attribute stored under name).