https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42214 Michaela Sieber <michaela.sieber@kit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew.auld@openfifth.co.uk | |, clemens.tubach@kit.edu, | |raphael.straub@kit.edu Severity|enhancement |major --- Comment #1 from Michaela Sieber <michaela.sieber@kit.edu> --- Short Description: When harvesting or parsing COUNTER reports, the monthly usage data (erm_usage_mus) is written correctly and completely into the database. However, the calculation and generation of the yearly summaries (erm_usage_yus) is broken because identical numbers block each other during the database check. If the monthly entries contain recurring numbers—for example: January = 1, February = 3, March = 8, April = 3 — the monthly table (erm_usage_mus) is perfectly fine. However, during the generation of the yearly records, Koha treats identical numeric counts as absolute duplicates. As a result, the second "3" is silently skipped, leaving the erm_usage_yus table with missing rows and an incorrect total overview. Root Cause: The bug lies in Koha/ERM/EUsage/UsageTitle.pm within the yearly_usages method: if ( $self->yearly_usages()->search($yearly_usage)->last ) { $job_callbacks->{report_info_callback}->('skipped_yus') if $job_callbacks; next; # <--- False positive triggers here! } The exact flaw: When the parser loops over the data and calls $self->_add_yearly_usage_entries, it passes the $yearly_usage attribute payload to search(). Because search() converts the entire attribute hash into a SQL WHERE clause, the database query includes the volatile metric counter value itself (totalcount). In our example, when processing the data (values: 1, 3, 8, 3): The first 3 (from February) is checked, not found, and stored successfully.The 8 (from March) is checked, not found, and stored successfully.The second 3 (from April) is processed. Koha's search() query looks into the database and asks: "Do we already have a record for this title with a count of 3?" The database answers Yes (because of the February entry). Koha hits next and drops the April data on the floor, mistakenly thinking it is a duplicate row, even though it belongs to a completely different month/context. Steps to Reproduce: Import a COUNTER report where different months contain identical values (e.g., Jan = 1, Feb = 3, Mar = 8, Apr = 3).Inspect the database table erm_usage_mus: All monthly entries are complete and correct.Inspect erm_usage_yus: Rows are missing (e.g., only 1, 3, and 8 are present; the second 3 was dropped by the skipped_yus condition). We suggest to remove / replace the yearly usage table, see Bug 42218 - ERM Usage – remove Database table erm_usage_yus -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42214 Michaela Sieber <michaela.sieber@kit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jvinke@austinseminary.edu -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42214 Michaela Sieber <michaela.sieber@kit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |42218 Priority|P5 - low |P1 - high Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42218 [Bug 42218] ERM Usage – remove Database table erm_usage_yus ? -- You are receiving this mail because: You are watching all bug changes.