Issue Report: Issue #1: Proprietary_ID for Books is blank in R5 whereas R4 has MRW|BK. This field is important for us to identify different package for separate Cost-Per-Use calculation. Issue#2: BR2(R4) and TR (R5-metric: Total Item Requests) for Jan-Mar 2019 totals do not match. R5 has 161 more count (0.48% more) than R4 and R5 has 1 extra title (10.1002/9781118316757) with 2 requests in Mar 2019 not shown in BR2 (R4). If R4 and R5 totals for the same time period (Jan-Mar 2019) do not match, we cannot make a valid Year-Over-Year comparison between 2018 and 2019. Thank you in advance for looking into these matters. Nga Ong

COUNTER Response: Wiley responded very promptly on this issue. thank you. They discontinued using the proprietary column to distinguish between books and MRW. They have had to reprocess the Jan_March data at least once, and it can happen that older reports are failing to match usage to content if the content has been published very shortly before month end. When data get reprocessed, the product table will be more up to date and cover these latecomers. The R5 data are correct.

Issue Report: We have noticed all the COUNTER 5 reports we get from publishers that come from Silverchair are in an incorrect format. There should be only two lines for each title one for Unique item request and the other one total item request. But for each title there are several lines

COUNTER Response: Silverchair has been informed and say that this is an issue they are aware of and the fix is in progress.  The usage numbers are correct, when combined into one row.  They are just appearing on two lines as there was a period of time that the data processed without the Online ISSN for the content, causing it to appear on two lines.

Issue Report: Credo is failing to respect YOP filter. Here is example URL. The YOP range is 2010-2020 but it's returning 2009 YOPs - basically it returns all data regardless of that setting, as I also tried other date ranges (2005-2009) and got the exact same result. https://search.credoreference.com/reports/tr?customer_id=7303&requestor_id=admin%40upei.ca%7Criddle999&begin_date=2019-03&end_date=2020-02&data_type=Book&access_method=Regular&metric_type=Unique_Item_Requests%7CUnique_Title_Requests%7CNo_License&yop=2010-2020&access_type=Controlled&section_type=Chapter%7COther%7CSection&attributes_to_show=Data_Type%7CAccess_Method%7CYOP%7CAccess_Type%7CSection_Type

COUNTER Response:

Issue Report: I cannot seem to get a usage report for my institution's use of Infection Control & Hospital Epidemiology for 2019. Can this be run and sent to me via email? I need this information ASAP. Please and thank you.

COUNTER Response: COUNTER sets and maintains the Code of Practice but does not supply the COUNTER usage report. The usage reports are provided by your vendors and publishers from their website.

Issue Report: In MPSInsights Counter 5 Dashboard (i.g. IEEE, RSC) columns for all attributes are displayed in the Title Master Report. The web interface offers no option to select or deselect attributes to be displayed in a report column.

COUNTER Response: MPS has started working on this as additional feature in their reporting platform.

