|
Facilitate the replay of circulation transactions recorded whilst the OLIB system was offline.
This is made possible via an Import Batch with a new type - "Offline Circulation". To replay the transactions, one or more comma or tab separated sets of records should be attached to the Import Batch, as follows:
| Field name |
說明 |
| Timestamp |
The date and time of the transaction. The default for the format of this date is: YYYY-MM-DD HH24:MI:SS.
An alternative date format can be supplied in the first record in each file, for example: "DD/MM/YYYY HH24:MI:SS".
|
| Transaction type |
This should be one of the reference data keys for circulation transaction types that are appropriate for this activity.
Not all types are handled by this process (such as loan transfer, in transit, automatic renewal). It is anticipated that most fo the transactions will be:
ISS - For Issue. If the item is already on loan to that user, this will be converted to a renewal.
RET - For Return.
NON - For Non-Loan return
This data is processed via a Reference Data mapping lookup. This means that any invalid entries here can be converted to their appropriate valid entries before the transaction is passed to the circulation system. For example, if the incoming data stated "issue", this could be mapped to ISS.
|
| Users' barcode |
The identifier for the user. This is normally the barcode but could be their Secondary Code or Identification - just as is recognized on the Circulation Desk.
The user barcode is not required on every record if either the same user is applicable for the transaction or no user is required for the transaction.
|
| Copy barcode |
The barcode of the item involved in the transaction. This value is mandatory. |
| 位置 |
The location code for the OLIB Location carrying out the transaction.
This data is processed via a Reference Data mapping lookup. This means that any invalid entries here can be converted to their appropriate valid entries before the transaction is passed to the circulation system. For example, if the incoming data stated "abbrd", this could be mapped to "ABBEY" for "Abbey Road".
This is primarily required as it's not possible to verify the location code while OLIB is offline.
|
A sample Microsoft Excel spreadsheet can be supplied which will gather the required data. This should be made available to the libraries for emergency usage if required ahead of, for example, network downtime.
The transaction file can be supplied to the system administrator for processing once OLIB service is restored. The system administrator should ensure that the Excel sheet is saved as a csv file, ensuring that the date and time are included in the transaction field. This is done by using the "CSV (Comma delimited) (*.csv)" format but may not behave as required when using other formats.
The files can be uploaded to the Import Batch individually or can be zipped together and uploaded as one binary file. If zipped, the Import Batch must be saved before the Decompress action is called. This will then extract the individual files and attach them as Objects to the Import Batch. These will be given a status of "Ready to Load", indicating that they are ready for Pre-Processing.
Alternatively, the data can be pasted from Excel into a new field available on the Objects record - "Pasted Content (ob_content)". This, and its corresponding "Upload Pasted Content" button, will need to be added to the Objects layout by the system administrator. Once pasted, the "Upload Pasted Content" button is used to store the content in the database.
Once all of the transaction files are uploaded (and, if necessary, decompressed) the files must be Pre-Processed. This will created a merged Object on the Import Batch and populate the Reference Data Mappings. The merged Object will have the standard date-time format, listing the transactions in chronological order and the user barcode will be copied to each line as required.
It is recommended that the email fields (on the second sheet) be completed prior to the final stage of processing the data. The email received will list the failed transactions at the top, following by a dividing line and then the successful transactions.
Checking will be carried out before transactions are attempted, including:
- If the copy record is locked (e.g. in modify mode) or not found
- If the user record is locked or not found and required for the transaction
- If the copy record has a physical transaction that occurred after the date/time given in the file being loaded
- If the date/time for the transaction is in the future, this will be rejected and may be a data error (e.g. 15-Feb-2202 10:30)
- If the date/time for the transaction is over 10 years in the past, this is likely to be a data error (e.g. 15-Feb-0022 10:30)
If a transaction cannot proceed or fails when attempted, a trap will be added to the copy record (or user record if no copy was found) unless the copy/user record was locked. If the copy record and the user record are both unidentified, this will be reported in the email and in the transaction log attached to the import batch.
Once the Reference Data Mappings are verified, the merged object can be loaded.
|
