Page Comparison

...

• Create Item Hold received
  • Check item is available, create item hold, create a transaction with received trackingId ; more details on

    Jira Legacy
    server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODINREACH-83

     and 

    Jira Legacy
    server System JiraJIRA columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODINREACH-91

• Check out to Borrowing site will be in new INN Reach UI App (scan barcodes, invoke standard FOLIO Check-out and send Item shipped)
• add about Report Item Received (update transaction status, no updates to local item or loan)
• add about Item in Transit (update transaction status, no updates to local item or loan)
• Check in will be in FOLIO Check-In App (scan barcodes) - mod-inn-reach needs to know about this fact to update its transaction and send Final Item Check-in
  
  • Inventory item status should be changed from Check Out to Available (or In Transit) - and we can track this change; another option - track changes with particular Circulation Request

...

• Assumption: a patron is known on Borrowing site
• Create Patron Hold received
  • Item and instance are not known on Borrowing site, so it's required to create Instance, Holding, Item (using Inventory API) but mark them that they are temporary, and are to be excluded from search; more details on

    Jira Legacy
    server System JiraJIRA columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODINREACH-85

  • When the Patron Hold request originates, the item's barcode is not included in the information provided by the owning site. That information only sent as part of the "Item shipped" message received from the central server by the borrowing site. The barcode should be updated on the "temporary" item record that was created in FOLIO for this transaction (see potential exception(s) below)
• In an ideal workflow, library staff would simply use the existing Check-in app to "receive" shipped INN-Reach items, rather than a dedicated check-in interface in the INN-Reach app (with the options to "receive" an item via the transaction detail action menu), and mod-inn-reach would react to those check-in events and issue the appropriate calls to the central server (eg. "Report Item Received"). One way to accomplish this without significant modification to mod-circulation or ui-checkin might be to set the status on the temporary item records created by the mod-inn-reach to "in process", so that when the item is checked in/received it's status would be updated to "in-transit" or "awaiting pickup" and an inventory update event would be triggered and handled by mod-inn-reach.
  • An exception to this exists if the owning site does not send the item shipped message, in which case staff at the borrowing site need to receive an unshipped item and send the appropriate message back to the central server and update the local item record to include the received barcode (the current plan is for this to take place via the transaction search interface > transaction details > actions menu)
  • Another possible exception to this flow would be a duplicate barcode (i.e. the barcode of the requested item is identical to an existing barcode in the local FOLIO inventory). For now, mod-inn-reach should accept the item shipped message but require the staff to receive the item via the INN-Reach app using the "Receive item" action in the transaction detail for the patron hold. The staff would then be prompted to enter either the barcode with a prefix or suffix or an entirely different barcode altogether.
  • RA: Brooks Travis - it's still unclear to me why we plan using INN Reach UI App for check out but the existing Check-in app for check in? Won't this confuse users?  Just thinking - what if we'll propose new interface for INN Reach related check in / check out as a single point for library staff? Maybe, using INN Reach UI App for check in can be more efficient for handling mentioned exceptions, e.g. it would be possible to add any prefix/postfix. And there would be no need in new statuses in mod-circulation. What drawbacks can be find with the approach with INN Reach UI App for check in?
• The item is either checked out to the patron using the check out app in FOLIO or it expires from the hold shelf
• After item is returned by patron or expires from the hold shelf, it should be checked-in to Borrowing site using the FOLIO Check-in app
  • A borrowed item that is checked in at the borrowing site will be routed to the service point associated with the effective location of the item. When checked in there, an Item in Transit message should be sent to the central server (Item in transit).
    • this can be tracked by item status change in Inventory
  • An item that expires from the hold shelf will trigger a "Return uncirculated item" call to the central server when cleared from the hold shelf via check-in in the FOLIO Check-in app.
• Once Final Item Check-in received (triggered by the owning site receiving the returned item), Borrowing site can remove temporary Instance/Holding/Item from its inventory (??)

...

...

What information should be stored in mod-inn-reach circulation transaction?

...

• mod-circulation / mod-circulation-storage
  
  • Assumption: Circulation API provides all required operations
  • Introduce a domain event streaming into Direct Kafka approach to send events in case of changes (similar to implementation in Inventory)
  • Where to locate this (mod-circulation or mod-circulation-storage)? Agree on Kafka topics naming. Agree on event structure.
  • Note: Volaris - knows Kafka but no experience with Circulation; Vega - best expert in Circulation but not familiar with Kafka; Folijet - implemented Direct Kafka approach for Inventory but no knowledge in Circulation
• mod-inventory / mod-inventory-storage
  
  • Assumption: Inventory API provides all required operations
  • Assumption: no additional functionality is required
• edge-inn-reach
  • implement 32 Circulation endpoints; all the requests are to be proxied to mod-inn-reach
• ui-inn-reach
  • Circulation configuration
  • Owning site Check-out UI - check with BT
  • Borrowing Site Receiving (check-in) UI (needed to handle barcode collisions between INN-Reach items and existing lnventory)
  • Transaction details - list of transaction, their statuses, details etc. - list, filtering, sorting, search, detail view, actions
•  mod-inn-reach
  • Mock D2IR Central Server for testing / verification - not sure if this is required
  • Configure edge-inn-reach endpoint to handle requests from D2IR Central server
  • Create mod-inn-reach service to handle requests from D2IR Central server
  • Implement Kafka consumer for Circulation events (create new consumer)

...