Why does C1405 have two boxes 11 with the same barcode in Alma?

[regineheberlein]

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

[amycvo]

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:

1. I rehoused the items in Box 11 in a new box, and update components in the finding aid as necessary. For C1405, I just had to update one component title.
2. In ArchivesSpace, I edited the current top container for Box 11: I revised the barcode, and the container profile. I update the latter because many of our legacy collections have "NBox" as the container profile, which is not very descriptive.

[regineheberlein]

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).

[regineheberlein]

@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]

@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.

[regineheberlein]

1. top_container record updated from 32101038564793 to 32101103194500 on April 17
2. aspace2alma imported 32101103194500 to Alma on April 18
3. deaccessioning procedure initiated on April 19
4. sc_active_barcodes did not include 32101103194500 on April 19 (i.e. data from April 18) << WHY?
5. aspace2alma imported 32101103194500 to Alma on April 19 (again)

[regineheberlein]

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.

[mzelesky]

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.