Issue | Reported Date | Description and Temporary/Workaround Solution | Reported by | Solution Status and Date |
---|---|---|---|---|
users_groups | 5/13/24 | LDP: the first subquery (creating the user_departments table) uses the users_departments_unpacked derived table, but doesn't specify "folio_reporting" as the schema. The department information from the custom fields (of the user_users table) is not properly extracted. MetaDB: the code does not specify the folio_derived schema for the user_departments subquery. Also, the MetaDB version is lacking the "user_tags" and "user_custom_fields" fields that are in the LDP version. | Joanne | |
po_instance table generating duplicates | 4/30/24 | MetaDB: po_instance derived table has duplicate rows and null values for location fields | Joanne | Unknown |
finance_transaction_purchase_order table for Metadb has two errors
| 4/30/24 | The MetaDB derived table finance_transaction_purchase_order table has two errors in it: The extracted elements should be “acquisitionMethod” and “orderType”. Also – to get the acquisition method name, instead of just getting the id, they could add join to the “folio_orders.acquisition_method__t” table and get the “value” entry. This would be a great addition to the derived table. | Joanne | Unknown |
LDP not showing invoice charge | 4/18/24 | When hosting fixes an invoice, some associated charges may not appear in LDP tables. For example, invoice 327443 has a shipping charge for 29.48 that is not appearing on the fund transactions table in the LDP. Therefore, our reports may show a discrepancy in invoice charges. | Poppy (one problem) and Quesnalia (another problem) may fix invoice input issues so there will be better data quality going forward | |
po_organization derived table | 4/15/24 | LDP and MetaDB - The table lacks contact names. The code for the derived table is not correct, because it matches the organization_organizations.id to the organization_contacts.id, which are not the same thing. The organization_contacts id has to be gotten out of the data array in the organization_organizations table ("contacts"). | Joanne | |
Fiscal Year field on Invoice | 1/31/24 |
| ||
Problems with patron data | 12/20/23 | Graduate students have been reverted to Undergraduate in the Patron Groups, except for about 300 records; this may impact all queries and dashboards using patron data | Unresolved | |
Fund 9 | 12/13/23 | An invoice was inadvertently deleted out of the Fund screen in FOLIO, which means balances for fund 9 will be off by $18,000 until this is fixed. Fixed as of 1/31/24 | Resolved | |
Publisher | 12/13/23 | There have been some inconsistencies in the availability of the publication date and publisher on tables with this data. Advised to get this data from the instance, not the PO for now | Unresolved | |
Fully paid order still shows encumbrance | 6/1/23 | In orders reports, even though payment status is showing the “Fully Paid” value, there are still encumbrances showing | Unresolved | |
FY23-FY24 Fiscal Year Rollover Changes to Fiscal Year Dates | 7/15/23 | FY23-FY24 Fiscal Year Rollover Changes
| None | |
Date/Time in LDP not matching Folio
| 5/17/23 | This issue has been found when using the folio_reporting.feesfines_account_actions. It may very well affect many other tables. The transaction date result from an SQL query using LDP is showing a timestamp difference of 4 hours. If the query is referring to an original table where the time was recorded as Timestamptz, then the date in the derived table needs to be casted as Timestamptz, otherwise the system will add 4 hours automatically. It will affect the query results when the date/time was recorded after 8PM UTC. Examples are Fees, Fines, loans etc. A review of all derived tables using dates should be done. Example: Existing code: json_extract_path_text(ff.data, 'dateAction') AS transaction_date, Replace by: json_extract_path_text(fa.data, 'dateCreated') ::timestamptz AS transaction_date As a temporary fix, if your query is affected by a date not casted as Timestamptz, update your query by changing the data type to Timestamptz. The results should show the correct date/time. Derived tables will need to be updated by the Folio Community.
| Unresolved This issue (along with several others) is scheduled to be fixed in https://github.com/folio-org/folio-analytics/issues/501 | |
feesfines_comments table | 4/26/23 | feesfines-comments table not populating with comments -not requested in reports yet -not high priority, but good to know | Unresolved | |
The derived table "feesfines_accounts_actions" is no longer correct because the source table (public.feesfines_accounts) has changed | 4/19/23 | The derived table "feesfines_accounts_actions" is no longer correct because the source table (public.feesfines_accounts) has changed. Several fields in feesfines_accounts_actions are now blank. We discussed this issue in the reporting development meeting. Angela will update the feesfines_accounts_actions derived table so that these fields populate from the public.feesfines_accounts table. She will also bring up the problem of not finding out about field changes to Product Council on 4/20/23.
| Unresolved, but plan in place | |
srs_marctab instance count is low in LDP Production | 3/14/23 | reported to EBSCO -The number of srs_marctab instances in the LDP Production instance is down by a factor of 10 compared to LDP Test (600 million down to 60 million) -The number of srs_marctab instances in LDP Test is now down by 318624 records compared to 3/14/23 Resolution: Setting statement_timeout = 7200000 parameter for postgres addressed issue with srs_marc table not getting updated fully in LDP Test and LDP Prod | Unresolved -still seeing intermittent problems LDP system configuration setting addressed issue | |
Preserving Circulation Demographic data | 1/17/23 | Preserving Circulation Demographic data
Note: Metadb will include history for tables, so patron demographics could be gathered this way | Workaround in place local_core.circ_snapshot3 updated automatically daily at 7am | |
Call Number Order on Holdings-Level Call Numbers | -see https://issues.folio.org/browse/UXPROD-3496 -this is a feature that allows you to order your lists of items in correct call number order with the holdings level call number -Currently, we are unable to sort holdings record results by correct LC call number order. For item records, we can do this through the “effective_shelving_order” field in the inventory_items table (and with applying the “collate “C”” function in the ORDER BY part of the query). We can’t do this with holdings records. It never comes out right. We had a JIRA ticket for this work, but we can’t find it. | Unresolved | ||
Item Level Call Number no longer on some derived tables | -derived tables loans_items and items_holdings_instances no longer capture the item level call number, because the inventory_items table (which they reference) has changed -The derived tables “items_holdings_instances” and “loans_items” no longer contain the item call number, because the source table (inventory_items) no longer has that field. Instead, inventory_items has the call number components parsed out of the data blob (prefix, suffix and call number core). These components need to be included in a revision of the scripts for the two derived tables. Also, the item_ext derived table has been updated to include the parsed-out call number components, but still retains the non-functional item_level_call_number field. | Resolved -Natalya has updated items_holdings_instances for Orchid 1.6 -Natalya has updated loans_items for Orchid 1.6 | ||
Orchid Breaking Changes for Subjects and Series | 1/3/23 | Breaking changes for Orchid release: updates to instance records (subjects and series) to capture changes associated with authority control Cornell goes to Nolana - end of Feb, beginning of March Cornell goes to Orchid - hopefully before Fiscal Year Rollover
The changes are mainly related to two fields: "properties": { series field is now an array of objects: "properties": { | Resolved -Natalya has updated these derived tables for Orchid 1.6 Folio Analytics release -see more information in Subjects and Series documentation | |
Finance_Budgets table issue
| 1/17/23 | Finance_Budgets table issue
| Workaround in place Bug submitted, to be fixed in Poppy release | |
Fund Balance Discrepancy | 1/12/23 |
| Unresolved Bug submitted, to be fixed in Orchid release | |
In the public.srs_records table, the column external_id is actually the instance_id | None needed | Fixed | ||
In the public.srs_marctab table, all ids are in uuid format, and this does not match the format of ids in other tables | Cast all ids from tables that connect to srs_marctab as "::uuid" Example code when joining srs_marctab AS sm to srs_records AS sr LEFT JOIN srs_marctab AS sm ON sr.id::uuid = sm.srs_id | None | ||
In the public.srs_marctab table, the instance_id column is incorrect and should not be used. | The srs_marctab table can be connected to the public.inventory_instances table via hrid, and the instance_id can be brought in from the inventory_instances table. Example code: SELECT WHERE sm.field = '000' Another way to get data from the srs_marctab table and insert a correct instance_id is via the srs_records table. Example code: SELECT --NOTE that all ids in the srs_marctab table have been cast as uuids, so cast the OTHER table's id as ::uuid
| Fixed, the instance_id column from srs.marctab has been corrected as of 9/12/22. | ||
public.audit_circulation_logs did not start recording loan renewals until December 17, 2021. |
| The circulation_loans table has a record of renewals (renewal count) starting 7/1/2021, but note that these are only for items checked out since 7/1/2021. | None | |
public.notes table does not contain any data, and will impact any queries using this table | updated 10-17-22 | None | Resolved, but still has the contents field data that includes HTML tags -Sharon to ask Nassib | |
Invoice and fund tables migrated from Voyager show amounts 100 times greater than the actual amount | 10/17/22 | The data type for monetary amounts in Voyager finance tables was "Text," but when migrated to Folio was turned into "numeric." The decimals were stripped out – this means that when using Voyager historical data for funds and transaction amounts, divide your results by 100. Be careful to check your results for all queries that involve monetary values from Voyager. | No fix foreseen |
To create a new FOLIO Enhancement request:
https://tdx.cornell.edu/TDClient/138/Portal/Home/