11 Checkout
- Request
- 11
- Response
- 12
- Set
- core
- Position in BX
- 1
Checkout is what a self-checkout unit exists for. The device names patron and item, the library system charges it and answers with the due date.
Only the response decides: As long as the device has not seen 1 in the result
flag, it must not deactivate the item's security and must not print a receipt.
Request 11#
11<renewal policy><no block><timestamp><nb due date><AO...><AA...><AB...>
<AC...><AD...><BO...><XK...><XL...>
| Field | Length | Required | Content |
|---|---|---|---|
| renewal policy | 1 | yes | Y the device may renew if the patron already has the item |
| no block | 1 | yes | Y transaction filed later, see below |
| timestamp | 18 | yes | date and time on the device |
| nb due date | 18 | yes | due date the device assigned in offline operation; otherwise blank |
| Identifier | Required | Content |
|---|---|---|
AO |
yes | institution identifier |
AA |
yes | patron identifier |
AB |
yes | item identifier |
AC |
yes | terminal password |
AD |
no | patron password |
BO |
no | Y the patron has acknowledged a fee |
XK |
no | type of item identifier: BAR, ACC or UID |
XL |
no | type of patron identifier: BAR, ACC or UID |
Transactions without checks#
If the library system fails, a device can carry on provided the
system status
allows it: It remembers the transactions, assigns a due date itself and files
them once it reaches the system again. Such transactions carry Y in "no block"
and the self-assigned date in "nb due date".
The library system books them without further checks: The patron left long ago, the item is out of the building – a refusal would come too late and would only falsify the holdings.
Fee acknowledgement#
If the checkout incurs a fee, the library system first refuses it and states the
amount in BV. The device shows it to the patron; if they agree, it sends the
request again, this time with BO set to Y. Only then is the item charged.
Library systems that do not collect checkout fees at the device charge the item
straight away and ignore BO.
Response 12#
12<ok><renewal ok><magnetic media><desensitize><timestamp><AO...><AA...>
<AB...><AJ...><AH...><AQ...><CK...><BH...><BV...><AF...><AG...><XZ...>
| Field | Length | Required | Content |
|---|---|---|---|
| ok | 1 | yes | 1 charged, 0 not charged |
| renewal ok | 1 | yes | Y the patron already had the item, it was renewed |
| magnetic media | 1 | yes | Y/N magnetic security, U unknown |
| desensitize | 1 | yes | Y the device should deactivate the security, N not, U unknown |
| timestamp | 18 | yes | date and time on the library system |
| Identifier | Required | Content |
|---|---|---|
AO |
yes | institution identifier |
AA |
yes | patron identifier |
AB |
yes | item identifier |
AJ |
yes | short title |
AH |
yes | due date |
AQ |
no | location the item belongs to |
CK |
no | media type |
BH |
no | currency; only together with BV |
BV |
no | fee for this checkout |
AF |
no | message for the screen |
AG |
no | message for the receipt |
XZ |
no | transaction number |
If the library system does not track security technology – the normal case with
RFID, because the device knows it itself – "magnetic media" and "desensitize" are
U. The device then follows its own configuration.
If the checkout is refused (0), AF gives the reason in plain text: blocked
card, limit reached, reference stock, already charged to another patron. The
device shows this text unchanged – it should not phrase its own, because the rule
behind it is known only to the library.
Example#
11YN20260728 14301220260728 143012AOBVS|AA1140360000042|AB1140360000123|ACsecret|XKBAR|XLBAR|AY5AZE694<CR>
121YUU20260728 143012AOBVS|AA1140360000042|AB1140360000123|AJEnde, Michael: Momo|AH25.08.2026|AQCentral library|CK001|AF|AG|XZ12345|AY5AZD992<CR>
Charged (1), no renewal, due on 25 August 2026.