Contents Show
When the End of Day process in the Scheduled Job Administration application module runs and processes a bank payment file, it must account for all payment records included on that file from the banking entity by posting each record to either the food instrument table or to the bank exception table. A record is said to be quarantined when it is posted to the bank exception table. The Bank Exceptions functionality in the Financial Management and Vendor application modules provides the user options to manipulate information in the exception records and food instrument records to resolve exceptions. Resolving the exception causes it to be written to history, removed from the exception table, and the correct food instrument record to be updated with payment information. In some cases, the user is not required to make any corrections in order to get the record posted from the exceptions table to the food instrument table. Other times, depending on the reason a record was quarantined, there are several options available to correct the exception record so that it can post to the food instrument table.
Sometimes no user action is required to resolve a bank exception. The record automatically posts in a subsequent End of Day run. An example of this is a payment record quarantined for the reason of "Paid without Issuance". Records having this reason code are written to the bank exceptions table with a "Y" in the Reapply indicator so that the next time End of Day runs, it will determine if the issuance record has been received and added to the food instrument table. The quarantined payment is posted and removed from the bank exceptions table automatically when an issuance record is found in the food instrument table. If there is still no issuance record found in the food instrument table when End of Day runs again, the quarantined record remains in the bank exception table and the cycle is repeated. End of Day will continually attempt to post a "Paid without Issuance" record until it is resolved. User intervention may be required at some point if the record remains unresolved for a period of time. "Paid without Issuance" entries are more common in the bank exception table when clinics check out and benefits are issued in a disconnected mode. Issuance done at a remote site is not posted until the clinic is checked in and End of Day runs. If a clinic remains checked out for more than a day, the benefit payment may clear the bank ahead of the issuance being posted. A bank exception payment record of this type is usually resolved within a few days as soon as there is an issuance record available.
If a bank exception record does not automatically post to the food instrument table on a subsequent run of End of Day, the user should intervene and take the appropriate action to resolve the bank exception. Depending on who within the state office staff is responsible for monitoring the exceptions, SPIRIT provides the Bank Exceptions screen in the Financial Management application module and the Bank Exceptions screen in the Vendor application module for this purpose. The screen is accessed via the Bank Exceptions menu option on the Activities menu (Financial Management) and the Activities menu (Vendor). In either application module, the user must have the appropriate permission level to perform actions related to bank exceptions. The screen provides the capability to perform the following functions to resolve bank exceptions:
Manually correct and post bank exceptions to the food instrument table.
Reverse (un-post) a bank payment transaction previously posted to a record in the food instrument table.
Exchange (swap) a bank exception record with a food instrument record that has already had a payment posted.
In order to adequately address the topic of managing bank exceptions, it is helpful to begin with a definition of relevant terms that will be used in the explanation.
In order to adequately address this advanced concept, it is helpful to begin with a definition of relevant terms that will be used in the explanation.
The database table used to store individual benefits records for benefits that have been issued to participants.
The entry or row in the food instrument database table where specific information is held for each benefit issued to a participant. The unique identifier for each food instrument record is the serial number or benefit number assigned when the issuance is completed.
The database table used to store payment records that cannot be posted to the food instrument record when a daily bank payment file is being processed.
The entry or row in the bank exception database table where specific bank payment records are held or quarantined until they can be reviewed, researched, and modified before being posted to the food instrument table.
The database table used to store bank exception records that have been moved out of the bank exception table as a result of being resolved or changed.
The process of applying a quarantined bank payment record from the bank exception table to the food instrument table.
The process of removing payment information previously posted to a record in the food instrument table and creating a bank exception record with the information that was removed.
The process of exchanging a quarantined bank payment record from the bank exception table with a payment that was previously posted to the food instrument table.
One of the steps in the End of Day process is to apply bank payment records to their associated food instrument records. When a benefit is issued, the food instrument record is written to the food instrument database table. All issuance related information is populated at that time. However, columns related to payments are not populated when the food instrument record is initially written. One exception is direct ship benefits which are considered paid at the time of issuance. Typically, the presentment amount, paid amount, paid date, vendor stamp number, vendor ID, and peer group columns are populated at the time the payment is posted during bank payment file processing. The value of the issued code column is changed to "P" to indicate the payment has occurred. If for some reason, the SPIRIT system cannot post a payment to its associated food instrument record, it saves the payment information in the bank exception table. The category "BnkExcptReason" in the Reference Dictionary database table contains the reasons why a bank payment could be quarantined in the bank exception table. Examples include having an invalid or missing paid date, a missing paid amount, an invalid vendor ID, or an invalid vendor stamp number.
All bank payment records are accounted for either by posting to the food instrument record or storing the payment in the bank exception table. This approach keeps payments posted in SPIRIT in balance with bank totals. Payments recorded in SPIRIT during a month must match the bank file totals for that month before the End of Month Processing batch job can be scheduled.
When a bank payment file is being processed either by End of Day or by posting it manually, SPIRIT writes a bank exception if:
A bank payment has already been posted to the food instrument (issuance) record.
No food instrument record is found that matches the serial number in the payment record. The repost indicator will be set to "Y" in the bank exception record so that End of Day will try to post it automatically as soon as the issuance information has been added to the food instrument table. Typically, no manual intervention is required to resolve this type of bank exception.
Business Rule: BankEx_AllowPostToVoidedFI is set to "N" and a payment record is sent from the bank for a previously voided food instrument, End of Day will write the payment record to the bank exception table and will not post the payment to the voided food instrument. The bank file name will be valued in the exception record being added.
The payment record meets one of the posting error conditions defined in the BnkExcptReason category of Reference Dictionary.
End of Day will attempt to apply records in the Bank Exceptions table marked as Reapply = "Y" the next time it is run. Records that post to the food instrument table successfully will be written to the bank exception history table and removed from the Bank Exceptions table.
End of Day will send e-mail notifications to specified users when the bank payment file processing portion of End of Day has finished. The Notification List screen in the Reference Utility application module should be used to specify users who will receive the e-mail notifications.
The Bank Exceptions screen, as mentioned earlier, may be accessed from either the Vendor or Financial Management applications within SPIRIT. It allows the user to search for records in the bank exception table and perform the functions listed in the bullet points below. Each is accessed by activating a button on the Bank Exceptions screen. The first three do not require that a search of bank exception records be done before they are available. In order to Export to Excel or Resolve an exception, a search must be performed so that records are available in the data grid before the buttons become enabled.
Bank Reconciliation
Process Banking File
Exception History
Export to Excel
Resolve Exception
Post to Food Instrument (Post a corrected payment record to the food instrument table)
Unpost Food Instrument (Reverse a payment after it has been applied)
Swap with Food Instrument (Exchange an exception record with the payment information previously posted to a food instrument)
The search capability along with each of these processes is described in more detail in the following sections.
The user may look for one or more records in the Bank Exceptions table by completing the search criteria and activating the Search button on the Bank Exceptions screen. Search criteria include:
The serial number of the benefit to look up. The bank exception record with the specified serial number will be returned in the results.
A from/to date range. Bank exception records, having a paid date within the range inclusive, that also match other search criteria will be returned in the search results.
A specific reason for which the record(s) were quarantined. Bank exception records with the specified reason code that also match other search criteria will be returned in the search.
A from/to date range. Bank exception records, having a quarantine date within the range inclusive, that also match other search criteria will be returned in the search results.
A radio button group used to select the type of records returned in the search. Quarantined records may have a status of active or inactive. The user may choose to return only active records from the bank exception table, only inactive records, or both. The default selection is to return only active records. But, the user may change the selection by activating either the Inactive or the All radio button.
Bank exception records are returned if they match all of the specified search criteria and details about the payment as it resides in the bank exception table are provided in the Bank Exceptions data grid. Grid columns include:
The serial number associated with the quarantined bank payment.
The description from Reference Dictionary that correlates to the BnkExcptReason code in the bank exception record. This is the reason a bank payment could not be posted to the food instrument table, not a bank rejection reason.
The stamp number of the vendor where the benefit was redeemed.
The date the benefit was paid by the bank.
The date the bank payment record was written to the bank exception table.
The indicator used by End of Day to determine whether to attempt to post the record from the bank exception table to the food instrument table.
The status of the bank exception record; it may be active or inactive.
The name of the bank payment file containing the payment record that was quarantined.
The Bank Reconciliation button on the Bank Exceptions screen provides a way for the user to view summary and detail data for use in bank reconciliation activities. When the button is activated, the Bank Reconciliation screen is displayed. The user will be able to enter criteria to select the bank reconciliation (payment information) to be viewed and specify whether they want to see the results in detail or summary format. The user may choose to include bank exceptions in the results by checking the Include Bank Exceptions check box before activating the Run button. The results displayed in the data grid can be exported to Excel by activating the Export to Excel button on the Bank Reconciliation screen. The Bank Reconciliation button is visible and enabled when the Bank Exceptions screen is active and data is available in the results data grid. It has a mnemonic of "B".
Activating the Run button causes the system to search for and return data matching the criteria entered by the user. The results data grid contains 5 columns of data. The column contents are:
The month when the payment occurred if the Summary radio button is selected or the date when the payment occurred if the Detail radio button is selected. It is either the month portion of the paid pate of the benefit or the full paid date depending on whether the results is being shown in Summary or Detail form. This value will appear on multiple rows in the results data grid if the benefits redeemed within the report period have differing first date to use values.
The month when the participant can begin using their benefit. It is the month portion of the first use date of the benefit.
The sum of paid amounts for benefits paid in the Report Period and having a first date to use in the Begin Month.
The count of benefits paid in the Report Period and having a first date to use in the Begin Month
An indicator of whether the row in the results grid represents records from the Bank Exception table or not. It will contain either "Yes" or "No". If the Include Bank Exceptions check box is unchecked, the value in this column will be "No" for all rows. If the Include Bank Exceptions check box is checked, the value in this column will be "Yes" if the data in that row represents information from the Bank Exceptions table.
The Process Banking File button on the Bank Exceptions screen provides a way for the user to manually process a bank payment file that has not yet been applied through End of Day. When the button is activated, the Process Banking File screen is displayed. A "state" and a file date must be specified. Sometimes the state is shown as a label only and sometimes the user must select a state from a drop-down list box depending on whether the application server is shared or used by only one state entity. A standard error message will alert the user if the system cannot find a bank file for the date selected. Payment records from the selected file are either posted to the associated food instrument record or quarantined to the bank exception table when the process runs. If the state has set up e-mail notifications (Reference Utility/Notification List) to be sent when bank exceptions are written, they will be sent during the manual process. The Process Banking File button is visible and enabled when the Bank Exceptions screen is active. It has a mnemonic of "P".
Bank exception history contains a record for each modified or resolved bank exception record. A record is written to this table whenever a record is removed from the bank exception table because the issue with it was resolved and it was posted to the food instrument table. The interface allows the user to view bank exception history records via the Exception History button on the Bank Exceptions screen. The Exception History button is visible and enabled when the Bank Exceptions screen is active. It has a mnemonic of "H".
Accessing bank exception history is very similar to accessing bank exceptions. The search criteria are the same as for the bank exceptions with one difference. The Action is selected from a drop-down list boxt instead of a radio button selection. The content of the results data grid is nearly identical between the bank exception and bank exception history functionality. The two differences are that the Exception History results data grid contains two additional column. They are:
The date the bank exception history record was written.
The action taken by the user to resolve the bank exception.
The search results can be exported to Excel by activating the Export to Excel button on the Exception History screen. There must be at least one record in the Exception History results data grid to use the Export to Excel button.
Activate the Resolve Exception button to display the Resolve Exception screen. Several functions are available on the Resolve Exception screen to aid the user in resolving the selected exception record. The button is visible and enabled when the Bank Exceptions screen is active and a record is selected in the Bank Exceptions data grid. The mnemonic for the button is "V".
The Resolve Exception screen is divided into two sections, bank exception and food instruments. If the system detects both a bank exception and a food instrument record for the same serial number, both the bank exception section and the food instruments section of the screen will contain data when the Resolve Exception screen is first displayed.
The information related to the Bank Exception is contained in the upper part of the screen. Some of the information is static. Exception Reason, Quarantine Date, and the name of the Banking File containing the payment that was quarantined cannot be modified. Other information related to the bank exception including Benefit Number, Stamp Number, the Reapply indicator, the Active flag, the Paid Date, and Paid Amount may all be changed. It is the responsibility of the user to research the exceptions and make appropriate corrections to allow the payment to post to the food instrument table. If the only problem with the exception record is that one or more of these values is incorrect, the user may make changes, verify that the Reapply check box is checked, and activate the Save button. This will cause:
The bank exception record in its initial form to be written to the exception history table with an action code equal to the external ID of the "BNKEXCPTACTION" Reference Dictionary category with a description of "Edit" and a history date equal to the system date.
The bank exception table to be updated with the new information so that the corrected exception record is set for processing in the next End of Day run. This is the simplest type of bank exception resolution. One use for this type of resolution might be to correct an invalid stamp number sent in the payment record.
Sometimes a quarantined record cannot be resolved by simply changing it. If, for example, a food instrument has previously had a payment posted to it and the exception was written because a second payment for the same serial number was sent from the bank, more investigation may be required before the situation is resolved. It may be necessary to look at the food instrument record with the same serial number as the quarantined payment. Information about it would be defaulted into the food instruments section when the screen is displayed. If the user wants to look at information related to different food instruments, the user is able to search for a single or multiple food instruments by keying search criteria in one or more of the available controls and activating the search button. A standard error message is displayed if the system returns over 1000 records in the food instrument search. Only the first 1000 records are displayed after the message is dismissed. The user may refine the search criteria to reduce the number of returned records.
The functions available from the Resolve Exception screen are Unpost Food Instrument, Post to Food Instrument, and Swap with Food Instrument. Each is accessible from a command button.
Activate this button to reverse a payment that was previously applied to the Food Instrument table and write the information as a new record in the bank exceptions table. Only food instruments with a paid date can be "un-posted". The button is available when the screen is active and a food instrument record is selected in the Food Instruments data grid. The mnemonic for the button is "U".
The system will display a standard error message if the selected food instrument has not been previously paid. Otherwise, the system will add a bank exception record containing the payment information of the payment being removed from the food instrument. Then, it will update the food instrument record by removing any data related to the payment being "un-posted". Once processing has completed, the user is returned to the Resolve Exception screen and the data grid on that screen will reflect the removal of payment information from the food instrument record. Paid date and paid amount will be blank after the un-post function is complete.
Columns will be populated in the Bank Exceptions record as noted below.
SerialNo -- SerialNo from the Food Instrument table
PaidDate -- PaidDate from the Food Instrument table
PaidAmt -- PaidAmt from the Food Instrument table
PresentmentAmt -- PresentmentAmt from the Food Instrument table
StampNumber -- StampNumber from the Food Instrument table
ProgramCode -- ProgramCode from the Food Instrument table
PaidInd -- "Y" if PaidDate is not null (this always should be the case when removing payment information from a food instrument record); "N" if PaidDate is null
ReapplyInd -- "N"
CreateUserID -- User ID of the signed on user who is doing the reversal (un-post)
CreateDtTm -- Current system date and time
ModifyUserID -- Null
ModifyDtTm -- Null
Paid information will be removed from the Food Instrument record for the selected benefit number.
The following columns will be set as indicated to complete the reversal (un-post of payment data).
IssuedCode -- Set to "I"
PresentmentAmt -- Set to Null
PaidAmt -- Set to Null
PaidDate -- Set to Null
Reconciled -- Set to "N"
StampNumber -- Set to Null
VendorID -- Set to Null
PeerGroup -- Set to Null
ModifyUserID -- Set to User ID of the signed on user doing the reversal (un-post)
ModifyDtTm -- Set to current system date and time
Activate this button to post the selected bank exception record to the record selected in the Food Instruments data grid. The system will determine if the business rule BankEx_AllowPostToVoidedFI is set to "Y" or "N". If it is set to "Y", the system will post the payment to the food instrument regardless of whether the food instrument selected has previously been voided. However, if the business rule is set to "N", the system will display a standard error message and will not apply the paid information from the bank exception record to the voided food instrument record. When the state has the business rule set to "N", the exception record should probably be manually marked as inactive so that it can remain in the exception file and be separated from entries that still need resolution. If the system posts the payment from the exception to the food instrument table, the bank exception record will be deleted and a copy of it written to the bank exception history table for audit purposes. Once processing is complete, the Resolve Exception screen is dismissed and the user is returned to the Bank Exceptions screen.
The following data changes occur:
Bank Exception information is written to the Food Instrument record for the selected benefit number.
The following columns are set as indicated to complete the posting of the payment.
IssuedCode -- Set to "P"
PresentmentAmt -- Set to the Presentment Amount from the Bank Exceptions table
PaidAmt -- Set to the Paid Amount from the Bank Exceptions table
PaidDate -- Set to the Paid Date from the Bank Exceptions table
Reconciled -- Set to "Y"
StampNumber -- Set to the Stamp Number from the Bank Exceptions table
VendorID -- Set to the Vendor ID from the Stamp Number table that matches the stamp number from the Bank Exceptions table
PeerGroup -- Set to the Peer Group from the Vendor table that matches the Vendor ID
ModifyUserID -- Set to User ID of the signed on user doing the reversal (un-post)
ModifyDtTm -- Set to current system date and time
Information from the selected exception record being posted to the food instrument table is written to the bank exception history table for audit purposes.
The Bank Exception History record contains the following information:
SerialNo -- SerialNo from the Bank Exception table
PaidDate -- PaidDate from the Bank Exception table
PaidAmt -- PaidAmt from the Bank Exception table
PresentmentAmt -- PresentmentAmt from the Bank Exception table
StampNumber -- StampNumber from the Bank Exception table
ProgramCode -- ProgramCode from the Bank Exception table
PaidInd -- "Y" if PaidDate is not null (this should always be the value when posting to the FI table); "N" if PaidDate is null
ReapplyInd -- "N"
CreateUserID -- User ID of the signed on user who is doing the post
CreateDtTm -- Current system date and time
ModifyUserID -- Null
ModifyDtTm -- Null
History Date -- Set to the current system date
Action -- Set to the External ID from Reference Dictionary category of "BNKEXCPTACTION" where the description is "Post"
Delete the selected bank exception payment record that has been posted to the food instrument table and written to the bank exception table.
Activate this button to swap the exception information with an existing paid food instrument record. The user must select a single bank exception record and a single food instrument record with different serial numbers to be able to "swap" the records. This process moves the bank exception payment information to the food instrument record and creates a new bank exception record with the original payment information from the food instrument table. The original bank exception record is written to the history table for audit purposes and is deleted once it is posted to the food instrument table.
The user must select a row from the Food Instruments data grid and have an exception record displayed in order to complete the swap. The system provides a standard error message if the food instrument selected has not been paid. If an error occurs, no movement of data occurs. The user is returned to the Resolve Exception screen when the system has completed the swap of the two records.
A successful swap causes the following data changes to occur:
Columns will be populated in the Bank Exceptions record as noted below.
SerialNo -- SerialNo from the Food Instrument table
PaidDate -- PaidDate from the Food Instrument table
PaidAmt -- PaidAmt from the Food Instrument table
PresentmentAmt -- PresentmentAmt from the Food Instrument table
StampNumber -- StampNumber from the Food Instrument table
ProgramCode -- ProgramCode from the Food Instrument table
PaidInd -- "Y" if PaidDate is not null (this always should be the case when removing payment information from a food instrument record); "N" if PaidDate is null
ReapplyInd -- "N"
CreateUserID -- User ID of the signed on user who is doing the reversal (un-post)
CreateDtTm -- Current system date and time
ModifyUserID -- Null
ModifyDtTm -- Null
Information from the selected exception record being posted to the food instrument table is written to the bank exception history table for audit purposes.
The Bank Exception History record contains the following information:
SerialNo -- SerialNo from the Bank Exception table
PaidDate -- PaidDate from the Bank Exception table
PaidAmt -- PaidAmt from the Bank Exception table
PresentmentAmt -- PresentmentAmt from the Bank Exception table
StampNumber -- StampNumber from the Bank Exception table
ProgramCode -- ProgramCode from the Bank Exception table
PaidInd -- "Y" if PaidDate is not null (this should always be the value when posting to the FI table); "N" if PaidDate is null
ReapplyInd -- "N"
CreateUserID -- User ID of the signed on user who is doing the post
CreateDtTm -- Current system date and time
ModifyUserID -- Null
ModifyDtTm -- Null
History Date -- Set to the current system date
Action -- Set to the External ID from Reference Dictionary category of "BNKEXCPTACTION" where the description is "Swap"
Bank Exception information is written to the Food Instrument record for the selected benefit number.
The following columns are set as indicated to complete the posting of the payment.
IssuedCode -- Set to "P"
PresentmentAmt -- Set to the Presentment Amount from the Bank Exceptions table
PaidAmt -- Set to the Paid Amount from the Bank Exceptions table
PaidDate -- Set to the Paid Date from the Bank Exceptions table
Reconciled -- Set to "Y"
StampNumber -- Set to the Stamp Number from the Bank Exceptions table
VendorID -- Set to the Vendor ID from the Stamp Number table that matches the stamp number from the Bank Exceptions table
PeerGroup -- Set to the Peer Group from the Vendor table that matches the Vendor ID
ModifyUserID -- Set to User ID of the signed on user doing the reversal (un-post)
ModifyDtTm -- Set to current system date and time
Delete the selected bank exception payment record that has been posted to the food instrument table and written to the bank exception table.
|
Software Version: 2.40.00