US Bank produces daily files of purchasing card (also known as pcard or p-card) transactions. Automated processes run Monday through Friday securely retrieving the file from US Bank’s server, extracting data from it and routing it through the Banner document feed processes eventually creating “z-doc” invoices and journal vouchers in the Banner Finance system. The morning process, BS_PCARD_RECON_M_F, retrieves the file, loads, and posts the incoming data as a JV. Service Center personnel redistribute the transactions to appropriate expense accounts based on receipts from the departments. The afternoon process, BS_PCARD_INVOICE_M_F, feeds zero-balance invoices arising from the redistribution activities creating the "z-docs."
At end of month and end of fiscal year, these processes must be paused such that we continue to retrieve the data to load later but we suspend the process prior to production of JVs so that we are not trying to reconcile a moving target. The process creating invoices continues to run so that redistribution activities still post even though no new transactions are being loaded.
The job which retrieves the files from US Bank and routes them into the feed, BS_PCARD_RECON_LOAD_M_F, has a parameter known as “data action” which has two values, FEED and HOLD. When the value is HOLD, the data from the file is appended into a work table and held there. When the value is FEED, the data file will be loaded into the work table, then that data, and any data already held there, is processed creating JVs.
This job has another parameter, "data source", which has 3 potential values. Normally the value is "SFTP". The other values exist for IT to use when cleaning up load errors or processing older held data.
The afternoon process, BS_PCARD_INVOICE_M_F, always runs the same processing any documents which are available and ready. There are no parameters to change.
What to do
Near the end of each calendar month, triggered by closing of the bank’s reconciliation cycle, we must change the data action from FEED to HOLD. For normal months, which are end of July/start of August through end of May / start of June, after the final run for the month has finished, the parameter is changed from HOLD back to FEED. End of June / start of July is a special case because of end of fiscal year. The change from HOLD to FEED is delayed until the end of period 12 which will generally be 7-10 days into July.
How to do it
In each case, the change of parameter will be accomplished by Business Services opening a help desk ticket in the Banner queue (recommend emailing email@example.com to do this) requesting that the “data action” parameter to BS_PCARD_RECON_LOAD_M_F be changed either from FEED to HOLD or from HOLD to FEED as appropriate.
If any card represented in the inbound file is not defined in FTMCARD, the whole day’s batch will be rejected, not just the transactions for undefined cards. If that happens, we must retry that day’s file after Business Services receives the needed information to define the card and enters it in FTMCARD.
If we are in normal FEED mode, only a single day’s file will reject and need to be retried once the missing card has been added to FTMCARD. If we have been in HOLD mode, then change to FEED, and there is even one transaction with an unknown card number, all of the accumulating files’ data will reject. The individual days’ files can be retried immediately except the file which rejected must wait until the missing card has been created.
When Business Services has added a missing p-card to FTMCARD and is ready for the rejected file to be retried, they will initiate a help desk ticket requesting loading of the missed file. This ticket should include the bank transaction date and the file date (typically 2 days later than the transaction date) of the previously rejected file.