Issue Report: Dear Sir or Madam, I just downloaded the TR_B3 from JSTOR and I noticed that although they managed to pass the audit successfully (https://www.projectcounter.org/counter-user/jstor/#sect-title_master) the recording seems wrong to me. Please have a look at the pivot table result: Metric Type Sum of Reporting_Period_Total Total_Item_Investigations 1127 Total_Item_Requests 1127 Unique_Item_Investigations 1312 Unique_Item_Requests 986 Unique_Title_Investigations 370 Unique_Title_Requests 157 1) The Total_Item_Investigations and Total_Item_Requests are identical. 2) The Unique_Item_Investigations are more than Total_Item_Investigations. I would appreciate it if you could check it and inform me back. Kind regards, Dimitris Antonakis

COUNTER Response: ProQuest noticed a temporary data issue that resulted in this behavior. This has already been corrected.

Issue Report: Hi, We're noticing several errors when attempting to harvest SUSHI R5 reports from JSTOR. Our developers investigated and found that JSTOR is queuing reports. We see this error when initially attempting to harvest: "The SUSHI server returned HTTP code 202 (Accepted) and exception Warning 1011: Report Queued for Processing (Report is currently queued for processing. Please retry the request after some reasonable time.)." We also see this error, "Publisher is required report Item," which seems to indicate a required field or parameter that is not part of the COUNTER R5 standard. When I try to reharvest again after the queuing error, the TR_J4 shows this error message: "TR_J4: Report Server returned Exception: Message: Error during serialization or deserialization using the JSON JavaScriptSerializer. The length of the string exceeds the value set on the maxJsonLength property. Parameter name: input." Can you work with JSTOR to address these problems? Would it be possible for them to stop queuing reports? Let me know if you need additional information. Thanks, Susan Martin

COUNTER Response:

Issue Report: JAMA COUNTER Individual months’ usage stats doesn’t add up to the reporting period total. Usage Report retrieved from the AMA Admin Site: https://sitemaster.jamanetwork.com/admin/instAdminDash.aspx?ID=37848

COUNTER Response: Silverchair which provides COUNTER reports for JAMA has been contacted and the team there confirms that this is an issue they are aware of and the fix is in progress. They will be restating the reports for the period when the errors occurred.

Issue Report: The DB1 and MR1 reports are using invalid date formats. For example: 2020-02-11T03:05:30Z and this: Begin_Date=2019-01-01; End_Date=2019-12-31

COUNTER Response: The correct date formats are as follows. The issue was raised with the third party which manages COUNTER reports on behalf of Infobase and quickly investigated. The dates are now in the correct format.

Reporting_Period	The date range for the usage represented in the report, in the form of: “Begin_Date=yyyy-mm-dd; End_Date=yyyy-mm-dd”.	Begin_Date=2016-01-01; End_Date=2016-08-30
Created	The date and time the usage was prepared, in RFC3339 date-time format (yyyy-mm-ddThh:mm:ssZ).	2016-10-11T14:37:15Z

Issue Report: Hi! It appears that HighWire reports are not following the Counter r5 Standard for the report filter field. When we attempt to upload HighWire reports to 360 Counter we're seeing errors. Our developers investigated and determined this is due to HighWire not following the report standard. Can their files be corrected going forward? Specifically we found problems with the TR_J1 for Genetics Society of America report files. Thanks! Susan

COUNTER Response: We are awaiting a sample report to review the errors.

Issue Report: Highwire's downloadable COUNTER 5 reports only offer the choice of HTML and CSV.

COUNTER Response: CSV is a structured text file that can be easily imported into spreadsheet programs without loss or corruption of data.

Issue Report: Dear, Maybe I'm wrong but I find it a bit strange when the unique_title_request and the unique_item_request gives the same number. this is the case with the TR_B3 report I've downloaded from Dawsonera. Kind regards /Charlotte Malmo University Library

COUNTER Response: It is quite possible that on a platform where the books are delivered as a single PDF, you will see Unique_Item and Unique_Title with the same number. On such platforms, the unique item is the book. On a platform where the books are delivered as separate PDFs, you are more likely to see a higher number of Unique_Item than Unique_Title requests. On such platforms, the unique item is the chapter.

Issue Report: Tr_j2 and some others are not sending report_items but no exception in header. Sample URL: https://sitemaster.geoscienceworld.org/sushi/reports/tr_j2?customer_id=2320&requestor_id=15359&api_key=2d3422e9-04c5-448b-bb62-811f4ad3a1ee&begin_date=2019-01&end_date=2019-12

COUNTER Response:

Issue Report: JSTOR uses the wrong exception when requesting reports before their R5 start date. The header for all supported reports is returning: "Exceptions" : [ { "Code" : 3030, "Severity" : "Error", "Message" : "No Usage Available for Requested Dates", "Help_URL" : "https://support.jstor.org", "Data" : "" } ] Example URL: https://www.jstor.org/sushi/reports/dr/?customer_id=upei.ca&requestor_id=collections%40upei.ca&begin_date=2018-01&end_date=2018-12

COUNTER Response:

Issue Report: https://www.counter.amdigital.co.uk/CounterSushi5Api/reports?customer_id=collections%40upei.ca&api_key=492368c9-2338-49e8-a01b-8cb88504dc49

COUNTER Response: AM Digital responded and provided the basic URLs to obtain reports. AM Digital's SUSHI details are https://www.counter.amdigital.co.uk/CounterSushi5Api.

Issue Report: https://inqwell.squidsolutions.com/release/aps/sushi/reports/pr?customer_id=PR447048&requestor_id=5c9290982b734cbb9893a765&begin_date=2017-01&end_date=2017-12 They're putting UPEI in the Created_by header field instead of who is generating the data

COUNTER Response:

Issue Report: Proquest Ebook Central only offers HTML and XLSX format for tabular R5 reports

COUNTER Response:

Issue Report: 503 Service Unavailable Service Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. Apache/2.4.7 (Ubuntu) Server at pqbi.prod.proquest.com Port 443 My understanding is the 503 https should be returning a json exception but this is returning html. https://pqbi.prod.proquest.com/release/sushi/ebooks/r5/reports/tr_b1?customer_id=upei&requestor_id=5e31c5140c18c070632e35e4&begin_date=2019-01-01&end_date=2019-12-31

COUNTER Response: This was a temporary error resolved promptly by the vendor.

Issue Report: Depending on which report and which of my two SUSHI clients, I'm getting 403 errors, 404 errors, and spurious "invalid api key" errors from Brill. https://ams.brill.com/rest/COUNTER/v5/reports/ir?customer_id=5923&api_key=FWjEKsp1+ocRWaQuwvySMw==&begin_date=2019-01-01&end_date=2019-12-31

COUNTER Response: Sheridan PubFactory discussed this issue with its Site Reliability Engineering (SRE)  team. A new release is in progress and therefore they do not want to unblock the user agent right now. Queries should be sent to the the Brill support team brillonline@brill.com, so that Sheridan can track the status of queries and they can assign the work to the relevant team.