Banner FIS Coordinator Work Summary

Daily

Review nightly feed suite and audit reports and OnBase travel/PR load

“[Travel Reports] Travel I/F” messages reports - review these for any TR/TA/TV/PR that bombed; review reason; issues are tracked on this worksheet
- if it’s just account code, correct and resubmit the text file (resubmit instructions below)
- if index, see if there is a better index available, correct and resubmit
- if grant, see if grant is closed, ask SPA to reopen or provide a new grant code; update and resubmit
- to resubmit the file:
- copy the text string of the existing file layout from the flat file output to a blank Notepad file
- save file with file name TVresubmit(original transaction number) - for example if you needed to resubmit TR123456, the new file name would be TVresubmtTR123456
- open WinSCP and log in
- drag renamed file to the err_reload folder
- In Banner, run ZF_INVOICE_UPLOAD job sub; no data to enter; click Next Section through each section then click Save; that puts the file on the server to be processed that evening along with the rest of that day’s OnBase work

Library invoice feed (weird subject line with a bunch of numbers)

usually loads OK, but sometimes they have a payment to a vendor that just connected to PaymentWorks and the available remittance addresses have changed; contact Elsa Loftis (eloftis@pdx.edu) and Will Fanning (rfanning@pdx.edu) to let them know the Alma system invoice voucher needs to be resubmitted)

fis nightly report suite

fgrtrnr_a report shows any trnr process documents that need to be updated to post

fis fac inv report

check for invoices that error out; they will need to be resubmitted through AiM or manually entered in Banner; convey info to member of facilities accounting group doing invoice entry

fis_fgrtrnr_f

shows PCard transactions that didn’t feed as expected; check for error message; usual reason is transaction was somehow completed without a commodity description; transaction needs to get rolled back to an unfed status; use banweb, Admin tab, PCard transaction rollback option; enter IV doc number and click Submit; 

Review details shown to ensure it’s the right transaction. Click Delete

Notify pcard@pdx.edu and cc to Margaret Hernandez (hernanm@pdx.edu) about the rollback; info on email should show:

• assigned invoice IVxxxxxx

• Card ending - xxxxxx

• Bank Post Date - MM/DD/YYYY

• Feed date - MM/DD/YYYY

• Invoice Date - MM/DD/YYYY

• Amt - $amount

• Vendor  -vendor name

• Custodian - ODIN ID

As of November 2024, the PCard program manager has access in banweb to do these updates as well.

• zfrfisa_purch_probs - shows incomplete invoices, POs and PCard transactions that didn’t feed as expected; check on invoices and POs to see if they may need to be deleted because they are not fully filled out and from a prior business day

• Bank Rec Deposits - check for deposits against a deposit code that’s not set up in our Banner instance; notify Linda Troupe and Clint; may not require update as sometime these posting are actually in Banner

• in OnBase travel/PR load, review PRs over $100 to look for issues with reasonableness of account code or if reimbursement is being processed with the right process; issues are track on this worksheet

• Run FGRIDOC to review incomplete POs, invoices and any JA journal vouchers (travel authorization liquidations)
  - POs get stuck waiting for CAPS to approve contract or when CAPS denies PO out of Banner approvals; check status and contact inputter to complete PO if things are ready
  - invoices get returned for update and inputters ignore Banner messages - check GUAMESG to see if approver provided reason for document being returned; if no message, check FOIAPHT to see if inputter denied invoice; email inputter to check if document is still needed or can be recompleted with required updates
  - JA docs get mixed up when they get created from OnBase and don’t always have the correct FOAPAL details; review in FGIENCD and check on what the correct FOAPALs should be; open JV in FGAJVCD, removed messed up FOAPAL details and enter correct ones

• Run ZFPRITBP and check if any invoices are noted as using address type other than VP; see if a matching address to the problematic one(s) exists by opening FAIINVE, determine vendor ID, use FTMVEND to check addresses; use FZPINCH to update address

• Review incoming email from across campus seeking Banner document assistance and respond as needed

Weekly

Friday - special FIS audit reports

FOMPROF and FIS Approval Queue Audit Report - review issues noted

some things that come up, but are OK as is:

• Employees who are terminated but whose fobprof web indicator is still checked:

