ASAP Customer Advisory Board
|Linda Holiman||Sam Moore|
|Judy Sheppard||James Turner|
The 1031/Letter of Credit (LOC) enrollment process was automated in July 2011. The Department of State, Department of Energy, Centers for Medicaid Medicare Services, and Tri Care Management Activity were all using a manual procedure to enroll 1031/LOC recipients. Federal Agencies can now enroll their 1031/LOC Recipients through ASAP.gov.
ASAP’s backend functions and DB2 database are being moved from the Federal Reserve Bank mainframe environment to the Financial Management Service’s Treasury Web Application Infrastructure (TWAI) distributed environment over the next two years.
Currently, ASAP interface with FRB CA$HLINK for end of day settlement. ASAP reports SF 5515s Debit Vouchers (payments) and SF 215 Deposit Tickets (returns) to each agency’s ALC at the end of each day.
Beginning June 1, 2012, ASAP will no longer report SF 5515s and SF 215s to agencies’ ALCs through FRB CA$HLINK. The ASAP system will report detailed payment and summary accounting information to the PACER application. With this change, agencies will be receiving Schedule Number Reports from ASAP instead of SF 5515 and SF 215s.
The PACER interface will also change the way an agency reports ASAP transactions on the SF 224. Currently ASAP payments are reported as a negative collection. After the PACER interface, ASAP payments will be reported in the same way as regular Treasury disbursed payments.
Beginning June 2, 2012, a new report, The Schedule Number Transaction Report, will replace the Debit Voucher/Deposit Ticket Reports in ASAP.gov. A new “Agency Accounting Procedures for ASAP” guide explaining how to use the new report is available at www.fms.treas.gov/ASAP/ fpa_handbooks.html
The PACER interface will require that ASAP remove the existing “negative draw” functionality. Negative draws are currently used by Recipient Organizations to move money between two ASAP accounts when they are initiating a payment request. The negative draw results in collection transaction for one of the ASAP accounts. The PACER application cannot process the accounting required to reflect a collection as a part of a payment. Therefore, ASAP was required to remove the negative draw functionality and this was implemented in Release 12.0 on December 17, 2011.
There are no plans to reinstate the “Negative Draw” functionality. Agencies should consider allowing their Recipients to use Book Entry Adjustments to move money between ASAP accounts. Funds drawn erroneously can be returned through ASAP’s regular return processes or through the ACH Debit functionality.
In the past, ASAP’s ABA number was classified as a “Receiver” which allowed Recipients to return partial ACH payments to ASAP and allowed Financial Institutions to send ACH debits to ASAP. A new Treasury policy requires that all ABA numbers be classified as “Originator Only.” This means that ASAP’s ABA number will now reject any transaction received from a Financial Institution where the transaction is not in response to a payment or ACH debit previously originated by ASAP. Regular return items that comply with NACHA rules will be accepted and processed since these items are a response to a payment or an ACH Debit originated by ASAP.
The two main impacts of this change are that 1) the Treasury is protected from unauthorized debits and 2) Recipient can no longer return partial payments to ASAP because NACHA rules require a return item to be in the exact amount of the original item. Recipients that need to return a partial payment still have the option of sending a Type 1000 Fedwire payment to return the partial amount to ASAP. The Philadelphia Financial Center classifies returned payments back to the ASAP account.
ASAP is currently working on the GWA Requirements for capturing and reporting TAS/BETCs. In ASAP, agencies will be responsible for defining TAS/BETCs on every ASAP account. When a Recipient requests a payment, ASAP will apply the TAS/BETCs to the payment based on a distribution method defined on the account by the agency. At the end of the day ASAP will report the TAS/BETC distribution for the payment to the PACER application, which will forward the data to the Governmentwide Accounting system. The data will also be available to agencies in new end of day reports.
ASAP will be in compliance with the FMS mandate that all applications be ready to collect and report TAS/BETC information for each transaction in November 2012. All agencies will be required to provide TAS/BETC data by November 2014. As stated in the May 2, 2011, Memorandum to all Federal Agencies, the TAS/BETC functionality will be available in ASAP in November 2012. Between November 2012 and September 30, 2014, the use of TAS/BETC functionality will be optional for agencies; however, beginning October 1, 2014, ASAP will require the use of TAS/BETC functionality for all agencies.
The ASAP staff is in the process of creating a guide for GWA changes in ASAP. This guide will be made available to agencies in late spring.
GWA, SPS, ITS, and ASAP are in the process of developing joint training sessions to inform agencies of the TAS/BETC requirements and how it will affect the agencies. Details will be forthcoming this year on the joint training sessions that will take place from April 2012 to November 2012. The training sessions are being scheduled in various locations throughout the U.S. We are doing the training sessions jointly because the applications share some of the same users. GWA is also planning outreach activities to answer questions pertaining to TAS/BETCs and what is required to become a GWA Reporter.
Notification of the training sessions will be sent to agencies by their servicing RFC. Notification will be sent to the National/Headquarters Office as well as the Regions to insure that everyone is informed.
With the move of ASAP processes from a mainframe to a distributed environment as well as the need to capture and report TAS/BETC information, ASAP is converting all batch files for Accounts and Authorizations, as well as End of Day Reports, from a flat file format to an XML format. These new XML format will be implemented in the November/December 2012 timeframe.