RA - Fine Reports Small Group Fall 2019 - Summary

See feature UXPROD-845 for more information!

General Recommendations:

CSV format is fine for all of these reports, additional formats are not needed.
Permission controls are needed for all of the in-app reports, for the following reasons:
1. Anything having to do with financial data would not be something we would want to have open to all operators.
2. If the report did not have permission controls, you would not be able to know who had potentially run the report.
3. These specific reconciliation reports have associated service points, which identifies how much money is being handled at that location - a physical security concern.
One point that will need resolution - whether the in-app report can be thin-threaded by setting default time periods for running the report. Because of this, we are recommending that the report be required to have a prompt for date, and not a hard-coded default time period. If that truly can't be done, we believe the report will need to run for at least a four month time period to accommodate quarterly, monthly, and daily reconciliation and audit needs.

Requested Feature	Timeframe to run report (Required?) Yes, or default to past 30 days?	Service Point for Report (Required?) I think so	Payment Methods in Report (Optional)	Thin Thread Options	Data Points	Other info
In-App Report: Cash Drawer Reconciliation Report	Prompt on run for start date and end date (default to current date/time) Which date should be checked in order to include the item in the report? Payment date? Refund date? 'Action' date? JL: probably action date, where action = whatever is appropriate, like payment or refund	Prompt for Selection We actually use Fee/Fine Owner, which could be one or several Service Points JL: we need to specify the service point at which the cash drawer is located, because that's what's being reconciled. We take payments for all libraries (= fee fine owners) so we need to show the fee fine owners on the report.	Prompt for Selection (of one or more) JL: Yes (we need to exclude non-desk payment methods, like bursar pass)	Use logged in service point Return all payment methods Return transactions and libraries compute summary values on their own.	Do you want each fee/fine to be one row in the spreadsheet? (Keeping in mind that a fee/fine can have multiple 'actions' (aka transactions) such as payments, waives, transfers, refunds. List all the transactions on separate lines for each fee fine that meets the previous criteria For each transaction returned in the query: Transaction date/time Transaction Amount Payment Status Payment Method Waive Reason (if applicable) Refund Reason (if applicable) Add'l actions: Cancelled as Error, Suspended as Claim Returned, Staff Info Only Add'l information: Staff, Patron Operator ID Fee/Fine owner Fee/fine type? (e.g. Lost item fee, Overdue fine, Locker rental fee, Damaged item fee). JL: Yes Summary values: Total payment by fee/fine payment type. We don't have a field called Fee/fine payment type. Did you mean Fee/fine type? JL: right, we don't need this - we need payment method (below) Total by fee/fine payment method. JL: Yes, to me this means cash, check, credit card, dept account.	Personal Data: Operator ID Add'l Information - Patron (potentially) Same-Day Data needed? Yes
In-App Report: Financial Transactions Detail Report	Prompt on run for start date and end date (default to current date/time) Which date should be checked in order to include the item in the report? Payment date? Refund date? 'Action' date? JL: Action date	Prompt for Selection We actually use Fee/Fine Owner, which could be one or several Service Points JL: Yes, fee fine owners showing also the service points at which the transactions occurred	Prompt for Selection (of one or more) JL: Yes	Use logged in service point Return all payment methods	Do you want each fee/fine to be one row in the spreadsheet? (Keeping in mind that a fee/fine can have multiple 'actions' (aka transactions) such as payments, waives, transfers, refunds. Each transaction should be listed on a separate line for each fee fine For each transaction in the timeframe: Transaction date/time Transaction Amount Payment Status Payment Method Waive Reason (if applicable) Refund Reason (if applicable) Add'l actions: Cancelled as Error, Suspended as Claim Returned, Staff Info Only Add'l information: Staff, Patron Operator ID Fee/Fine owner Fee/fine type? (e.g. Lost item fee, Overdue fine, Locker rental fee, Damaged item fee). JL: Yes. Add'l specific info Patron Name Patron ID (Default - External System ID) Patron Email Instance Title Instance Author Item Barcode Item Call Number Item Loan Date Item Return Date (if applicable) Item Effective Location Overdue Policy Name Lost Item Fee Name (this is Fee/fine type) JL: Not sure I understand this - is this different than the Fee/fine type listed in the group above?	Personal Data: Operator ID Add'l Information - Patron (potentially) Patron name Patron ID Patron Email Item information (because Same-Day Data needed? Yes
ID440: Fine Fee Reconciliation	This report is essentially the same as the two reports above (depending on whether an institution includes patron info as part of their reconciliation process.)
ID483: Monies paid/collected for fines/fees, privileges, purchases, or other reasons by payment method, date range, location, or operator	This report is intended for annual statistics UChicago reported that it does not need to include operator information (contrary to report title description) This report can be accommodated for in the LDP.