• Employees who have no active job but whose fobprof web indicator is still checked:

For Employees whose FOMPROF and HR org codes differ, go to FOMPROF and change Organization to the one in the HR_org column (leave THOODE and LOVELAT, report is not correct)      

For Users granted BAN_FIS_PURCHASING_DEPT_C in the last 7 days go to FOMPROF and check the box for Purchase Order Hold Override

Check FIS Security Audit Report        

For FIS users who were assigned a new position in the past 7 days, look for those people who handle daily transactional or approval processes or are dept chairs; add to psu-fin-announce-group@pdx.edu (https://groups.google.com/u/1/a/pdx.edu/g/psu-fin-announce-group?pli=1 )  if not already on it

For Users who are in both ap check processing and vendor maint groups, OK for KING4 to be there   

Travel reimbursement records driven by travel module report

shows potential duplicate payments for travel reimbursements - most likely the payments aren’t duplicates for the same trip, just repeating dollar amounts for regular trips or for $0 when there is a travel advance involved and the reimbursement invoice ends up at $0, or the same advance amount provided for different trips; add column to the far right labeled “Information”; review the entries and determine if a real duplicate payment has occurred; when the expense is for a recurring trip, enter “different trips same reimb amt” in the Information column; when the expense was for a trip connected to a travel advance and the reimbursement amount is $0, enter “different trips ea with travel advance netted against actual exp” in the Information column; if the travel advance is for different trips, enter “different trips same adv amt’ in the Information column; name the file YYYY-MM-DD of the review date; completed reviews are saved in Google Drive

Monthly

• Check FIS Security Audit Report - on the first Friday of every month, there will be an additional csv file of data included with this report. That shows employees with FIS access who are having an employment anniversary during the prior month. Worksheet needs to be updated, then distributed to SFO’s of the units where the people work.
  - Add column for SFO
  - Leave columns for PSU ID, Username, Last, First, Hire Date, Employment Status, Job Description, Org code, Org Title, SFO (column to be added), FIS_Access, Remove? Y/N? (column to be added); remove other columns
  - Sort report by Org code and add appropriate Fiscal Officer
  - Divide the report by Fiscal Officer and create separate files for each one; send their portion attached to an email asking them to review assigned access and mark in the Remove? Column “Y” or” N”
  - Saved returned worksheets in Google drive - FIS access audit reports

Annually

• Encumbrance roll
  - Controller runs process after per 12 close that creates a mass JV of all open encumbrances (PO, travel authorizations, grant e-docs)
  - two JVs need to be created from that one - one JV with rule code 2LIQ will liquidate PO encumbrances on general funds and on any PSU Foundation indexes, the other JV with rule code E090 will roll open travel authorizations and grant e-docs to the new fiscal year

• Audit scripts for SQL reports needed by external auditors
  - Controller will request various reports by produced via SQL Query that provide auditors with data on tuition fee revenue, cash disbursements, manual JVs and system JVs over a certain dollar amount; upon request OIT will run a report on payroll transactions higher than disposition 60

As needed

Enterprise Technical Coordinator duties

• Banner upgrades - Ellucian releases software updates quarterly - OIT installs them in non-prod Banner STAGE instance - review if any upgrades affect FIS - if so, set up testing matrix (example) if one is warranted and review pages and processes; it may be sufficient to just test the items being updated; OIT will provide an upgrade workbook (example) where you note your testing issues and note the installation day testing results

• Notifying OIT of Banner FIS issues - when issues arise that need OIT intervention to resolve, create a ticket with the JIRA system. Module = FIS, Dept = University Financial Services, Description should be as detailed as possible and can include screenshots of issues, Priority should be Normal for most issues, but can be elevated if processes are blocked and more immediate assistance is needed; a Banner FIS team member will pick up the ticket and assign it to the appropriate staff member

• Banner access requests - the Odin Account Manager (OAM) system allows users to update their passwords, manage their Duo settings and request system access with an OAR (Odin Access Request). The OARs will route for approval to the requesters supervisor, then to the Banner coordinator overseeing the access requested, then to a financial manager if they are requesting Banner FIS access, then to the OIT Identity and Access Management (IAM) team for access assignment, then completion. Users get a notification when the request finishes.

For Banner FIS access, we have been pretty liberal in allowing people to have access to create invoices, purchase orders and journal vouchers. However, access to be a transaction approver or having a PCard role require additional steps. Approvers need to hold a role in managing an area budget and usually are the person holding signature authority for travel and personal reimbursements for their unit. PCard requests are tracked on a worksheet. All card roles require the requester to have completed the PCard exam (tracked here), turn in a card signature sheet indicating their card role and submit the OAR. The OAR should only be approved if both the card signature sheet and exam have been completed.
There is also OnBase access that ties to some of the Banner assignments. For Banner invoice entry, the user also needs OnBase access for Campus Wide invoice upload and Campus Wide invoice retrieval. For PCard, card custodians and card business managers need PCard online processing. PCard budget authorities need PCard budget authority approval and View and Approve Monthly reconciliation documents

Invoice uploads for grant stipends

• Receive worksheet from department/PI

• Save in folder by grant or program with the file name as received and appending the name of who sent it - for example - October stipend list.xls” received from Mary Smith could be called “October stipend list from Mary” - it may be best to create a new folder for all the upload files that get created for this process noting the year/month of the payments

• Add column labeled “Banner doc #” to the far right

• Look up what the next available one-up Banner doc number for the grant will be:
      CIMR-DISC  - IB9xxxxx
      College of Ed honoraria - IHxxxxxx
      DRC Note takers - IN1xxxxx
      EAGLES - IB0xxxxx (this program may be done)
      Éxito - IE0xxxxx
      OCCD Ed Awards - IB1xxxxx
      OCCD HECC Bonus - people outside of PSU - IB4xxxxx
      OCCD HECC Bonus - people within PSU - IB5xxxxx
      PDX STEM (various grants all with grant funds coded 323xxxx - IB2xxxxx
      URISE - IUxxxxxx

• Enter first available one-up number document number in the Banner doc # column; expand the invoice number list incrementing doc number by 1 for each new invoice for the full list of payments
  - format the worksheet so it will print on 8 ½’ x 11” portrait print out, narrow margins, add header/footer and add gridlines; print as PDF
  - update worksheet to prep for txt file for upload
  - move dollar amount column to be two columns to the right of the Banner doc column; format in General format so there are no commas, dollar signs, or decimal points (unless payment amount includes cents)
  - next column enter ‘YYYY-MM-DD’ (including the apostrophes) - copy down all rows
  - next column repeat the date as noted above - copy down all rows
  - next column enter ‘DD-MMM-YYYY’ (including the apostrophes) where MMM equals the three character abbreviation for the month - JAN, FEB, MAR, et al - copy down all rows
  - next column create an invoice number - could be program and year/month of payment - example - URISE202410 - copy down all rows
  - drag over the PSU ID column
  - enter ODIN ID of person sending you the worksheet - copy down all rows
  - enter the word VENDID - copy down all rows
  - drag over (or enter) index to be charged - copy down all rows
  - drag over (or enter) account to be charged - copy down all rows
  - next column enter 1
  - clear out any remaining columns to the left of the Banner invoice number (name, email address and possibly other columns) so that the Banner invoice number becomes column A
  - save worksheet in csv (MS-DOS) format and append to file name “for upload”

• Open File Explorer and navigate to where you saved the “for upload” file, right click the file name and choose “Open With” and select Notepad

• In Notepad, replace all the commas (,) with pipes (|); make sure there are no extra commas or pipes beyond the last row of data

• The file you are creating needs to have four pipes at the end of each row - to do that, do a replace for Account code|1 with Account code|1||||

• Save the file with the naming convention created by OIT for these - TV (must start with TV) followed by a name you chose that describes the data - for example, TVURISE202410, and save as txt file

• Use WinSCP to move the txt file to the batch_loads upload folder

• In Banner, run ZF_INVOICE_UPLOAD job sub; no data to enter; click Next Section through each section then click Save

• You’ll get emailed output that shows the file transfer

As of November 2024, Jackie Pham and Beth King have been trained on how to do these invoice batch uploads

Approval queue updates or additions

These come in via chart of accounts forms or via email from SPA for grants
All approval queue IDs are four characters long
For updates - changing people - locate the existing queue name by querying from page FTMAPPQ to locate the queue; to add a person, insert new row, enter effective date, queue level, ODIN and a dollar amount to match other queue members at that level; to remove a person, insert a new row, enter effective date, termination date, queue level, ODIN and dollar amount
For updates - changing or entering fund/org values assigned to a queue - locate the existing queue name by querying from page FOMAQRC; click insert to create a new blank record; enter Document Type (INV, PO, or JV), Rule Group (INDG, PORG, or JDPG), Chart (D), then the fund or org to be added

For new queues - determine next available queue name - for grants, as of Fall 2024, new grant queue IDs begin with YC, followed by next letter of the alphabet up to Z (excluding the letters I and O since they get way too confusing for the numbers 1 or 0) then followed by the letter D for invoice queue or P for PO queue; enter queue description - PI last name (and first initial if there are multiple PIs with same last name) followed by GRANTS INV (for invoices) or GRANTS PO (for POs); For invoices the Next Queue is DPAY. For purchase orders, queue limit is $50K (as of Fall 2024) and next queue is POBD
For queue additions - determine next available queue name - for non grants, queue names try to pick up some initials for the unit or program they are serving - for example ENGD is the direct pay invoice queue for the English Dept; after first three letters, then add the letter D for invoice queue or P for PO queue; enter queue description - Dept/Program name followed by INV (for invoices) or Dept/Program name PO (for POs); For invoices the Next Queue is DPAY. For purchase orders, queue limit is $50K (as of Fall 2024) and next queue is POBD

SQL updates for grant FOAPAL elements or for other FOAPAL changes

These arrive via email from the grant setup folks in SPA or SPA fiscal folks (Anisa Chisti or Matthew Mitarnowski as of Fall 2024) or from the chart setup folks in CAS
Use banweb, Admin tab, FOAPAL SQL form link
Before doing what you’re being requested to do, review the existing layout of the FTMFUND, FRMFUND or other chart element to be changed
You can only update the most recent record; you can remove other records to make an older record the most recent one, but check that the older records only differ in terms of dates and not other values within the record
You can’t completely remove a fund or frmfund from the system; if that’s what is needed, create JIRA ticket for OIT to remove the entry altogether

Example:

From: Anisa Chisti <chistia@pdx.edu>
Date: Tue, Nov 5, 2024 at 11:53 AM
Subject: Fund 283552
To: FIS Help <fishelp@pdx.edu>

I created a new record with today's date for fund 283552 which needs to be backdated to 9/01/24 please.

Thank you.

Original fund setup:

Remove second record:

New fund setup:

Update top record to be effective 9/1/2024:

New top record effective 9/1/2024

Banner ship to code updates (FTMSHIP)

Ship to codes are a part of a Banner FIS user’s fobprof record and are used in creating a purchase order. Use Banner admin page FTMSHIP to add new codes or edit existing ones. Codes use effective dates, so any updates can only be done by creating a new record effective with the current date. Purchase orders not yet completed will still maintain the ship to information unless they modify the transaction date on the document to help it find the new ship to record.

Codes do not correlate exactly to the university’s mail codes. There are too many changes to unit names, units consolidating and such to have them exactly match. Address details get updated when a unit requests it or if there is a general information release about a unit’s new location.

To update a code, it is usually easiest to bring up the existing info in FTMSHIP. Click Copy. Make the necessary changes and assign the current date as the effective date. You can future date a record if that is needed. You can’t backdate one. 

Duplicate PIDM cleanup

Staff from the Registrar’s Office monitor the status of system records, and identify potential duplicates. When a dup record involves an entry that is coded as VEN (vendor), they will alert the Banner FIS coordinator and the vendor setup staff member in Campus Accounting. We review the potential duplicate and help identify which is the “good” record (the one we will keep) and which is the “bad” record (the one to be terminated). When one record has a substantial amount of detail in other Banner systems like Student, HR, Financial Aid, that record will be deemed the “good” one. We need to then review if there were any payments made against the “bad” record and request that OIT move them to the “good” record’s payment history.

Create a JIRA ticket, indicate the two IDs involved and ask the payments from the “bad” one be moved to the “good” one. Once they have completed that work in STAGE, review to ensure the transaction movement happened as expected. Approve the JIRA ticket and request the update be made in PROD during the next change control processing.