After adding an Alma Item policy in the Configuration->Fulfillment->Physical Fulfillment->Item Policy, the Item Policy Code Table allows you to edit the Code. Existing items records linked to the item policy code are not updated in such an edit. Such items retain the now “orphaned” original item policy code as can be queried in analytics.

To compound this, leading and trailing spaces within an item policy code are considered significant, so an edit to remove a trailing space leaves (invisible to the user) distinct item policies, one of which is broken.

We propose the following three changes:

1.) The Item Policy code table be changed to not allow editing of the item policy code to bring it in-line with other code tables in Alma to avoid “orphaning” item policies. This enforces consistency within the system.

2.) When saving an item policy, the system performs a trim of prefixed and postfixed spaces to the item policy code. This enforces data cleanliness.

3.) Since you can no longer edit the item policy code going forward per #1 above, the removal of an existing item policy should not be allowed until all items associated with item policy have had their item policy changed or removed. This enforces data consistency relating to existing items and ensures removal of unused item policies from items.

We are using the Alma “scan-in” API
/almaws/v1/items?itembarcode={itembarcode}
which redirects to
/almaws/v1/bibs/{mmsid}/holdings/{holdingid}/items/{item_pid}
to print book labels.

Some sublibraries also use call number prefixes or suffixes in some cases.

Please see the following example record:
- Marc21 field 852 in the Holding record
- XML output

(1) Example: Call number with prefix 852 $$k
852 8_ |b XHOG |c XGRY |h G-1234567 |k Präfix

XML output:
item/holdingdata/permanentcallnumber: Präfix G-1234567
item/holdingdata/callnumber: Präfix G-1234567
item/holdingdata/accession_number: G-1234567

item/itemdata/parsedcallnumber:
<parsedcallnumber>
<callno/>
<call_no>Präfix</call_no>
<call_no>G-1234567</call_no>
</parsed_call_number>

(2) Example: Call number with suffix 852 $$m
852 8_ |b XHOG |c XGRY |h G-1234567 |m Suffix

XML output:
item/holdingdata/permanentcallnumber: G-1234567 Suffix
item/holdingdata/callnumber: G-1234567 Suffix
item/holdingdata/accession_number: G-1234567

item/itemdata/parsedcallnumber:
<parsedcallnumber>
<callno>G-1234567</call_no>
<call_no/>
<call_no>Suffix</call_no>
</parsed_call_number>

(3) Example: Call number with prefix 852 $$k and suffix 852 $$m
852 8_ |b XHOG |c XGRY |h G-1234567 |k Präfix |m Suffix

XML output:
item/holdingdata/permanentcallnumber: Präfix G-1234567 Suffix
item/holdingdata/callnumber: Präfix G-1234567 Suffix
item/holdingdata/accession_number: G-1234567

item/itemdata/parsedcallnumber:
<parsedcallnumber>
<callno/>
<call_no>Präfix</call_no>
<call_no>G-1234567</call_no>
<call_no/>
<call_no>Suffix</call_no>
</parsed_call_number>

and after some tests the <parsed_call_number> section looks like this:

<parsed_call_number>
<call_no/>
<call_no>Präfix</call_no>
<call_no>G-1234567</call_no>
<call_no/>
<call_no>Suffix</call_no>
</parsed_call_number>

