SIP2: Protocol for self-checkout (UXPROD-1001)

[SIP2-123] SIP2: Item Information Response Created: 19/Nov/18  Updated: 23/Feb/23  Resolved: 10/Feb/23

Status: Closed
Project: sip2
Components: None
Affects versions: None
Fix versions: 3.0.0
Parent: SIP2: Protocol for self-checkout

Type: Story Priority: P2
Reporter: Hkaplanian Assignee: Gurleen Kaur1
Resolution: Done Votes: 1
Labels: back-end, q1-2019-spillover
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File RegressionTestOfOtherScenarios.png     PNG File image-2023-01-23-13-01-16-210.png     PNG File image-2023-01-23-13-44-24-220.png     PNG File image-2023-01-31-15-13-27-302.png     PNG File image-2023-02-01-15-34-15-639.png     PNG File image-2023-02-01-15-35-15-671.png     PNG File image-2023-02-01-15-50-11-706.png     PNG File image-2023-02-01-17-02-44-508.png     PNG File image-2023-02-02-08-48-31-108.png    
Issue links:
Continues
continues SIP2-122 SIP2: Item Information Closed
Defines
defines UXPROD-1895 SIP2: Protocol for self-checkout - ad... Closed
Relates
relates to SIP2-140 Spike for SIP2-123 and SIP2-122 Closed
Sprint: Volaris Sprint 157, Volaris Sprint 158
Story Points: 5
Development Team: Volaris
Release: Orchid (R1 2023)
Epic Link: SIP2: Protocol for self-checkout

 Description   

FOLIO must send this message in response to the Item Information message.

Fields not supported:

  • securityMarker
  • recallDate
  • itemProperties


 Comments   
Comment by Magda Zacharska [ 18/Mar/19 ]

18<circulation status><hold queue length><security marker><fee type><transaction date><due date><recall date><hold pickup date><item identifier><title identifier><owner><currency type><fee amount><media type><permanent location><current location><item properties><screen message><print line>

Comment by Magda Zacharska [ 09/Feb/22 ]

Additional use case provided by Bibliotheca:

In this case with the customer we will be demoing for, there is a specific use case.

 

Customer does their checkout. Items are partially processed (ie RFID does not turn off the security bit).

 

When the customer exits the gates alarm, indicating an item has not been checked out. Library staff ask patron to come back empty out their entire bag of books and reprocess all items at a staff desk.

 

With our gates + staffConnect Gate software, the ILS has a connection to the staffConnect gate software. The RFID gates alarm, and then when this occurs, the staffConnect software sends a request to the ILS to do an item information lookup (what is the item matching this barcode). The ILS responds and our software will then display the title of the item that was not processed correctly and the library staff can ask the patron to give them the book title “XYZ” based on what our software is reporting.

 

Similarly, in another use case, if we want to look up a patron account (a function we can do on our selfChecks), there is a request that can be made to provide patrons with item specific information (title, due dates etc).

Comment by Tim Auger [ 08/Nov/22 ]

Flag added

This capability is currently in a community branch and may be merged into the main. See latest comments in SIP2-122 Closed for status.

Comment by Tim Auger [ 13/Dec/22 ]

I think this and SIP2-122 Closed can be combined. Will do.

Comment by Gurleen Kaur1 [ 23/Jan/23 ]

Hi Tim Auger ,

By going through SIP2-122 Closed and SIP2-123 Closed I need some clarity if you could please provide - 

Which command are we discussing about because as per the 3M SIP2 protocol doc there are 2 commands as shown -

 

FYI - Both these commands as of today are not implemented in edge-sip2.

Questions -

  1. Do we have to implement both the commands from scratch or, the code is present in some community branch and will be merged to edge-sip2 master branch ? 
  2. SIP2-122 Closed and SIP2-123 Closed are different in terms of the implementation itself. Please confirm which one is targeted for Orchid or Poppy release ?
  3. Not sure as of now but which API can be invoked to get the corresponding response data for these 2 commands which can be utilized by edge-sip2 to format the message as per 3M SIP2 standards.
Comment by Tim Auger [ 23/Jan/23 ]

Question 1
Gurleen Kaur1 As we discussed today, we only need to implement the 18 type command. The 17 command will come from the selfcheck vendor system.

As noted this morning, we have code from community contributor, Gordon Goldner, that can be used as reference. He has implemented the 18 command and may be of use for our implementation.

Question 2
SIP2-123 Closed is what we want.

Question 3
As we discussed, the 17 command we only need to respond to with the 18. I'll go through the 18 and identify which we need to include values for and which not. As a result, I think this will be much easier to code than thought.  

Comment by Tim Auger [ 28/Jan/23 ]

Gurleen Kaur1 I have inquired with FETech (selfcheck vendor) about what they would expect in the response. I'm waiting but the good news is that they are located in Australia so they are hours ahead of both of us. 

Comment by Tim Auger [ 30/Jan/23 ]

Gurleen Kaur1 I confirmed with FEtech that was they need does not include the:

  • securityMarker
  • recallDate
  • itemProperties

The only question I have is whether or not we are able to get the fines data. 

Comment by Gurleen Kaur1 [ 31/Jan/23 ]

Thanks Tim Auger
But  securityMarker is a mandate filed as per the 3M SIP2 doc as shown below. If the value for any field is null or blank it will be populated with default value as 00 (for security marker 01 means NONE) ?

For your question - "The only question I have is whether or not we are able to get the fines data. " - By fine data do you mean fees? Then, no we are not determining it as fee type is also a mandate filed it will be defaulted to 01 (other/unknown).

Comment by Gurleen Kaur1 [ 01/Feb/23 ]

Hi Tim Auger ,

The code is implemented and the response of item information command would be as highlighted in yellow (shown below) – 

 

In case the item barcode didnt fetch an item record then it will display a message item does not exists as highlighted below in yellow – 

Comment by Tim Auger [ 01/Feb/23 ]

Gurleen Kaur1 Excellent. 

Sorry about the confusion regarding the security marker. Blank or null are correct and 01 (NONE) is not correct. 

Fines are the same as fees. And defaulting to 01 is right. thanks.

 

Comment by Gurleen Kaur1 [ 02/Feb/23 ]

Hi Tim Auger ,
Thanks for the confirmation on security marker field. It will display nothing if there is no value present and it will not display as 01 by default. 
As shown below  after 1808 there is no security marker value and displays BT01 which is fee type value. 

Generated at Fri Feb 09 00:14:45 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.