This is managed by going to Settings > Tenant > Bursar Exports in Iris, which will change to Settings > Users in Juniper, where this feature is known as "Fee/Fine Transfers". Bursar / Transfer admin permissions in FOLIO are required.
On the transfer settings form, the important fields are:
Schedule Period - leave at "None" until this can be automated. Otherwise you can specify when this runs.
Max. Days Outstanding - this sets how many days old the fees/fines will be that are transferring. For example, set to "10" to pick up all non-transferred fees/fines from the last 10 days. The Library has a standard of waiting 9 days before transferring, so this setting does not fit our needs, hence the manual process. We are not currently able to say "only bring in fees/fines that are older than 9 days". After each run, the Bursar file needs to be manually edited to remove recent fines and only send off older fines. This may be fixed by the Kiwi version of FOLIO when this issue is resolved: https://issues.folio.org/browse/MODEXPW-31
Patron Groups - only Undergraduate and Graduate groups are used. Although the form allows selecting multiple groups, only one is really run, so run one group at a time. This is a known FOLIO bug.
Transfer Owner, Transfer Owner Account - leave as "Olin" and "CUL Transfer Account". These fields are meaningless for CUL but they are required.
Transfer types:
An admin can set all the fee/fine transfer types by fee/fine owner (CUL service point) in the table. Select the owner, then you can see the various fee/fine types. These are determined by agreement between CUL and the Bursar. CUL Accounting (Ken Putnam) and Access Services (Andy Horbal, Michelle Hubbell) negotiate these with the Bursar.
Transfer type corresponds to the CU Bursar "Item Type". Transfer description corresponds to the Bursar's "Item description". These carry over as is to the Bursar file. There is some redundancy in needing to put the same Type and Description values for similar fee/fine types (like "Lost item fee" and "Lost item replacement", or "Overdue" and "Overdue fine"). Sometimes they come through as one of the pair, sometimes the other of the pair, but in the end it doesn't matter.
Transfer code must be set to "Charge" to carry through to the Bursar. "Payment" is not active yet, but the intent would be to track Bursar refunds if ever used.
To change any of the values, select the Fee/fine owner, enter the data, then click the "Save" button on the lower right. Make sure to keep Accounting and Access Services in the loop (Accounting has admin rights).
To manually run the job once all the parameters look good, just click the "Run manually" button below the table. A green confirmation message should pop up.
To see the status of the job, go to Apps > Export Manager and periodically refresh the page. You should see the job in the table along with a status and date. The link used to permit downloading the Bursar file but that stopped working at some point. The files are transferred to the CUL AWS S3 bucket called "folio-bursar", in its "shipped" folder:
https://s3.console.aws.amazon.com/s3/buckets/folio-bursar?region=us-east-1&prefix=shipped/&showversions=false . Someone from Library Systems or a developer with access can download the file. Eventually this will be more self-service and automated. Currently technical staff must drop the file into the Peoplesoft FTP server for processing.
To see the status of the job, go to Apps > Export Manager and periodically refresh the page. You should see the job in the table along with a status and date. The link used to permit downloading the Bursar file but that stopped working at some point. The files are transferred to the CUL AWS S3 bucket called "folio-bursar", in its "shipped" folder:
https://s3.console.aws.amazon.com/s3/buckets/folio-bursar?region=us-east-1&prefix=shipped/&showversions=false . Someone from Library Systems or a developer with access can download the file. Eventually this will be more self-service and automated. Currently technical staff must drop the file into the Peoplesoft FTP server for processing.
The file needs to have the naming convention lib_YYMMDDa_hh-mm-ss.dat, such as lib_210916a_16-30-37.dat, for a job that ran on 9/16/2021 at 4:30:37 pm.
The charges within the file also have dates; cut and paste charges newer than 9 days into a new file for later dispatch to the Bursar. You can combine Undergraduate and Graduate charges into the same file.
You may occasionally see missing Transfer type (Bursar Item type) values in the file; they can be manually added in once known. Check that they are defined in the given Fee/fine owner's fee/fine types table. You can view the closed / transferred fines in the user's FOLIO record. The file only has their Cornell ID, so you have to translate that to a barcode or NetID to know which FOLIO user had the fine. One way to do that is use DBeaver or another database client to connect to the patron_warehouse MySQL database, then run a query like:
SELECT barcode, institution_id FROM PATRON_NETID WHERE institution_id = '001234567';
where the last value is the user's Cornell ID from the file prepended by two zeroes.
After submitting the file to Peoplesoft, an email needs to be sent to bursar-systems@cornell.edu with the file name, row count, and dollar total. This gives the Bursar a heads-up that the file was there to process. Details by way of example:
To: Bursar Systems <bursar-systems@cornell.edu>; Library Accounting Services <libacct@cornell.edu>; Library Batch Output <lib-batch-out@cornell.edu>
Subject: LIBRARY ==> BURSAR CONTROL FILE
Charge File name: lib_210521a.dat
Number of charge records: 4
Monetary amount: 300.00
Credit File name: lib_210521b.dat
Number of credit records: 1
Monetary amount: 15
This had been automated in Voyager via old custom code. At some point this should be rewritten to avoid manual work.
In the past, the list of billable students was captured in an "aecubillable" file, which we believe is the same as a file that went to the Voyager App server called "billingflag<date>.txt", and which will transition to the LSTools server lms-018 at some point. This is important because we are only supposed to pass through charges to billable students; the Bursar will pick up improper billing but it will be smoother to filter them out ahead of time. The process was based on ancient code that is no longer in use, so at some point we should build a new app to handle that. The Bursar is able to reject improper billing in the meantime.