DRAFT_FMSITSS_IDIQ_SOW_15_Feb_18.pdf
PDF 633 KB Posted
- Solicitation number
- APP_2017-0034
- Issued by
-
Pension Benefit Guaranty Corporation
About this file
DRAFT SOW as of 15 Feb 2018
View the file
Other files
Show all 16
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Page | 1
Financial Management Systems Information Technology Support Services (FMS-ITSS)
Single Award Indefinite Delivery/Indefinite Quantity (IDIQ)
Page | 2
Table of Contents
1.0 INTRODUCTION, BACKGROUND, AND OBJECTIVE 4
1.1 INTRODUCTION 4
1.2 BACKGROUND 5
1.3 OBJECTIVE 22
2.0 SCOPE 22
2.1 IDIQ CEILING 23
2.2 TYPE 23
2.3 PERIOD OF PERFORMANCE (POP) AND FUNDING STRATEGY 23
2.3.1 Contract POP 23
2.3.2 TO POP 23
2.3.3 TO Funding Strategy 23
2.4 PROGRAM AND TASK ORDER MANAGEMENT 23
2.5 TASK ORDER AREAS 24
3.0 FMS-ITSS TASK AREAS 26
3.1 PROJECT MANAGEMENT SUPPORT 26
3.1.1 Project Management 26
3.1.2 Change Management 27
3.1.3 Release Management 27
3.1.4 Demand and Backlog Management 27
3.1.5 Configuration Management 27
3.1.6 Issue and Risk Management 28
3.1.7 Status Reporting 28
3.1.8 Integrated Project Team (IPT) and Change Control Board (CCB) 29
3.1.9 Meeting Participation 29
3.2 SYSTEMS DEVELOPMENT AND ENGINEERING 29
3.2.1 Requirements Definition, Analysis and Specification 29
3.2.2 Design and Design Specification 30
3.2.3 Development (Prototyping, Coding and Configuration) 30
3.2.4 Testing 31
3.2.5 Implementation and Deployment 32
3.2.6 Operations Turnover 32
3.3 OPERATIONS AND MAINTENANCE 32
3.3.1 Tier-3 Technical and Operations Support 32
3.3.2 Enhanced Peak Period Support (i.e. fiscal-year end, peak premium filing season) 33
3.3.3 Maintenance/Emergency Release Development and Configuration 34
3.3.4 Infrastructure Impact Analysis, Testing, Remediation and Infrastructure Coordination 34
3.3.5 Integration Impact Analysis, Testing and Remediation 35
3.3.6 Financial and Enterprise Reporting 35
3.3.7 System Decommissioning 35
3.4 PROGRAM ANALYSIS AND ENTERPRISE ARCHITECTURE (EA) SUPPORT 35
3.4.1 Business Needs Analysis 35
3.4.2 Alternatives Analysis and Feasibility Studies 36
3.4.3 Technical Reference Model/Review Board (TRM/TRB) Support 37
3.4.4 Data Model Development and Maintenance 37
3.5 TRAINING 37
3.6 CONTINUITY OF OPERATIONS (COOP) SUPPORT 37
3.7 SYSTEM DOCUMENTATION, DOCUMENTATION MAINTENANCE AND TECHNICAL WRITING 38
3.7.1 FMS System Documentation and Documentation Maintenance 38
3.7.2 Technical Writing 38
3.8 DATA QUALITY MANAGEMENT 38
3.8.1 Data/File Migration and Conversion 38
3.8.2 Data/File Validation 39
Page | 3
3.9 DATA CALL AND AUDIT SUPPORT 39
3.10 PROFESSIONAL ADVISORY/CONSULTING SERVICES 40
3.10.1 Business Process Automation/Re-engineering 40
3.10.2 Financial System Analysis and Strategy 40
3.10.3 Technical Analysis 41
3.10.4 Special Studies 41
3.10.5 Staff Augmentation 41
3.11 IT SECURITY 41
3.12 TRANSITION SUPPORT 41
3.12.1 Transition from Incumbent 41
3.12.2 Transition as Incumbent to PBGC or new vendor 42
4.0 GENERAL INFORMATION 42
4.1 PLACE OF PERFORMANCE 42
4.2 CORE HOURS OF OPERATION 43
4.3 CONTINUITY OF SERVICES 43
4.4 SUBCONTRACTING 43
5.0 CONTRACT ADMINISTRATION 43
5.1 PERIOD OF PERFORMANCE 43
5.2 TASK ORDERS (TOS) AND ORDERING PROCEDURE 43
5.3 CONTRACT TERM AND RENEWAL 45
5.4 ROLES AND RESPONSIBILITIES 46
5.5 CONTRACTING OFFICER'S REPRESENTATIVE (COR) 46
5.6 CONTRACTOR ROLES AND RESPONSIBILITIES 47
5.7 INVOICES ERROR! BOOKMARK NOT DEFINED.
Page | 4
1.0 Introduction, Background, and Objective
The Employee Retirement Income Security Act of 1974 (ERISA) established Pension Benefit Guaranty Corporation (PBGC) as a federal corporation to encourage the growth of defined benefit pension plans, provide timely and uninterrupted payment of pension benefits and keep pension insurance premiums at a minimum. Defined benefit pension plans promise to pay a specified monthly benefit at retirement, commonly based on salary and years on the job. PBGC, a wholly owned United States Government Corporation, administers the insurance program and termination process for most defined benefit pension plans that are tax-qualified under the Internal Revenue Code.
1.1 Introduction
As reported in the 2017 Annual Report, the Pension Benefit Guaranty Corporation (PBGC) protects the pensions of nearly 40 million workers and retirees in more than 24,000 private defined benefit pension plans. The Corporation receives no funds from general tax revenues.
Operations are financed by insurance premiums paid by companies that sponsor defined benefit pension plans or from the plans’ assets, investment income, and assets from terminated plans.
PBGC administers two insurance programs. The single-employer program protects nearly 30 million workers and retirees in about 22,500 pension plans. Under this program, a company can voluntarily seek to terminate its plan using either a standard termination or a distress termination procedure. Additionally, PBGC may seek termination of a plan without the employer’s consent to protect the interest of the plan participants of the plan or of PBGC. PBGC must seek termination when a plan cannot pay current benefits. Ultimately, as a result of the termination of pension plans, PBGC pays benefits to participants and beneficiaries. In addition to the single-employer program, about 10 million people are covered by about 1,400 multiemployer plans.
PBGC is headed by a Director who is appointed by the President and subject to Senate confirmation. The Director reports to a Board of Directors consisting of the Secretaries of Labor (Chair), Commerce, and Treasury. General tax revenues do not fund PBGC. PBGC collects insurance premiums from employers that sponsor insured pension plans, earns money from investments and receives funds from pension plans it takes over. Information about PBGC can be found at: http://www.pbgc.gov/
PBGC is a leader among federal agencies achieving 25 consecutive years of unmodified audit opinions. To preserve this elite status, several opportunities exist to improve financial management in support of the PBGC Strategic Plan. These opportunities include focusing on the continued development of strategic resources in areas such as IT Security, Integrated Financial Systems that lead to greater operational efficiency, regulatory compliance, and the continued transformation of our IT Infrastructure Program to enable the implementation of new business solutions efficiently and securely.
http://www.pbgc.gov/
Page | 5
1.2 Background
In order to carry out its statutory mission, the PBGC relies on the Financial Operations Department (FOD) to administer and manage the Corporation’s financial and accounting programs and to prepare the financial statements for the Corporation. FOD is comprised of the following four divisions:
• Controller Operations Division (COD): COD’s mission is to manage the general and investment accounting programs of the Corporation. COD consists of the Financial Reporting and Accounting Analysis Group (FRAAG), which administers PBGC’s external financial reports and statements and responds to special PBGC financial reviews;
the General Accounting Branch (GAB), which administers the general accounting programs including vendor payments, benefit funding, and budgetary funds control for PBGC; and the Investment Accounting Branch (IAB), which performs accounting functions for plan assets PBGC receives from distressed or involuntarily terminated plans.
• Administrative Division (AD): AD’s mission is to plan and implement the administrative programs and services for FOD. In addition, AD manages PBGC wide programs for payroll, travel, and the mass transit benefit.
• Policies, Procedures and Control Division (PPCD): The PPCD’s mission is to manage and establish financial policies and procedures, maintain internal controls through the implementation of these policies and procedures, and ensure the integration of the Corporation’s financial systems. PPCD consists of the Financial Systems Branch (FSB), which oversees, coordinates, and controls the design, development, and maintenance of accounting and financial management systems and internal control processes; and the Corporate Financial Policies and Procedures Group (CFPPG), which develops, revises, implements, and communicates PBGC’s financial policies and procedures.
• Collection and Compliance Division (CCD): CCD’s mission is to administer PBGC’s premium program for the receipt, accounting, collection, and internal review of receivables including: PBGC insurance premiums, interest and penalties, ERISA Section 4071 penalties, and, to a much lesser extent, Due and Unpaid Employer Contributions (DUECs), employer liability under ERISA Section 4062, and participant recoveries. CCD consists of the Premium Operations Branch (POB), which focuses on management of premiums, and the Receivables and Analysis Branch (RAB), which manages and accounts for PBGC’s premium plan filings and payments. The Technical Enhancement Branch (TEB) within CCD is primarily responsible for oversight of the IT system requirements supporting the premium program.
PBGC’s Financial Operations Department (FOD) conducts premium processing operations to provide premium filing, collection and enforcement services to pension practitioners (e.g., plan administrators, plan sponsors, and actuaries) allowing practitioners to comply with premium filing and payment obligations (under Title 4 of ERISA). FOD’s premium operations staff also supports corporate-wide functions such as plan monitoring, plan auditing, standard terminations, legal claims, and FOIA (Freedom of Information Act) requests.
Page | 6
The primary services currently performed by PBGC’s premium operations staff include:
• Premium filings and payments processed
• Filing error notices issued
• Invoices and past due filing notices issued
• Penalty waiver and reconsideration responses
• Practitioner inquiry responses (calls, letters, and e-mails)
• Refunds issued
• Account histories issued
• Premium financial reports
• Premium operational status reports
The Business Innovation Services Department (BISD) provides IT support to PBGC departments throughout the Corporation. BISD leverages best practices and state of the art technology to deliver IT innovation to PBGC business operations and customer service. BISD provides IT program management, IT project management, and IT contract oversight services while establishing and utilizing proven implementation approaches to further business area goals.
Within BISD, the Financial Management Services Division (FMSD) provides overall IT support for financial systems and oversight of IT contracts supports those systems.
The following are the current FOD operations business processes and associated financial IT systems supporting those operations:
Premium Filing/Payment Receipt and My Plan Administration Account (MyPAA) FOD is responsible for the processing of premium filings and associated payments that (by law) are submitted each year to PBGC and, therefore, is the primary business owner of My Plan Administration Account (MyPAA). This web application enables premium filings and payments to be electronically submitted to PBGC and provides other related services (e.g., an on-line confirmation of receipt by PBGC and an option to view PBGC’s posting of a plan’s filings and payments (i.e., a plan’s account history). Information about PBGC’s MyPAA application can be found at: https://www.pbgc.gov/prac/prem/online-premium-filing-with-my-paa.html
MyPAA’s objective is to facilitate premium e-filings to be submitted properly (i.e., based on each year’s requirements) for every plan year starting 2004 to the present (because filings for all plan years may continue to be submitted). To meet this objective, MyPAA must continue to be maintained for every plan year (starting 2004) and must also be enhanced each year to incorporate the upcoming plan year’s requirements (without negatively impacting the submission of filings for prior plan years). Currently, all plans must electronically submit their yearly premium filings, in accordance with PBGC’s mandatory premium e-filing regulation which was effective for all plans for plan years beginning on or after 1/1/2007. While there are similarities, each plan year has unique requirements that must be maintained and not impacted when a new plan year’s requirements are implemented. The premium instructions that describe each year’s filing requirements (including illustrative forms) can be found at:
https://www.pbgc.gov/prac/prem/premium-filing-payment-and-instructions.html https://www.pbgc.gov/prac/prem/online-premium-filing-with-my-paa.html
Page | 7
In support of mandatory e-filing, My PAA must continue to offer a variety of electronic filing options to meet the business needs of the filing community, offer customer-friendly features, and comply with PBGC’s business and systems requirements (e.g., internal controls and auditing requirements). Enhancements must be determined to be cost-effective and must efficiently integrate with PBGC’s corporate systems and infrastructure. PBGC coordinates with private sector software vendors who market software products to practitioners and in-house developers of filing software (currently about five vendors/developers). Their software is typically purchased/utilized by practitioners to create filings for various federal agencies (e.g., PBGC, Department of Labor (DOL), and Internal Revenue Service (IRS). In order to be used for PBGC’s filings, PBGC must provide updated Extensible Markup Language (XML) schemas that vendors/developers use to update their software products to produce an XML document that conforms to PBGC’s requirements. Information regarding PBGC’s XML requirements and related information can be found at: https://www.pbgc.gov/prac/prem/filings/e-filing-resources.html
There are some primary differences between PBGC’s premium filings and other agency/company filings. For example, PBGC offers three e-filing methods (rather than only one method) and requires multiple e-signatures/authorizations for many premium filings (while other agencies typically require only one e-signature) – which results in routing and e-signature routines within My PAA. In addition, PBGC requires premium payments while other agencies do not typically receive payments with their filings – which results in various payment alternatives being offered (i.e., payments may be made within My PAA or outside of My PAA).
My PAA is a secure web-based application that enables pension plan professionals (e.g., plan administrators, plan sponsors, actuaries, and consultants) to electronically submit premium filings and associated payments to PBGC for plan years 2004 and later. My PAA is the customer-facing front-end to the premium processing system. My PAA transfers premium filing and payment data to the Premium and Practitioner System (PPS) for processing and posting to plan accounts. In addition, information about payments made via My PAA is passed along to PBGC’s bank via Automated Clearing House (ACH) transactions.
• My PAA Filing Options o Screen Prepared - My PAA’s data entry and editing screens may be used to create, edit, route, e-sign, pay (within My PAA or outside of My PAA), and submit premium filings to PBGC. The received filings are then transferred to the back-end premium system for processing and posting to the plans’ accounts.
o XML Import: Private-sector software may be used to create premium filings (files that meet PBGC’s XML standards). My PAA validates the structure of the XML file and imports the filings (individually or multiple filings within a batch) into My PAA’s data entry and editing screens for review/routing, editing, e-signature, payment (within My PAA or outside My PAA), and submission to PBGC. The received filings are then transferred to the back-end premium system for processing and posting to the plans’ accounts o XML Upload – Private-sector software may be used to create premium filings (files that meet PBGC’s XML standards) that are uploaded (individually or multiple filings within a batch) to PBGC via My PAA. My PAA validates the structure of the XML https://www.pbgc.gov/prac/prem/filings/e-filing-resources.html https://www.pbgc.gov/prac/prem/filings/e-filing-resources.html
Page | 8 file and transfers the filings to the back-end premium system for processing and posting to the plans’ accounts.
• My PAA also provides other on-line tasks and services to facilitate the completion of premium filings:
o Using My PAA’s data entry and editing screens, some fields may be pre-populated using information from a previous filing.
o For screen prepared filings and for XML imported filings, premium filers can keep track of the status of the filings for each pension plan and can access on-line filing receipts that reflect the filing data submitted. For uploaded filings, the uploader can access the on-line filing receipts. Plan account histories that reflect filings and payments submitted (as well as any amounts owed or overpaid) for each plan year, may be accessed using My PAA.
o My PAA also enables each filer to set up an account (e.g., user ID, password, and secret question/answer) in order to use My PAA.
o My PAA e-filing teams are set up by the designated plan’s “filing coordinator” (the person identified by the plan or sponsor to be responsible for coordinating the plan’s on-line premium filings). After the filing coordinator “Adds a Plan” to his/her account, the filing coordinator “invites” other practitioners to be part of the plan’s e-filing team and assigns each person the appropriate e-filing roles (e.g., to e-sign as the plan administrator).and the filing coordinator then makes the necessary updates as people change over time.
• MyPAA Premium Payment Options -o MyPAA Application: Premium payments may be made within My PAA (along with the associated filing) via Automated Clearing House (ACH) information and payment details. This information is routed via a secure FedACHService web service to the My PAA ACH processor, Pay.gov. NOTE: Only single-filing uploads may be paid within My PAA or outside of MyPAA. If a premium filing was uploaded to MyPAA, and contains multiple filings, each filing must be paid separately outside of My PAA.
o Outside of MyPAA Application: Premium payments may also be made outside of
MyPAA, directly with Pay.gov using ACH payment information, with or without an associated premium filing. Lastly, those practitioners who prefer to pay via wire transfer can also utilize Fedwire.
• My Plan Administrator Account (My PAA) Administrator Module - For internal management purposes, My PAA provides FOD with the My PAA Admin Module to facilitate the following administrative functions:
o Perform premium filing support activities and to access related reports o Support functionality for a user to set up an account (e.g., with a user ID, password and secret question/answer) and to make changes (e.g., to the user’s name and email address).
o Approve filing coordinator requests to “add a plan” to their accounts if their submitted data does not match the premium system data o Reset user passwords
Page | 9 o Assist filers if their filing coordinator has left the filing team (without designating another filing coordinator) o Access My PAA report data for daily monitoring activities (e.g., cash reconciliation).
• Technical Framework: My PAA is an n-tiered distributed web architecture and is logically divided into three main parts:
o Customer Module – public facing interface that PBGC’s practitioner customers use to submit premium filings and payments o System integration components – the use of Business Process Execution Language
(BPEL) and Web Services to submit filing transactions from My PAA to the Premium Accounting System.
o Admin Module – internal PBGC utility to allow FOD staff to provide support to practitioners using the Customer Module and to provide an interface to monitor operations
The My PAA system architecture was developed as a combination of .NET, Java Platform, Enterprise Edition (J2EE), and Oracle technologies. The system utilizes a combination of Extensible Hypertext Markup Language (XHTML), Java Server Pages (JSP), XML, Java, Visual Basic (VB), and service-oriented architecture (SOA) principles and methodologies.
The My PAA Customer Module is an n-tiered .NET application comprising of a presentation tier, business logic tier, and data tier. The customer module presentation tier is designed and developed utilizing Web based technologies including JavaScript, Asynchronous Javascript and XML (AJAX), XHTML, and VB coding principles. The presentation tier also uses cascading style sheets (CSS) with industry standard form controls provided by the Bootstrap front-end framework.
An XML validation utility is also provided for the practitioners and vendors, so they can make any updates to XML formatted filings prior to submitting to MyPAA via the import or upload function.
The MyPAA Vendor validator is an independent Web application module on the Java 2 Platform, Enterprise Edition (J2EE) Framework. Although not yet bundled with the Customer Module interface, the vendor validator is currently a stand-alone utility in the Production DMZ.
The data integration and middle tier consists of the Data Access Objects, for the transport of data between the different tiers, and Web services classes developed utilizing a combination of SOA principles to transport data between the presentation and business logic tiers.
My PAA Admin Module is an n-tiered application built on the Java 2 Platform, Enterprise Edition (J2EE) framework. The Web application is deployed on an Oracle application server that runs on a Linux server behind the PBGC firewall. The presentation tier consists of Java Server Pages (JSPs) and Java Servlets that are largely responsible for data display, data formatting and data capture functions. The business tier consists of JavaBeans that retrieve data and perform transactions on user entered data. The My PAA business tier connects to the database tier using Java Database Connectivity (JDBC).
Finally, the system also includes a Business Process Execution Language (BPEL) process that is deployed to separate Linux servers and is used to submit filings and payments submitted through
Page | 10 the My PAA application to the PPS system. The BPEL processor listens for filings placed on Oracle’s Advance Queue for processing, once these filings are placed on the queue the filings are processed by BPEL and submitted to PPS for processing.
• My PAA Integration with Premium and Practitioner System (PPS): Premium filings submitted through My PAA are automatically loaded into the back-end premium accounting system (through the use of web services) for processing and posting to plan account histories.
The PPS is the system of record for premium filings and payments received by PBGC for each plan year. PPS uses a web service to receive and validate the filing and payment information received from My PAA. It creates an image of the electronic data, processes filings and payments per normal procedures, computes any interest and penalty owed, and calculates overpayments (amounts owed to plans) and underpayments (amounts owed to PBGC for underpaid premiums or for late premiums). This information is included in the plan account histories and invoices that are issued for each plan year. In addition, the premium system determines whether filings are missing so that past due filing notices may be issued and reports may be generated that provide financial information for PBGC’s annual reports.
In addition to My PAA submitting the premium filings to PPS, there is additional interaction between the two systems. For example, when a filing is created via the My PAA data entry and editing screens, My PAA uses a web service to request plan information PPS and automatically prepopulates some form fields (e.g., address information) to make it easier for filers to create a new filing. Also, after this screen prepared e-filing is submitted, an online receipt is generated that includes the submitted filing information and the date and time of receipt by PBGC. The date and time is also used by the premium system for its date-related processing functions. In addition, after a filing is submitted and posted to the plan’s account history (which shows the filing information, any late payment charges, and any overpayments and underpayments for each plan year), the account history from PPS is available as a web service to My PAA for online filer access. Additionally, enhancements are planned to increase the information provided to premium filers by MyPAA as sourced from PPS as well as additional means of correspondence and communication between FOD and premium filers.
Premium Filing Processing/Validation, Premium Accounting, Plan Administration and Premium and Practitioner System (PPS)
FOD processes premium filings and payments to prepare financial statements and administer the Corporation’s financial and accounting programs. FOD currently uses the Premium and Practitioner System (PPS) to automate the filing processes and facilitate premium filing, collection, and enforcement services. PPS is effectively PBGC’s accounts receivable sub-ledger for premium payments as well as processor for premium filings and plan management. PPS replaced the legacy Premium Accounting System (PAS) in December 2013.
PPS represents a hybrid between legacy, custom-Java coded PAS components and new Oracle E- Business Suite (EBS) COTS components that have been customized for PBGC premium operations. EBS was upgraded to Release 12.1.3 (R12) in August of 2014 with plans to upgrade again in the near future. The majority of PPS reporting is done via Oracle XML and BI Publisher. The legacy PPS components use Oracle Forms 10g, Reports 10g, PL/SQL, JAVA and J2EE (on middle tiers) to process filing information and to calculate the premium, interest, and
Page | 11 penalties due from defined-benefit pension plans. It also applies the cash received from each plan against amounts due to PBGC and generates plan specific Statement of Accounts (SOAs) for unpaid premiums, interest, and penalties. It generates Past Due Filing Notices (PDFNs) to be sent to those plan administrators who fail to file. These middle tier servers utilize an RHEL operating system along with Oracle Weblogic.
PPS requires skilled, technical services to resolve production issues, provide subject-matter expertise, and ensure that the PPS system remains operational and effective in supporting FOD business processes, premium operations, and accounting and reporting of premium financial transactions.
The PPS O&M team should be familiar with the following technologies that make up the system:
• Oracle E-Business-Suite (EBS) Release 12 including: TCA Module, CRM Teleservices
Module, GL Integration, AP Processes
• Oracle EBS Forms and Reports
• Oracle BI Publisher
• Oracle Weblogic server
• Oracle Rules Engine
• Java Web services
• Oracle 11g/12C database administration
• UNIX shell scripting and cron jobs
• Java/J2EE
• PL/SQL
• Spring Framework
• iBatis
• Oracle ADF
• JAX-WS JAXB
PBGC developed PPS using a phased approach to deliver desired features within the following four releases:
• GL Interface Release (Released May, 2013): The GL Interface Release was a custom program and supporting components that transfers journal entries from PPS to the CFS. The effort included application flows (both manual and programmatic steps), the definition of custom forms and reports, details on Oracle E-Business Suite 11.5.10 configuration, and the definition of interface components including source to target table mapping and processing rules
• 2014 Filing Changes Release (Released in December, 2013) - 2014 Filing Changes Release: The objective of the 2014 Filing Changes was to enhance the PPS 2.0 system by implementing the 2014 filing and processing changes and to maintain the operational stability and performance of the system in the production environment. Because of regulatory changes approved by the Office of Management and Budget (OMB), changes were implemented as configurable rule sets to be turned on for PYC 1/1/2014, or later, depending upon the outcome of OMB’s process.
Page | 12
• Trading Community Architecture (TCA) Release (Released in December, 2013) - The TCA Release implemented and integrated modernized components of PAS (e.g., PAS data model, forms, reports, and premium, interest, and penalty calculation engines) with a solution for the recording of PBGC’s business data (Plan, Plan Years, Sponsors, Administrators, Contacts, Transfers, etc.) within Oracle’s E-Business Suite TCA Model. Oracle Trading Community Architecture (TCA) is a data model that allows the management of complex information about parties who belong to a trading community, including organizations, locations, and the network of hierarchical relationships among them.
• Customer Relationship Management (CRM) Release (Released in April, 2014) -The CRM release implemented Oracle CRM configurations and customizations, reintegrated PPS 1.0 CRM customizations to point to PAS screens, and develop additional PPS integration points with interfacing systems. Oracle service requests (SRs) are be automatically generated based on the information provided on a filing and assigned to analyst. The types of service request that will be automatically generated include refunds, requests-for-refunds, suspense processing, credit carry forward, etc.
The following diagram shows the business operations flow through the PPS system components:
Analyst will enter additional information using modified suspense screens, modified CA forms and
COTS DFF
Receive & Review Customer Communication /
Correspondence (Email, Fax, Phone)
Assign and Review Service Request
Fed Debt
Manual
CRM Module IPS
Send Letter Generation Request to
CCS
Create Service Request
Perform Analysis and Add Aditonal
Details
Generate Letter
TCA
RelationshipPlan YearsPlan
Transaction Approval Process
Close Service Request
N
CFS - AP
CFS - GL
Pre Processor
Cash Receipts & Validation
Data Validation
Error ?
Call SR Creation
API
ERISA
Mini-ERISA
Premium Calculation
Estimated Filing Processing
Final Filing Processing
Payment Processing
PDFN
ProcessingSOA Processing
Due Dates Algorithm
Premium Algorithm Penalty
Interest
Other Transactions
EIN-PN Change
Mergers, Spinoffs, and Consolidations
Terminations
SOA
Grace PeriodPremium
Proration Algorithm
Automatic Credit Carry
Forward
TCA Plan Management
Temp Table
Journal Entries
N
Refunds Interface
GL
Interfaces
Automated
Data from CMS and 5500 Interfaces
IPS
Letter Approval Process
CIR
Image indexed to
IPS
Actionable Doc Type?
Y
N
User uploads or indexes image in IPS
BoA Lockbox
MyPAA
Page | 13
The following provides a brief description of the PPS automated interfaces.
• My Plan Administration Account (MyPAA): The MyPAA interface enables PBGC to send filings collected in MyPAA to the PPS solution. Filings are interfaced through a PPS hosted web service. Additional webservices between the systems are discussed above.
• Customer Correspondence System (CCS): The PPS letter generation components interface with CCS to generate and print SOA, PDFN and NFE letters. The program specifies letter contents and letter templates and uses an CCS hosted web services to interface letter data to the CCS solution.
• Image Processing System (IPS): Interfaces images of filings and payments to the Image Process Systems (IPS) for storage, using web services. The PPS solution also enables end-users to open and view filing and payment related images stored on IPS.
• Bank of America (BOA): The PPS solution receives payment files (from check deposits) from BOA through an automated SFTP process. The PPS preprocessor loads and processes theses files. This is being replaced by another interface for Lockbox receipt of payments and correspondence.
• Department of Labor ERISA Filing Acceptance System II (DOL EFAST2): Form 5500 data is provided from the DOL to the solution for matching purposes. Data is sent through flat files that are transferred to a file server via SFTP.
• Case Management System (CMS): The CMS Interface enables the processing of information related to Coverage Determinations, Plan Terminations, Trusteeships, and Bankruptcy cases managed within the CMS system.
• Risk Management and Early Warning (RMEW): The RMEW interface extracts Single Employer and Multiemployer premium filing data from the solution for use in CFRD actuarial PPS calculations for the yearly contingency list, and for assessing the health of the plan.
• Corporate Performance Reporting System (CPRS): CPRS is an automated warehouse that provides historical premium and plan filing information and plan termination information for reporting, research, and analysis.
• Corporate Data Management System (CDMS): CDMS is an automated warehouse that provides historical premium and plan filing information and plan termination information for reporting, research, and analysis.
• Treasury’s FedDebt: Provides payment information for any debt owed to PBGC that was referred to FedDebt for delinquent collections and that they successfully collected. New functionality is now in development that will also automatically refer new delinquent debt to FedDebt. The interface transfers flat files through Direct:Connect software.
Page | 14
• Treasury Collections Information Repository (CIR): A daily extract file, transferred by VPN, provides payment information for different types of Treasury payment sources including Pay.gov, Credit gateway-ACH, Credit Gateway-Fedwire and Bank of America. Along with other attributes of transaction such as Transaction date, Amount, EIN/PN/PYC, the extract captures the status of each transaction (e.g., Settled and Returned).
• PBGC IPVFB: IPVFB is an actuarial valuation system used to determine the PBGC’s Present Value of Future Benefits liability. IPVFB uses PPS data to support the Actuarial Services Department in reviewing Nonseriatim (NS) Multiemployer (ME) data submitted through form 5500 filings with the Department of Labor (DOL) “EFAST” system.
Financial Accounting, Financial Management, Financial Statement Generation and Consolidated Financial System (CFS)
FOD is responsible for all PBGC financial accounting, financial management and financial statement generation. Supporting all of these activities is the CFS system. CFS is a major information system within FOD and is an essential application for Continuity of Operations Plan (COOP) purposes. The CFS addresses the PBGC’s budgetary, fiscal, financial, management, and reporting needs for the enterprise revolving fund, trust accounting, and consolidated financial operations. The following diagram shows the high-level architecture of the CFS system and its internal/external interfaces:
The CFS is comprised of the following systems:
• The Consolidated Financial System Revolving Fund System; and
Consolidated Financial System
(CFS)
Oracle EBS 12.1.3
Oracle 11g RDBMS
Revolving Fund (GL,PO,AP, Fed
Admin, DATA Act)
Trust Accounting Fund
(GL)
Consolidation Ledger
(GL) Web ADI
Premium Feeder Systems
PPS
My PAA
CFS
Trust Account System
TAS
Revolving Fund Feeder Systems
Concur Interface
(BPEL)
Comprizon Interface
Invoice Automation Payroll Interface
Treasury SPS
Comprizon
From DOI FPPS System
Concur
Budget Interface
Page | 15
• The Consolidated Financial System Consolidated System.
Each of these components is described in greater detail below:
• The Consolidated Financial System Revolving Fund System - The General Accounting
Branch (GAB) is the primary user of the CFS Revolving Fund System. It is comprised of the following subsystems:
o Oracle Federal Financials for Revolving Fund Accounting; Oracle Federal
Financials Revolving Fund is a set of functionality based on the Oracle Federal Financials Commercial Off-the-Shelf software package, Oracle e-business Suite, version 12.1.3, and running on the Oracle Relational Database Management System 11.2.0.3 (to be upgraded to 12c). The Revolving Fund system records budgetary, administrative and operational transactions associated with PBGC’s revolving fund accounts. The Revolving Fund system is a major information system and is identified as an essential application for Continuity of Operations Plan purposes. The Revolving Fund system is comprised of the following Oracle Federal Financial modules: Oracle General Ledger, Oracle Financial Statement Generator, Oracle Federal Administrator, Oracle Purchasing, Oracle Accounts Payable and Oracle HR (employee table maintenance only) modules along with Oracle’s Mass Allocation and Cross Validation functionality and Oracle’s Systems Administration functionality. The Revolving Fund system is mainly used by the General Accounting Branch (GAB), Budget Department, Budget Liaison Officers and Contracting Officer’s Representatives. The Revolving Fund system is a subsidiary ledger to the PBGC’s consolidated financial reports. The CFS Revolving Fund system supports single year and multi-year funds. There are approximately 300 active users in the system. The CFS Revolving Fund system utilizes standard, customized and Financial Statement Generator reports. There are approximately 75 custom oracle reports and Financial Statement Generator reports currently in use. The Revolving Fund system incorporates certain custom extensions, objects, code and personalized forms to assist with user needs and further enhance security and internal controls.
o DATA Act Reporting: An integrated Processing solution within CFS, which enabled PBGC to fully meet DATA Act requirements; including ingesting required data, transforming data to meet standards, storing/archiving data, reconciling data inputs, and reporting required data to the US Treasury. This reporting was operationalized in April-2017.
o Government-wide Treasury Account Symbol Adjusted Trial Balance System (GTAS) Functionality – PBGC has implemented Oracle GTAS patches to ensure continuation of vendor support, product upgradability and it also provides PBGC the opportunity to automate and improve the reporting processes, by furthering the use of CFS as the prime application for government reporting. GTAS and existing FACTS II reporting is currently executed outside of the CFS application.
With implementation of the GTAS patches in January-2018, PBGC is planning to leverage the automated GTAS Bulk File generation from within the COTS product.
Page | 16
• Web Application Desktop Integrator (Web-ADI) for Revolving Fund Accounting; The Application Desktop Integrator is an automated, Excel-based Oracle Commercial Off-the-Shelf package that allows authorized CFS General Ledger users to prepare journal entries in Microsoft Excel format to import into the CFS General Ledger for posting. This application provides CFS users the flexibility of maintaining a secured, organized library of journal entries required for PBGC’s ongoing accounting operations. The application does data validation upon the start of the import process to ensure that entries created using the Application Desktop Integrator conform to the security and validation rules defined within the CFS Revolving general ledger module. Currently the Application Desktop Integrator is a web version of Application Desktop Integrator.
• Comprizon Interface; The Comprizon Interface is an automated interface between PBGC’s Comprizon application and the CFS Application. Solicitations and contract awards entered into Comprizon are automatically transferred to the CFS for the appropriate commitment and obligation accounting. Comprizon is a Commercial Off-the-Shelf application provided by CACI. The CFS Comprizon Interface is specifically designed between CFS and Comprizon to communicate and transfer transaction data and statuses between the two systems. The CFS Comprizon Interface is a backend process that uses a DB-Link to access the ComprizonSuite External Interface Manager (EIM) database schema to pull and push transaction data. The following transactions are transferred to CFS and imported into Payables and Purchasing Oracle modules:
o COFA (Check of Funds Availability);
o Commitments;
o De-commitments;
o Obligations; and, o De-obligations.
Upon a successful or unsuccessful import the Interface provides a status data back to the Comprizon system.
• Payroll Interface; PBGC payroll is processed by the Department of Interior (DOI) payroll system. DOI provides a summary transaction file to PBGC for each payroll process, which is used to update PBGC’s financial system. The processing of this file is handled by the Payroll Interface System. Payroll Interface System was developed in the fiscal year 2011 to replace a legacy PowerBuilder solution. The PBGC Payroll Travel Office (PTO) staff downloads a file from DOI into the PBGC network and place it in a secured folder ready for processing.
Payroll Interface is an Oracle technology (forms, reports, and Structured Query Language/Procedural Language-Structured Query Language) based application bolt-on to the CFS. This bolt-on reads, validates, aggregates, and imports payroll results from the DOI Federal Personnel/Payroll System into the CFS. Once the file has been properly processed and imported into the CFS, the source payroll file is archived onto the secure FOD drive for retention purposes. The CFS custom payroll interface tables does retain certain Personally Identifiable Information data, however that data is encrypted. The Interface provides the capability to generate multiple reports and export them to Microsoft Excel or Adobe Portable Document Format (PDF).
Page | 17
• CFS Concur Interface; PBGC uses GSA provided Concur system for its travel needs.
Concur is a web-based system which manages PBGC employees’ official travel plans. Concur provides an online end-to-end service for PBGC employees and is more specifically used to plan, book, reserve, track, and approve travel reservations and process reimbursements for travel services. The purpose of the CFS Concur Interface is to integrate the PBGC’s Concur and CFS systems. The CFS Concur Interface was developed and deployed in Aug 2014. The scope of the CFS Concur Interface starts when the SOAP message is sent to Demilitarized Zone (DMZ) from the Concur CGE EAI Web Service call, which defines the way to process the transaction within the CFS system and also sends back the expected Status response to Concur application. The references made are with respect to CFS system. All Travel transactions will be initiated in Concur by the Traveler or the preparer on behalf of the traveler. A traveler in Concur is always defined as either an employee or an invitational traveler. The Travel Authorization, Travel Advance, Pre-Trip Vouchers, Local Vouchers and Vouchers are the major transactions which are created in Concur and received by CFS. Once travel transaction is stamped PTO FINAL APPROVED, Concur sends the transaction data to CFS, The transactions then must be validated by the CFS Concur Interface which determines the state of document based on the Pass or Fail response. A document in Concur is not considered to be “Completed” until the successful Document Status response is returned from CFS. CFS returns a Document Status (DocumentStatus) response to Concur based on the type of transaction. Once the document status is returned from CFS, CFS Concur Interface will populate CFS with successfully transmitted through the interface data.
• Invoice Automation; Invoice Automation is an automated workflow that links PBGC’s Image Processing System (IPS) Document Manager (DM) with the CFS. Invoices are scanned into the IPS DM and then automatically transferred to the CFS workflow via Business Process Execution Language (BPEL). Prior to the fiscal year 2011 PBGC used a manual, paper-based procedure for the invoice processing and tracking. The Invoice Tracking System (ITS) was providing basic tracking and notification and was an internally developed, custom Access system. The Invoice Automation project was designed to provide an automated process to transfer the invoice scanned image and metadata from the Document Management System (DMS) to CFS, and to automatically generate invoice entries into CFS. The CFS Invoice Automation System is designed to have two major components:
o CFS Invoice Automation Business Process Execution Language (BPEL) process o Contracting Officer Representative (COR) Approval Workflow
The Invoice Automation process transfers the invoice scanned image and metadata from the IPS Document Manager to CFS. Invoices are scanned into the FileNet image repository and kept on the PBGC Image Processing system (IPS) and then automatically transferred to the CFS staging area via BPEL. The BPEL process invokes the CFS System to receive the Invoice metadata and it will send an Acknowledgement Notification back to DMS. It will parse the Invoice metadata schema file and load the file into the CFS staging tables. The scheduled COR Approval Workflow will process the records from the staging tables and import them into the CFS Open Interface once the COR has approved the invoice for payment. The system will call the Payable Import Program to populate the records into Oracle Payables. This program will create Invoices in CFS automatically with distribution details. The image of the invoice can be viewed during the approval process and after the CFS import. In addition the Interface provides the capability to generate multiple reports and export them to Microsoft Excel or Adobe PDF.
Page | 18
PBGC is currently working to adopt Treasury’s shared service invoice solution Invoice Processing Platform (IPP) by summer of 2018.
• Budget Execution Interface; The PBGC Budget Execution Open Interface is automated, Structured Query Language-based, customized, software that processes data from customized Excel spreadsheets to create a CFS -formatted journal entry file for import into the Oracle Financials – Revolving Fund’s General Ledger module. The Budget Interface allows the loading of budget Appropriation, Apportionment and Allotment transactions into the Oracle CFS Federal Admin module so that funding can be allocated to various projects. It was developed in the fiscal year 2009. The interface accepts an Excel worksheet (comma separated file) as the source data for loading records through the budget execution open interface tables. The interface is comprised of four distinct processes:
o Loading budget data;
o Staging data in temporary tables;
o Validating business rules; and, o Uploading data into CFS through the budget open interface tables.
o Secure Payment System; and,
• The Secure Payment System (SPS) is an application that provides a mechanism by which government agencies can create payment schedules in a secure fashion, and with a strictly enforced separation of duties. This application allows personnel at Federal Program Agency (FPA) locations to submit payment schedules to Financial Management Services (FMS) over a browser/web interface. Two different user-types and roles are required for an FPA to submit schedules to SPS. These are:
o A Data Entry Operator (DEO) who creates a schedule and submits the schedule for certification; and, o A Certifying Officer (CO) who examines the schedule and upon verification, certifies the schedule which results in the schedule being submitted to FMS.
The Payment files are generated from the CFS Account Payables module and saved to a secure file folder. The file is transferred to a secure Universal Serial Bus (USB) flash drive and provided to the SPS user for loading into the SPS application.
• PPS General Ledger and Premium Refund Interface. The GL Interface Release was a custom program and supporting components that transfers journal entries from PPS to the CFS.
The effort included application flows (both manual and programmatic steps), the definition of custom forms and reports, details on Oracle E-Business Suite configuration, and the definition of interface components including source to target table mapping and processing rules. The Premium Refund Interface is automated customized software that transfers premium refund invoices from the PPS into the Oracle Financials – Revolving Fund’s interface tables for import into the Accounts Payable Module of Revolving Set of Books for processing and payment. This interface is supported by the Premium Practitioner System technical team. The Refund interface provides a summary of refund invoices for CFS which is automated to load into CFS, via the GL Interface table(s).
Page | 19
• TAS and Trust Accounting System Interface. The Trust Accounting System (TAS) interface is an automated interface between PBGCs TAS application and CFS. The TAS application is a sub ledger used to account for all trust accounting transactions. Every month a summary journal is sent through an automated interface to be loaded into the CFS trust set of books. TAS is based on the Commercial off-the Shelf (COTS) solution, Eagle Investment Systems Accounting & Data Management (ADMS). TAS (Eagle ADMS) and CFS TAS interface are deployed in production in January 2013. TAS (Eagle ADMS) sends summarized Trust posting transactions by Plan in a set of three CSV files. All financial transactions are transferred through a Secure File Transfer Protocol (SFTP) connection between TAS (Eagle ADMS) and CFS. CFS will receive monthly and yearly trust posting transactions. Once the files are received by PBGC, an automated interface processes the transaction files and imports a journal entry into the GL interface tables. A reconciliation process is conducted to ensure that the data reconciles between the TAS application and CFS. In addition the Interface provides the capability to generate multiple reports and export them to Microsoft Excel or Adobe Portable Document Format.
• The Consolidated Financial System Consolidated Financials. The Financial Reporting and Accounting Analysis Group is the primary user of the CFS Consolidated Financials to prepare PBGC’s quarterly and annual financial statements. It consolidates summary level data from the Trust Set of Books and Revolving Set of Books. The CFS Consolidated Ledger utilizes Oracle customized and Financial Statement Generator reports. There are approximately ten custom Oracle Reports and Financial Statement Generators being maintained for use by system.
Trust Accounting and the Trust Accounting Systems (TAS)
This trust accounting area involves a group of business processes that…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it.