Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

See feature UXPROD-845 for more information!

General Recommendations:

  1. CSV format is fine for all of these reports, additional formats are not needed.
  2. 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.
  3. 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 FeatureTimeframe 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 OptionsData PointsOther 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 ReconciliationThis 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.

...