09/10 Checkin

~The request looks like:

09<No block (Offline)><xact date><return date>[Fields AP,AO,AB,AC,CH,BI]

No Block (Offline): A single character field of Y or N - Offline transactions are not currently supported so send N.

xact date: an 18 character field for the date/time when the checkin occurred. Format: YYYYMMDDZZZZHHMMSS (ZZZZ being zone - 4 blanks when local time, “Z” (3 blanks and a Z) represents UTC(GMT/Zulu)

Fields: See Fields for more details.

The response is a 10 “Checkin Response” with the following:

10<resensitize><magnetic media><alert><xact date>[Fields AO,AB,AQ,AJ,CL,AA,CK,CH,CR,CS,CT,CV,CY,DA,AF,AG]

Example (with a remote hold):

09N20100507    16593720100507    165937APCheckin Bin 5|AOBR1|AB1565921879|ACsip_01|
101YNY20100623    165731AOBR1|AB1565921879|AQBR1|AJPerl 5 desktop reference|CK001|CSQA76.73.P33V76 1996
|CTBR3|CY373827|DANicholas Richard Woodard|CV02|

Here you can see a hold alert for patron CY 373827, named DA Nicholas Richard Woodard, to be picked up at CT “BR3”. Since the transaction is happening at AO “BR1”, the alert type CV is 02 for hold at remote library. The possible values for CV are:


The logic for Evergreen to determine whether the content is magnetic_media comes from either legacy circ scripts or search_config_circ_modifier. The default is non-magnetic. The same is true for media_type (default 001). Evergreen does not populate the collection_code because it does not really have any, but it will provide the call_number where available.

Unlike the item_id (barcode), the title_id is actually a title string, unless the configuration forces the return of the bib ID.

Don’t be confused by the different branches that can show up in the same response line.

  • AO is where the transaction took place,
  • AQ is the “permanent location”, and
  • CT is the destination location (i.e., pickup lib for a hold or target lib for a transfer).