kristenwilson
commented
2 years ago Comments from Sean based on review of PCOM data:
For total requests, I'm counting the number of unique request IDs with the REQ_VALIDATED state, which gets us to 55 for pcom. I suspect the additional 7 that the UI is counting are the following: 10b147c7-bc88-4f59-a83b-2a3553007663 6a6dfee3-4b40-4ff3-80ed-90142d1c6d43 7dbf7758-bcc3-4e51-a0e9-658afe193fd5 c157cc0b-6ec2-47ad-a2a7-9d27528a2295 cf3f1d1e-97cd-4eac-a22d-ad16b005e226 e42d650f-df51-4516-bf63-611672d967aa edadbb20-771d-4085-8384-a088f0112fa5 6 of them have a message stating that the lookupPatron call failed and indicate an unknown user.
For received, I think I am double-counting. When an item has REQ_CHECKED_IN as its current state and someone uses the Message feature, ReShare creates a new transaction where the from state and to state are both REQ_CHECKED_IN. There are 3 examples of this in the pcom data, thus creating the 34/31 discrepancy. I will try to update the code to only count from REQ_SHIPPED to REQ_CHECKED_IN as received instead of what I'm doing now.
For unfilled, PPCO-50 is the culprit. According to this data, it's been sitting in the Supplier Identified state since 10/29.
Action items related to this:
- Edit all queries to eliminate double counting of received items with messages.
- Fix ReShare bug that is preventing some requests from properly transitioning to the end of rota state.
I've started doing some more detailed checking of the reports, now that we have a lot of data for PALCI. I'm seeing relatively minor discrepancies between the reported totals and the totals visible in the UI.
As a sample, I reviewed NYU (high volume) and PCOM (low volume). The results of this analysis is below.
I'm wondering if it would be possible to pull the actual list of the requests associated with these counts for both PCOM and NYU so we can compare them.