Fees/Fines (UXPROD-792)

[UXPROD-3903] Update automated transfer process to allow sites to format extract as needed Created: 22/Nov/22  Updated: 30/Nov/23

Status: In Progress
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Fees/Fines

Type: New Feature Priority: P3
Reporter: Holly Mistlebauer Assignee: steven turner
Resolution: Unresolved Votes: 0
Labels: Current-ff-work, feesfines
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Duplicate
is duplicated by UXPROD-105 Future Fees/Fines: Update current aut... Closed
Relates
relates to UIPBEX-48 Bursar Acceptance Testing Open
relates to MODEXPS-208 fines missing from bursar export Closed
relates to UXPROD-105 Future Fees/Fines: Update current aut... Closed
relates to UXPROD-3967 New permission for allowing FOLIO use... Open
relates to UIPBEX-46 Create view version of "ui-plugin-bu... Closed
Requires
requires MODEXPS-206 Support new versatile bursar export j... In Progress
requires MODEXPS-207 Migration to new bursar job configura... In Progress
requires MODEXPW-406 New bursar export jobs should allow d... In Progress
requires MODEXPW-407 New bursar export jobs should continu... In Progress
requires MODEXPW-408 New bursar export jobs should allow a... In Progress
requires MODEXPW-409 New bursar export jobs should allow a... In Progress
requires FEXPCMN-18 Add schemas to support new bursar exp... Closed
Epic Link: Fees/Fines
Development Team: Bama
PO Rank: 0
Rank: Cornell (Full Sum 2021): R1

 Description   

Current situation or problem: The current automated transfer process produces an extract that matches what Cornell needs to send to the bursar. The plan was that other sites would use that extract to produce an extract in the format needed by them. Bama is going to make changes to the process to allow the site creating the extract to (SJT) to generate any kind of text-based file, and allowing a variety of formatting options - eg,  adjustable columns, headers, delimiters, and - within "reason" (as-yet-to-be-defined) - choosable data  parameters/DB fields, so that the client site can choose what data belongs in the file. 

In scope

File exports, data pulls from FOLIO db, the ability to alter / choose field data, delimiters, permissions, spacing, newline types, column headers, API interaction between the Circ module and the file export module, file extension choice. In scope should be defined as specific the programming and project management activities needed create a file of library users with current fines and fees, which will be generated by the module and (SJT 1/24) emailed or downloaded. Will review the possibility of saving to a file location. It is a very narrow and specific scope, as the project intends to create this module that performs the above behaviors, and will work within the parameters that allow us to create the above behaviors, and generate the file. Thje module will also generate or change flags inside the FOLIO db/system to indicate users within a file have had their fines transferred. There will be no holds or other punitive behaviors from this module, communication between the module and circ / FOLIO db should be limited to a few items that are flags or indicators of fee/fine status AS related to an individual.

Out of scope

The project is not concerned with any API connectivity other than with is needed by the module to perform it's tasks. The project will not consider generating any other kinds of files, or accommodating data from additional sources outside of FOLIO, or adding any data, or altering the process or described behavior in any way. Again, this project is very specific to its well-defined task, and anything outside of that task is considered out of scope. The module will not perform alerts, the module will not communicate with outside financial systems, and will not perform actions better handled by the circulation module. Modifying circ records with fee and fine updates are also out of scope. The circ module may perform this task, and then whatever actions result in X data changes, then that would be reflected by the Bursar file, but not managed by the Bursar file module. Moving or pushing the file to multiple locations is also out of scope, the single location will be defined by the circ user, or the file may be downloaded.

Use case(s)

  1. UA Libraries needs to send a list of current fines and fees levied upon its users to the financial offices of UA. Once this file is sent, accounts are marked transferred, and placed into the history tab of voyager. UA libraries uses a format that is simple but very specific, their university Bursar requires the data to be received in this format. Once the data is received, UA's system moves these fees and fines, and associated personal data, to it's 'History' tab.  Fees and fines are paid at the University system level, so the library (and the module) are not concerned with performing arithmetic calculations related to fines, or having API communication with the module and the Bursar's office, or with communicating with circulation after the file is sent. UA is only concerned with generating an accurate file, and pushing that to the bursar, or a common, accessible location on the server
  2. A similar use case might be that of a similar library, that needs to generate a text file of fees and fines and users for their financial systems, but uses a different financial system than UA, resulting in their need to create a Bursar file that contains very different formatting.

Proposed solution/stories

Links to additional info

Questions



 Comments   
Comment by steven turner [ 23/Jan/23 ]

UA initial schedule for the project is:

12 and 1/1/23 - initial meetings with stakeholders and experts, and those requesting the mod.

1/25/23 - initial planning meeting, with scrums/standups happening weekly. We should log around 36-40 standups by the end of the project. We hope to initiate Sprint 1 by feb 1, with it lasting until UA spring break in March; Sprint 2 should last until Late April (April 20). We plan to have a finished product by June 1.

 

Comment by Erin Nettifee [ 24/Jan/23 ]

steven turner do you know enough here yet to know if the plans include an edge module that can be used for an external tool?

Comment by steven turner [ 24/Jan/23 ]

Hi Erin - that would appear to be out of scope, I am not sure why we would incorporate Edge connectivity into this module? Is there a demonstrated need? We would be happy to review the idea (there may be other needs we are not aware of, or better ideas on how to accomplish a task)

Comment by Erin Nettifee [ 24/Jan/23 ]

steven turner I think it depends on what "placing a file in a specified location" means.... if it's saving it in someplace in FOLIO, an edge module would be required for an external system to connect in to grab the file.

At Duke, the workflow (in ExLibris Aleph) is
1) script runs that collates some aleph built-in functions and generates the bursar file
2) script puts the bursar file on a server share
3) central IT data warehouse runs script to reach out to server share and grab file and bring into data warehouse

It's that step 3 that seems like it would require an edge module for authentication.

Comment by steven turner [ 24/Jan/23 ]

Erin, I feel that may be out of scope. Creating an external authorization environment & process for a file is not part of planning scope for this project. We will review and make determinations on the efficacy the advice (it is much appreciated), and proceed from that point. I will note that we will do everything we can to avoid instantiating an Edge module. We would prefer manual downloads of presented data in a text format via the browser, I think, or saving in another part of the server, outside of folio (that is what we envisioned) before working with auth and Edge, as we have limited time to complete the project, unfortunately.

Comment by Erin Nettifee [ 24/Jan/23 ]

OK - email is not an option for us, in fact we just went through a whole process with the bursar so that we would stop emailing student data to them and instead use the secured data warehouse workflow. Manual processing through a browser download would be really painful.

I don't know what options there are for saving on the server outside of folio though - that's going to end up being specific to hosting environments.

Comment by steven turner [ 24/Jan/23 ]

Erin, unfortunately I am pretty sure edge is going to be out of scope for us, in this version of the project. I am guessing Duke will need to continue their current process until such a time that we can move to version 2.0 which will involve API connectivity, and will use any module needed to enable this connectivity. Out initial plan is to work on that this fall, looking towards the spring of 2024, for API connectivity.

Generated at Fri Feb 09 00:35:42 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.