Description dialogs for SIP2

Dialog 41/42: View unpaid registrations

Request: field FA of FB of FC should contain a Y (for example FBY). Registrations with invoice status J are sent as well. The machine can decide whether it should show it or not. Also added to the response are the:

• Description of the item
• Status: I=invoice, D=debt collection, R=payment arrangement
• Debt collection date, dd-mm-yyyy (with status D)
• Unique identifier of the item: adm_id
•  Item type (1-contribution, 2-fines/contribution etc., 3-sales, 4-cash receipts, 6-theater)
•  Date payment arrangement. Items with a filled date don’t have to be paid (with status R).

Fields are separated by a tilde instead of a dash.

Field           1         2    3       4         5     6        7       8   9  10

YZ-line:   14-03-2004 ~ Boete ~ ~ 10-03-2004 ~ 0.30 ~ ID ~ 01-10-2008 ~ 10 ~1~ - -

Structure:

Field	Description
Field 1	Creation date of item
Field 2	Description of item
Field 3	Title or description of journal entry code.
Field 4	Date on which calculations are based (e.g. return date of the item)
Field 5	Amount
Field 6	Status: I=invoice, D=debt collection) Whether the registration is debt collected or if the registration will be paid by invoice. If there are unpaid membership fees, then the invoice status will be shown (when it's configured for a customer that an invoice authorization has been extended for collecting the membership fee).
Field 7	Date on which the registration is sent to the debt collector.
Field 8	Unique ID of the registration (can be used to pay registration)
Field 9	Type
Field 10	Date payment arrangement.

Dialog 41/42: Show paid registrations

Fields are separated by a tilde instead of a dash.

YZ-line: 01-11-2009 ~ Registrations ~ 0.40 ~ Cash ~ Description

Dialog 37/38: Pay open registrations

Added: multiple id’s in field fee_identifier (CG), separated by '+'
CG<id>+<id>+<id>+

Example: CG2500+417+312+

These registrations are paid first. If there is money left, it will be added to the deposit of the patron.

Added: field ‘FX’
This field can be used to gather the payments in such a way that the payments can be linked to the correct journal. It’s a five-digit number and it is the SIP2 client's responsibility to provide Wise with this number. This number is generated by the SIP client. A SIP2 client can, for example, use a session number for each patron/day.
 

This number needs to be provided when increasing the deposit and when paying for fines and fees.

Example:
A patron has two outstanding fees, both 1.25. The IDs of these fees are 464305 and 464306 (obtained by dialogue 41/42)

3720200117     1347060100EURBV1.25|AOWise|AA28340011105903|AC|AD|CG|BK|FX12345|FC1.25|AY1AZEAD4
3720200117     1347060101EURBV1.25|AOWise|AA28340011105903|AC|AD|CG|BK|FX12345|FC1.25|AY1AZEAD4
3720200117     1347060109EURBV2.50|AOWise|AA28340011105903|AC|AD|CG464305+464306+|BK|FX12345|FB2.50| AY1AZEAD4

Line 1: make deposit of 1.25. The payment type is cash (paymenttype 00), identification number is 12345 (field FX)
Line 2: make deposit of 1.25. The payment type is bank (paymenttype 01), identification number is 12345 (field FX)
Line 3: pay fees with id’s 464305 and 464306 using deposit (paymenttype 09) and make use of the deposit, done under identification number 12345 (field FX)

What happens in Wise:
Financial record 464305 will be closed and registered in journal Knnn
Financial record 464306 will be closed and registered in journal (Bnnn)

The temporary financial records (the added deposit) will be removed from the database. This is done to make sure they won’t affect the journal anymore. This method only works for deposits on the same day.

If the SIP2 client doesn’t supply the IDs, Wise will automatically start writing off the oldest outstanding items until all credit of the patron is used. The IDs of outstanding items can be obtained with dialogue 41/42.

Dialog 63/64: View patron information

If the field FW has the value B, it will be interpreted as retrieving patron information for a payment terminal. In that case, the action won’t be cancelled if the patron has too many registrations. The following fields are sent besides the regular fields.

• Field FN: full patron name
• Field FM: card numbers for other patrons that the patron can pay registrations for.
• Field FO: username of the patron
• Field FU: statistical category of the patron, supplied if BETAAL or MAKEN_BOEKINGEN license is configured.
• Field LF: birthdate as yyyymmdd
• Field AK: for each loaned item: item number, name and return date (as dd-mm-yyyy). example: AK10000021028319 De Terugkeer – 22-03-2012|

For payment terminals with a SIP2+-license, the field FM contains the card numbers of other patrons that the current patron is permitted to pay registrations for. This requires LIC_MACHTIGING to be configured, and the patron needs to be authorized for payment. Card numbers of main/extra subscriptions will also be sent in this dialog.

Increasing and using credits

Request payments

This extension is used for viewing payments. The payments are counted per date-type-payment method. Here the payments are counted for the same type and same payment method. This dialog can also be used to get an overview of unpaid registrations.

Dialogs: 41/42

Request
41<transaction date><Patron Identifier><Date from><Date To><Payment Method Type><Debt type>

The message needs to be closed with a sequence number and a checksum.

Field	Code	Format
Transaction date		Length of 18, required: YYYYMMDDZZZZHHMMSS
Patron Identifier	AA	Variable length, required.
Payment Method Type	FI	Length of 2, numerical, 00 – cash, 01 – visa, 02 – credit card, 03 – chipknip, 09 – deposit.
Date From	FJ	Required. Date from. The shown registrations are handled on or after this date. Format: dd-mm-jjjj
Date To	FK	Required. Date to. The shown registrations should be handled before or on this date. Format: dd-mm-yyyy
Debt type	FA FB FC FD FG	Which types should be shown. FA – Contributions, FB – registrations, FC – Deposit. 0, 1 or more can be shown in this dialog. If omitted, all types are shown. Using field FD, only unpaid registrations will be shown. If FA, FB or FC are added, these will be ignored. Field FG will only show the open amount of punches. This can’t be used in combination with other codes.

Patron passwords are not used; these happen in dialog 63/64.
Field FD determines whether it concerns a 'debt' overview or not. If this is the case, use of Payment Method Type is not relevant and will be ignored.

Response
42[<YZmessage>|]
The non-existing field identifier YZ will be used here.

The response consists of one or more lines with the following structure:
YZDate ~ Type ~ Amount ~ Payment method|

Type can consist of:
Membership fee, registrations, deposit. This can be requested with the field ‘Debt. Type’ in the request. These cannot be requested together.

Payment method can be one of the following: cash, chip, bank (credit card).

Example request, show payments
4120091116 091000AA29444000001179|FJ01-11-2009|FK30-11-2009|FI00|FAY|AY3AZE1EF
or
4120091116 091000AA29444000001179|FJ01-11-2009|FK30-11-2009|FI00|FBY|AY3AZE1EF
or
4120091116 091000AA29444000001179|FJ01-11-2009|FK30-11-2009|FI00|FCY|AY3AZE1EF

Dialog 41
Transaction date: 16-11-2009 (09:10:00)
Patron-id: 29444000001179
Date from: 01-11-2009
Date to: 30-11-2009
Payment type: 00 (00-cash,01-visa,02-creditcard,03-chipknip)
Debt type: Membership fee or registrations or deposit
Tracking number dialog: 3
Checksum: AZE1EF

Example response
42YZ01-11-2009 ~ Registration ~ 10.00 ~ Cash ~ <description>|YZ01-11-2009 ~ Contribution ~ 15.00 ~ cash ~ <description>|AY3AZE1EF

Response 42
1st payment: 01-11-2009 ~ Registrations ~ 10.00 ~ Munt ~ description
2nd payment: 01-11-2009 ~ Contribution ~ 15.00 ~ Munt ~ description
Tracking number dialog: 3
Checksum: E1EF (fictional example)

Example request, request unpaid registrations
4120100310 091000AA29444000001179|FJ01-01-2009|FK31-12-2010|FDY|AY3AZE1EF

Dialog 41
Transaction date: 10-03-2010 (09:10:00)
Patron-id: 29444000001179
Date from: 01-01-2009
Date to: 31-12-2010
Debt type: Unpaid registrations
Tracking number dialog: 3
Checksum: AZE1EF

Example response
42YZ01-12-2009 ~ Adult 4155 E ~ Subscription ~ 01-01-2010 ~ 41.00 ~ J ~ - - ~ 382 ~ 1 ~ - -|YZ25-02-2010 ~ Damage ~ ~ 01-01-2010 ~ 4.00 ~ ~ - - ~ 393781 ~ 4 ~ 01-04-2010|YZ05-03-2010 ~ Replaced card ~ ~ 05-03-2010 ~ 3.00 ~ ~ - - ~ 393831 ~ 2 ~ - -|AY0

Dialog 42
1st line : 01-12-2009 ~ Adult 4155 E ~ ~ 01-01-2010 ~ 41.00 ~ J ~ - - ~ 382 ~ 1 ~ - -

field 1: 01-12-2009:   creation date registration
field 2: Adult 4155 E : description registration
field 3: <empty> : title (empty for membership rules)
field 4: 01-01-2010 : start date membership
field 5: 41.00  : amount
field 6: Y  : will be collected by automatic invoice
field 7: - -   : date sent to debt collector
field 8: 382 : identifier
field 9: 1  : type of payment, see below for definitions
field 10:  - - : date for payment regulation, does not have to be paid before this date

2nd line  : 25-02-2010 ~ Damage ~ ~ 01-01-2010 ~ 4.00 ~ ~ - - ~ 393781 ~ 4 ~ 01-04-2010
3rd line  : 05-03-2010 ~ Replaced card ~ ~ 05-03-2010 ~ 3.00 ~ ~ - - ~ 393831 ~ 2 ~ - -

Tracking number dialog : 0

Types of payment:

1	Membership fees
2	Registrations
3	Store Sales
4	Other revenue

Example request, request punches
4120091116 091000AA20105000000011|FGY|AY3AZE1EF

Dialog 41
Transaction date: 16-11-2009 (09:10:00)
Patron-id: 20105000000011
Debt type: Punches
Tracking number dialog: 3
Checksum: AZE1EF

Example response
42FGBookpunches~35|FGPunches-2~75|FGPunches3~Ransomed|AY3AZE1EF

Dialog 42
1st line: Book punches, 35 times
2nd line: Punches3, 75
3rd line: Punches3, ransomed
Tracking number dialog: 3
Checksum: E1EF (fake)

Punches

Request possibilities for punch purchase, dialog Y1/Y2
Dialog Y1 can be used to request the purchasable types of punches. The dialog should show the patron number and the punches.

Request: Y1
Y120091116 091000AA20105000000011|AY3AZE1EF

Field AA contains the patron number.

Response:
Y21[FGType ~ Code ~ Description ~ Amount ~ Price|]AF<Text>|seq.n0

If the request could not be processed, the status is 0 (Y20).

Request to purchase punches, Dialog Y3/Y4
Request Y3

Example:
Y320161116 091000AA20105000000011|FG01-40-15.75-4810 ~ 02-35-13.25-4810|FI00|AY0000
Field AA contains: patron number
Field FG contains: type - amount - price - journal entry code
Field FI: payment type

The various items are separated by a tilde.

  Attention: the type of punch card originates from dialog Y1. There, it contains a description that can be shown in the dialog.

 Response:
Y4[1/0]AF<notifications>
1=ok, 0 = not ok, field AF contains an explanation.

Double loan period

Field FE in dialog 11 can only be used to indicate that the patron would like a double loan period, the value must be Y. This can be used for checking out and renewing (dialog 11 and 29 respectively).

Request family members

Dialog 63/64 is extended with field FM. This field contains the (main) card number, name, unpaid membership fees, unpaid registrations and open deposits.

The structure is:
[FM<patron number> ~ <name> ~ <contribution> ~ <registrations> ~ <deposit>|]

Request/save username

Dialog X1/X2 can be used to register the username of an anonymous patron.

The structure is:
X1<FO<username>|AA<patron number>|AD<pin code>

Example:
X1FPjan12345|AA20105000000011|AD1234

Response:
X2<status>|AA<patron number>|FO<username>|AF<text>

Status:
0 – Ok
1 – Not ok

Which licenses are activated?

Dialog 98 shows which licenses are activated for the SIP2 client:
98YYYYYY30000320110201 1138402.00AO|BXYYYYYYNYYYYNNNYY|AMBibl.Test|GGLIC_SORTEER / LIC_BETAAL / LIC_MAKEN_BOEKINGEN / LIC_VERLENGMOGELIJKHEDEN|AFWelcome <machine>|AY1AZD052

The machine in the example has the following licenses activated:

• SORTEER
• BETAAL
• MAKEN_BOEKINGEN
• VERLENGMOGELIJKHEDEN

SIP2+

Besides the options above, a supplier can activate the following options using SIP2+ (suppliers can request SIP2+ by contacting busdev@oclc.org):

• Selling of depreciated items: when checking out a depreciated item, it is possible to sell it to the patron.
• When the patron checks out an already borrowed item, ask to confirm whether the patron wants to borrow the item again.
• Confirm that items have an attachment.
• Confirm items are damaged.

In the cases above, the patron must confirm something before the loan/sale will be processed. These notifications are shown in field FV. By assigning this field in the request with the value Y, the confirmation will be processed.

The system option LEENHIS must be set before the machine can show the previously loaned items. Wise can indicate the support for each port (machine).

If the SIP+ license is not activated:

• Depreciated items cannot be sold
• Field FV contains the date when the patron has previously borrowed the item. The loan is already processed by then.
• Materials with an attachment are loaned as set in the settings of Wise. Either way, the loan is already processed then.
• Damaged items are able to be loaned.

Example:

Without confirmation:
11YN20110905 09301320110905 093013|AO|AA28340011105903|AB10000021028319|BON|BIN|AY1

Response:
120NNN20110905 092633AOBibl.8340|AA28340011105903|AB10000021028319|AJDe Terugkeer van de dansleraar|AH|BHEUR|BV0.00|BK0|ST0|FVPreviously loaned on: 26-08-2011|AY1

With confirmation:
11YN20110905 09301320110905 093013|AO|AA28340011105903|AB10000021028319|BOY|FVY|BIN|AY1

Response:
121NNY20110905 093013AOBibl.8340|AA28340011105903|AB10000021028319|AJDe Terugkeer van de dansleraar|AH26-09-2011|BHEUR|BV0.10|BK4|ST0|AFUitlening akkoord|AFEUR. 0.10 Leengeld|FQ0337|FQ0342|AGLeengeld|AGEUR. 0.10 Leengeld|AY1

Request renewal possibilities

Dialog 70/71 is available for requesting to renew specific items.

Request:
7020110907 092600|AA28340011105903|AB|AY1

Response:
71GC8340450365719~Het schateiland : een oud verhaal van R.~11-11-2011~12-12-2011~0.00~0.15~0~0.00~|GC8340450371998~Brandt New York?~28-09-2011~26-10-2011~0.00~0.15~0~0.00~|GC8340450372020~Roebels voor de generaal / Tais Teng ; t~25-07-2011~05-10-2011~4.30~0.15~0~0.00~|GC8340450372053~De wraak van Rachwana / Peter Vervloed ;~25-07-2011~05-10-2011~4.30~0.15~0~0.00~|GC8340450372079~Kinderen gezond grootbrengen : wegwijzer~02-05-2011~05-10-2011~7.50~0.15~0~0.00~|FG0|AY1

Fields are separated by a tilde.

Field             1                            2                     3              4         5     6     7     8   9
GC-regel: 8340450365719~Het schateiland : een oud verhaal van R.~11-11-2011 ~ 12-12-2011 ~ 0.00 ~ 0.15 ~ 0 ~ 0.00 ~|

Structure:

Field	Description
Field 1	Item number
Field 2	Title
Field 3	Current return date
Field 4	New return date (if renewing is allowed)
Field 5	Fine if too late
Field 6	Loan costs
Field 7	Punches count
Field 8	Renewal costs
Field 9	Remarks

Processing attachments with SIP2

Wise can process attachments in different ways. Important for this to work:

• For each machine, the self-service settings must be set in Wise (SSS profile).
• Each supplier has different settings for handling attachments.
• Some suppliers can communicate with Wise using SIP2+.
• The way the attachments are registered for an item:
• The main item and attachment have their own RFID-tag
•  The main item contains the number of attachments in its RFID-tag.

Based on the settings and possibilities, attachments are handled in several different ways.

Settings of the machine
The settings differ for each supplier/machine. The following settings can be configured one way or another for each supplier:

• Block checking out / checking in if the item is incomplete according to the RFID-tags.
• Have the patron confirm that the item contains attachments if the RFID-tag of the main item indicates that it should contain multiple attachments. The loan/return is continued based on the answer of the patron.

Self-service settings
In self-service system settings (SSS profile) you can configure the following settings:

• Items with attachments can be borrowed (Y/N)
• Items with attachments can be returned (Y/N)

If the item contains an attachment code in Wise:

Option	Description
N = Not	Wise will block the return.
T = Table	The attachment code table (TABBIJ) contains information regarding whether an attachment can block returning for each different code. If the table returns true for a specific code and the machine supports this functionality (SIP2+), the dialog with the confirmation will be shown. If the machine does not support this functionality or the table returns false, the return will be blocked.
A = Always	An attachment won’t block the return.

Sorting

When checking in items (dialog 9/10), Wise will decide whether the item can be placed back on the shelf immediately or not. If there is a reason when it can’t be placed back immediately, Wise will show this reason in field CL.

01 = Hits
02 = Reservations
03 = Transport
04 = Warehouse / blocked

Items with blocking reasons must always get status D (not-sorted). These items need to be checked in in the Wise Client. When items can be placed back immediately, the item will get the status B (inside) and field CL will have the value 05.

If the library sorts items with status B, the sorting license must be enabled for the specific branch.

Based on the placement in the library, this functionality will determine how this item should be sorted. The values 06 up to and including 99 are available for different sorting deposits. This value will be communicated using the field CL. If this sorting takes place physically, the machine translates this value to the right deposit.

Above is a broad description of the sorting functionality. Besides these possibilities, the following are available as well:

• Determine depositing bin number per item
• Determine the depositing bin number based on the target branch (transport)
• Show additional notifications for each material type.

These possibilities should be discussed with the system administrator.

Handling status D items using smart shelf functionality

Items with a hold that are checked in by a customer using a SIP2 machine receive status D (sorted item). Usually, these items have to be prepared for the hold shelf through the Wise Client. This step can be simplified using the smart shelf functionality.

This functionality allows the items to be placed directly on the smart shelf, which makes them 'hold ready' without having to use the Wise Client. This only applies to items that have been placed on hold in the branch where they were checked out. If the items need to be placed on transport, the smart shelf will decline the items and will show an appropriate error message. You can use this functionality by adding the field DR to the 09 dialog:

• If the field DRY is provided in the SIP2 check-in request, the server will process the hold the same way as when checking in the item through the Wise Client.
• If the field DR is not provided in the SIP2 check-in request, then this will be considered DRN.
• If the field DRN is provided in the SIP2 check-in request, then checking in the item will be processed according to the behavior of the self-service machine.
• You don't need any extra settings,  licenses, or system options for this functionality.