Conclusion:
- Marc21 subfields 852 $$k and $$m are not listed sperately in the XML :-(
- In <parsed_call_number> section the content of <permanent_call_number> or <call_number> is splitted up into the content of 852 $$k, $$h and $$m. The order of the <call_no> tags is correct (call number prefix / call number / call number suffix) but there are also empty <call_no/> tags.

Please provide us a XML output with Marc21 852 content in seperate fields. The important call number fields for us are:
- 852 $$k ... call number prefix
- 852 $$h ... call number (classification part)
- 852 $$m ... call number suffix
- <accession_number> includes 852 $$h only if the call number has been generated via a call number (accession number) counter.

Other libraries may be interested also in other subfields of Marc21 852:
https://www.loc.gov/marc/holdings/concise/hd852.html
$h - Classification part (NR)
$i - Item part (R)
$j - Shelving control number (NR)
$k - Call number prefix (R)
$l - Shelving form of title (NR)
$m - Call number suffix (R)

Having the content of 852 $$k, $$h and $$m in separate XML fields gives us the possiblity to handle the call number parts in a different way on the book label (if desired).
Having two <call_no> tags in the <parsed_call_number> section is not clear enough. It could mean that you have:
- 852 $$k ... call number prefix / 852 $$h ... call number (classification part)
- or 852 $$h ... call number (classification part) / 852 $$m ... call number suffix

Thank you in advance!

Problem - Database type electronic collections are not getting published to Blacklight in the OAI publishing job. So bibliographic records that have database type electronic collection inventory attached, display as records without inventory in the catalog.

Situation as described by Ex Libris - The OAI publishing profile is designed to publish the BIB record plus the enrichment fields. The Collection enrichment in the profile is for the Digital Collection, not the Electronic collection. The descriptive BIB record does not have Electronic collection as its inventory, the inventory is only Physical/Electronic/Digital. Adding Electronic Collection to the descriptive BIBs would be an enhancement request.

Please add electronic collection to the collection enrichment in the OAI publishing Profile.

As a reference librarian, I would like to 1) see which patron is currently viewing a digital book on the Waiting List tab within the digital representation and 2) have the ability to manage that patron’s session.

Presently, I have the ability to see who is next in line on the patron waitlist, but I can't tell who has the book out now.

From the patron standpoint, they might simply X out of Primo VE, thinking they have finished the book, but it is still out in their name.

This becomes problematic for me as the book is in limbo, no one else can check it out, and I can’t do anything about it.

If I could see who has the book out and have the ability to perhaps even remove that patron from the queue of readers, this would be helpful.

This functionality should mirror print loans where one can find the details of who borrowed a book within Alma and the patron can also see what is checked out to them in their account profile on Primo.

The current Request webhook doesn't seem to include the Request Cancellation reason. Currently it just says:

'event' => {
'desc' => 'Request canceled',
'value' => 'REQUEST_CANCELED'
},

The comment field refers to the request, but not the cancellation reason here:

'userrequest' => {
'requesttime' => '2022-05-11T23:42:26.191Z',
'managedbycirculationdeskcode' => 'EASTCIRC',
'mmsid' => '993815723607636',
'taskname' => 'Rejected',
'author' => 'Ferguson, J.',
'itemid' => '2365452260007636',
'issue' => '',
'pickuplocationlibrary' => 'ABC',
'dateofpublication' => '',
'managedbylibrary' => 'State Library',
'requesttype' => 'HOLD',
'requestid' => '1419991190007636',
'pickuplocation' => 'Redmond Barry Reading Room',
'materialtype' => {
'desc' => 'Book',
'value' => 'BOOK'
},
'requestsubtype' => {
'desc' => 'Patron physical item request',
'value' => 'PATRONPHYSICAL'
},
'volume' => '',
'managedbylibrarycode' => 'ABC',
'part' => '',
'barcode' => '30328504468884',
'expirydate' => '2022-05-19Z',
'description' => undef,
'pickuplocationtype' => 'CIRCULATIONDESK',
'comment' => undef,
'userprimaryid' => '12345678',
'pickuplocationcirculationdesk' => 'DEFAULTCIRCDESK',
'managedbycirculationdesk' => 'East Retrieval',
'requeststatus' => 'HISTORY',
'title' => 'Life.',
'requestdate' => '2022-05-12Z',
'additional_id' => '141-999-119'
}

It would be nice to be able to roll just a set of of orders, not individual POLs, or specific types of POLs. In our case, we have two libraries that prefer to have their orders rolled over on encumbrance, and the remainder on expenditure plus an FPC factor. We tried doing this this year by separately rolling the specific library's ledger and then associated POLs, but it took days. I think the issue is that it is trying and failing to roll every other active POL, and then just failing on those that do not yet have active funds.
Being able to roll this set of POLs over first would be much more effective.