Closed regineheberlein closed 1 week ago
Box 11 came from ReCAP with a broken handle, which necessitated going through rehousing workflow, even though the new container was the same (record carton). The steps below are what I did for this particular collection:
sc_active_barcodes.csv on lib-sftp did not include 32101103194500 on April 19 (data from April 18), but did include it on April 20 (data from April 19).
Alma has 3 boxes with indicator 11 for C1405: two with barcode 32101103194500 and one with barcode 32101038564793.
SCSB does not have barcode 32101103194500.
C1405 Box 11 in SCSB has barcode 32101038564793.
ASpace has a single top_containers
record with barcode 32101103194500, Last Modified by av2181 2024-04-17 15:07:02 -0400
(no record for barcode 32101038564793).
@amycvo Just making sure I understand the steps. So you went into the top_container record in ASpace and updated the barcode, is that it? And is 32101103194500 the new barcode?
Did you also do anything with the item record in Alma?
And what happened with the old barcode, did you deaccession it from ReCAP? (Just deleting it from ASpace or Alma does not delete it from ReCAP.)
@amycvo Just making sure I understand the steps. So you went into the top_container record in ASpace and updated the barcode, is that it? And is 32101103194500 the new barcode?
Did you also do anything with the item record in Alma?
And what happened with the old barcode, did you deaccession it from ReCAP? (Just deleting it from ASpace or Alma does not delete it from ReCAP.)
@regineheberlein Yes, those were my steps. After I updated Aspace, I gave the box to Mike along with the old barcode so that he could deaccession/withdraw it properly from ReCAP, and create a new box 11 with the new barcode. But I'm not sure what his steps were in Alma.
32101038564793
to 32101103194500
on April 1732101103194500
to Alma on April 1832101103194500
on April 19 (i.e. data from April 18) << WHY?32101103194500
to Alma on April 19 (again)For some reason, the new barcode 32101103194500
was imported to Alma on April 18 (circa 9 am) but wasn't available to the Analytics barcodes report later that day (circa 8pm), causing a duplicate item record to be created.
Analytics is always one day behind. For example, if you go to the Analytics menu in Alma today, you'll see at the bottom:
Data available as of: 04/22/2024 01:03:06 EDT Data updated as of: 04/21/2024 20:05:00 EDT
So the data in Analytics is accurate as of 8:05 PM on April 21st, but the data was updated at 1:03 AM on April 22nd. So this might just be a timing issue of the Analytics report.
Describe the bug C1405 has two item records for box 11 with the same barcode.
Expected behavior There should only ever be one item record for each barcode.
Impact of this bug
This is confusing to patrons and may indicate a problem with the barcode deduping.
Screenshots
Contact reported by Mike S., contact @amycvo for details