functional requirement document

Defense Finance and Accounting Service

Financial Management Center of Excellence

Functional Requirements DescriptionFor

Release 6.0

September 30, 2009

Release/Version Control

Release/Version

Date Description of Changes

5.0 April 30, 2009

Release 5.0 contains new functional requirements related to Managerial Cost Accounting, Eliminations, Funds Control and Budgetary Accounting, Seized Assets, Grants, Financial Reporting – Departmental Level and Audit Trails and Systems Controls. Also included are updates to Accounts Payable, Accounts Receivable, and Intragovernmental.

6.0 September 30, 2009

This release contains new functional requirements related to Benefits; Direct Loans; Foreign Military Sales (Security Assistance Accounting); Guaranteed Loans; Human Resources and Payroll – Civilian; Human Resources and Payroll – Military; Inventory, Operating Materials & Supplies, Stockpile Material; Property, Plant and Equipment; Time and Attendance; and Travel. In addition, updates to previously released areas.

ii

Table of Contents

1.0 INTRODUCTION..........................................................................................................................................1

1.1 BACKGROUND...............................................................................................................................................11.2 DOCUMENT PURPOSE....................................................................................................................................11.3 SCOPE............................................................................................................................................................21.4 DEFINITIONS..................................................................................................................................................2

2.0 THE ENTERPRISE FUNCTIONAL REQUIREMENTS PROGRAM...................................................3

2.1 OVERVIEW.....................................................................................................................................................32.2 FUNCTIONAL REQUIREMENTS DEVELOPMENT METHODOLOGY....................................................................52.3 REQUIREMENT IDENTIFICATION FORMAT.....................................................................................................5

3.0 ACCOUNTS PAYABLE (PUBLIC) CONCEPT OF OPERATION.........................................................7

3.1 ACCOUNTS PAYABLE (PUBLIC) FUNCTIONAL OVERVIEW............................................................................73.2 ACCOUNTS PAYABLE (PUBLIC) PRACTICES..................................................................................................93.3 RELEASE 6.0 SCOPE.......................................................................................................................................9

3.3.1 Map Requirements to BEA Processes....................................................................................................93.3.2 Review Requirements Linked by Processes...........................................................................................93.3.3 Validate Requirements Source Information............................................................................................93.3.4 Assign Reclassified Requirements to Other Core Teams.......................................................................93.3.5 Perform Team Quality Review of Requirements....................................................................................93.3.6 Develop Additional Process Models.....................................................................................................103.3.7 Close Out Open Issues..........................................................................................................................103.3.8 Compare Requirements to DoD Transaction Library...........................................................................10

4.0 ACCOUNTS RECEIVABLE CONCEPT OF OPERATION..................................................................11

4.1 ACCOUNTS RECEIVABLE FUNCTIONAL OVERVIEW.....................................................................................114.2 ACCOUNTS RECEIVABLE PRACTICES...........................................................................................................124.3 RELEASE 6.0 SCOPE.....................................................................................................................................12

4.3.1 Map Requirements to BEA Processes..................................................................................................124.3.2 Review Requirements Linked by Processes.........................................................................................124.3.3 Validate Requirements Source Information..........................................................................................124.3.4 Assign Reclassified Requirements to Other Core Teams.....................................................................124.3.5 Perform Team Quality Review of Requirements..................................................................................124.3.6 Develop Additional Process Models.....................................................................................................124.3.7 Close Out Open Issues..........................................................................................................................134.3.8 Compare Requirements to DoD Transaction Library...........................................................................13

5.0 AUDIT TRAILS AND SYSTEM CONTROLS CONCEPT OF OPERATION.....................................14

5.1 AUDIT TRAILS AND SYSTEM CONTROLS FUNCTIONAL OVERVIEW............................................................145.2 AUDIT TRAILS AND SYSTEM CONTROLS PRACTICES..................................................................................155.3 RELEASE 6.0 SCOPE.....................................................................................................................................15


iii

6.0 BENEFITS CONCEPT OF OPERATION................................................................................................17

6.1 BENEFITS FUNCTIONAL OVERVIEW.............................................................................................................176.2 BENEFITS PRACTICES..................................................................................................................................186.3 RELEASE 6.0 SCOPE.....................................................................................................................................18


7.0 CASH ACCOUNTABILITY CONCEPT OF OPERATION...................................................................20

7.1 CASH ACCOUNTABILITY FUNCTIONAL OVERVIEW.....................................................................................207.2 CASH ACCOUNTABILITY PRACTICES...........................................................................................................217.3 RELEASE 6.0 SCOPE.....................................................................................................................................21


8.0 DIRECT LOAN CONCEPT OF OPERATION........................................................................................23

8.1 DIRECT LOAN FUNCTIONAL OVERVIEW.....................................................................................................238.2 DIRECT LOAN PRACTICES...........................................................................................................................248.3 RELEASE 6.0 SCOPE.....................................................................................................................................24


9.0 DISBURSING CONCEPT OF OPERATION...........................................................................................26

9.1 DISBURSING FUNCTIONAL OVERVIEW........................................................................................................269.2 DISBURSING PRACTICES..............................................................................................................................289.3 RELEASE 6.0 SCOPE.....................................................................................................................................28


iv

10.0 FIELD LEVEL REPORTING CONCEPT OF OPERATION................................................................30

10.1 FIELD LEVEL REPORTING FUNCTIONAL OVERVIEW...................................................................................3110.2 FIELD LEVEL REPORTING PRACTICES.........................................................................................................3110.3 RELEASE 6.0 SCOPE.....................................................................................................................................31

10.3.1 Map Requirements to BEA Processes.............................................................................................3110.3.2 Review Requirements Linked by Processes....................................................................................3210.3.3 Validate Requirements Source Information.....................................................................................3210.3.4 Assign Rejected Requirement to Other Core Teams.......................................................................3210.3.5 Perform Team Quality Review of Requirements.............................................................................3210.3.6 Develop Additional Process Models................................................................................................3210.3.7 Close Out Open Issues.....................................................................................................................3210.3.8 Compare Requirements to DoD Transaction Library......................................................................32

11.0 FINANCIAL REPORTING CONCEPT OF OPERATION....................................................................33

11.1 FINANCIAL REPORTING FUNCTIONAL OVERVIEW.......................................................................................3311.2 FINANCIAL REPORTING PRACTICES.............................................................................................................3411.3 RELEASE 6.0 SCOPE.....................................................................................................................................34

11.3.1 Map Requirements to BEA Processes.............................................................................................3411.3.2 Review Requirements Linked by Processes....................................................................................3411.3.3 Validate Requirements Source Information.....................................................................................3411.3.4 Assign Reclassified Requirements to Other Core Teams................................................................3411.3.5 Perform Team Quality Review of Requirements.............................................................................3411.3.6 Develop Additional Process Models................................................................................................3511.3.7 Close Out Open Issues.....................................................................................................................3511.3.8 Compare Requirements to DoD Transaction Library......................................................................35

12.0 FOREIGN MILITARY SALES CONCEPT OF OPERATION..............................................................36

12.1 FOREIGN MILITARY SALES FUNCTIONAL OVERVIEW.................................................................................3612.2 FOREIGN MILITARY SALES PRACTICES.......................................................................................................3712.3 RELEASE 6.0 SCOPE.....................................................................................................................................37


13.0 FUNDS CONTROL AND BUDGETARY ACCOUNTING CONCEPT OF OPERATION................39

13.1 FUNDS CONTROL AND BUDGETARY ACCOUNTING FUNCTIONAL OVERVIEW............................................3913.2 FUNDS CONTROL AND BUDGETARY ACCOUNTING PRACTICES..................................................................4013.3 RELEASE 6.0 SCOPE.....................................................................................................................................40


v

14.0 GENERAL LEDGER CONCEPT OF OPERATION..............................................................................42

14.1 GENERAL LEDGER FUNCTIONAL OVERVIEW..............................................................................................4314.2 GENERAL LEDGER PRACTICES....................................................................................................................4414.3 RELEASE 6.0 SCOPE.....................................................................................................................................44


15.0 GUARANTEED LOANS CONCEPT OF OPERATION.........................................................................46

15.1 GUARANTEED LOANS FUNCTIONAL OVERVIEW.........................................................................................4615.2 GUARANTEED LOANS PRACTICES...............................................................................................................4715.3 RELEASE 6.0 SCOPE.....................................................................................................................................47


16.0 HUMAN RESOURCES AND PAYROLL – CIVILIAN CONCEPT OF OPERATION......................49

16.1 HUMAN RESOURCES AND PAYROLL – CIVILIAN FUNCTIONAL OVERVIEW................................................4916.2 HUMAN RESOURCES AND PAYROLL – CIVILIAN PRACTICES......................................................................5016.3 RELEASE 6.0 SCOPE.....................................................................................................................................50


17.0 HUMAN RESOURCES AND PAYROLL – MILITARY CONCEPT OF OPERATION....................52

17.1 HUMAN RESOURCES AND PAYROLL – MILITARY FUNCTIONAL OVERVIEW...............................................5217.2 HUMAN RESOURCES AND PAYROLL – MILITARY PRACTICES.....................................................................5217.3 RELEASE 6.0 SCOPE.....................................................................................................................................52


vi

18.0 INTRA-GOVERNMENTAL CONCEPT OF OPERATION...................................................................54

18.1 INTRA-GOVERNMENTAL FUNCTIONAL OVERVIEW......................................................................................5418.2 INTRA-GOVERNMENTAL PRACTICES............................................................................................................5518.3 RELEASE 6.0 SCOPE.....................................................................................................................................55


19.0 INTRA-GOVERNMENTAL ELIMINATIONS CONCEPT OF OPERATION...................................57

19.1 INTRA-GOVERNMENTAL ELIMINATIONS FUNCTIONAL OVERVIEW.............................................................5719.2 INTRA-GOVERNMENTAL ELIMINATIONS PRACTICES...................................................................................5819.3 RELEASE 6.0 SCOPE.....................................................................................................................................58


20.0 INVENTORY, OPERATING MATERIALS AND SUPPLIES, AND STOCKPILE MATERIALS CONCEPT OF OPERATION.....................................................................................................................60

20.1 INVENTORY, OPERATING MATERIALS AND SUPPLIES, AND STOCKPILE MATERIALS FUNCTIONAL OVERVIEW...................................................................................................................................................60

20.2 INVENTORY, OPERATING MATERIALS AND SUPPLIES, AND STOCKPILE MATERIALS PRACTICES...............6120.3 RELEASE 6.0 SCOPE.....................................................................................................................................61


21.0 MANAGERIAL COST ACCOUNTING CONCEPT OF OPERATION...............................................63

21.1 MANAGERIAL COST ACCOUNTING FUNCTIONAL OVERVIEW.....................................................................6321.2 MANAGERIAL COST ACCOUNTING PRACTICES...........................................................................................6421.3 RELEASE 6.0 SCOPE.....................................................................................................................................64

21.3.1 Map Requirements to BEA Processes.............................................................................................6421.3.2 Review Requirements Linked by Processes....................................................................................6521.3.3 Validate Requirements Source Information.....................................................................................6521.3.4 Assign Reclassified Requirements to Other Core Teams................................................................6521.3.5 Perform Team Quality Review of Requirements.............................................................................6521.3.6 Develop Additional Process Models................................................................................................6521.3.7 Close Out Open Issues.....................................................................................................................65

vii

21.3.8 Compare Requirements to DoD Transaction Library......................................................................65

22.0 PROPERTY, PLANT, AND EQUIPMENT CONCEPT OF OPERATION..........................................66

22.1 PROPERTY, PLANT, AND EQUIPMENT FUNCTIONAL OVERVIEW..................................................................6622.2 PROPERTY, PLANT, AND EQUIPMENT PRACTICES.......................................................................................6722.3 RELEASE 6.0 SCOPE.....................................................................................................................................67


23.0 TIME AND ATTENDANCE CONCEPT OF OPERATION...................................................................69

23.1 TIME AND ATTENDANCE FUNCTIONAL OVERVIEW.....................................................................................6923.2 TIME AND ATTENDANCE PRACTICES...........................................................................................................7023.3 RELEASE 6.0 SCOPE.....................................................................................................................................70


24.0 TRAVEL CONCEPT OF OPERATION...................................................................................................72

24.1 TRAVEL FUNCTIONAL OVERVIEW...............................................................................................................7224.2 TRAVEL ACCOUNTING PRACTICES..............................................................................................................7324.3 RELEASE 6.0 SCOPE.....................................................................................................................................73


25.0 SHARED SERVICES POINTS OF CONTACT.......................................................................................75

25.1 SHARED SERVICES DIVISION HOTLINE EMAIL............................................................................................7525.2 WORLD WIDE WEB.....................................................................................................................................7525.3 SCENARIO DATABASE.................................................................................................................................7525.4 BEA 6.0 ARCHITECTURE.............................................................................................................................75

Appendix 1 – Acronyms...............................................................................................................................................76

viii

[This Page Intentionally Left Blank]

ix

1.0Introduction

1.1 Background

Department of Defense (DoD) Directive 5118.5 identifies the Director, Defense Finance and Accounting Service (DFAS) as the principal DoD executive for finance and accounting requirements, systems, and functions. That role includes the responsibility to “Direct the consolidation, standardization, and integration of finance and accounting requirements, functions, procedures, operations, and systems within the Department of Defense.” Developing standard, consistent, and effective requirements for DoD finance and accounting operations and systems is a priority initiative for the DFAS Financial Management Center of Excellence (FMCoE). The FMCoE has assigned this complex program to its Shared Services Division (SSD), which has gathered requirements from current statutory laws, regulations, and guidance, in addition to requirements from existing and developing DoD finance and accounting systems. SSD used functional experts from other DFAS organizations to select and edit the appropriate set of requirements.

The requirements contained herein will become the basis for all new finance and accounting operations and system acquisitions across the Department, and all existing DoD finance and accounting systems will migrate to these requirements as their budgets and priorities dictate.

1.2 Document Purpose

The purpose of this document is to present the context for standard DoD requirements including:

Accounts Payable (Public) Accounts Receivable

(Public) Audit Trails and System

Controls Benefits Cash Accountability Direct Loans Disbursing Field Level Reporting Financial Reporting

Foreign Military Sales (Security Assistance Accounting)

Funds Control and Budgetary Accounting

General Ledger Guaranteed Loans Human Resources and

Payroll – Civilian Human Resources and

Payroll – Military

Intra-governmental Intra-governmental

Eliminations Inventory, Operating

Materials & Supplies, Stockpile Material

Managerial Cost Accounting Property, Plant, and

Equipment Time and Attendance Travel

The context is a description of the DoD concept of operation, its standard business practices, and its operational processes. The processes are taken from the DoD Business Enterprise Architecture (BEA) and extended, as necessary, to complete a level of detail to which the requirements can easily be assigned.

Requirements information is presented in three parts: 1) the contextual description of the requirements project and its functional area, 2) the process models for this functional area, and 3) the requirement statements, business rules and best practices for each functional area. The contextual description of the requirements project and its functional area are contained in this Functional Requirements Description (FRD). The process models, requirement statements, and business rules are presented in accompanying spreadsheets.

1

This version of the FRD will serve as the definitive reference for Release 6.0 functional requirements. It is a “living” document and will be updated as requirements change or is refined.

1.3 Scope

This document establishes the context for the DoD standard functional requirements. It also comprises the most current functional requirements resulting from analyses, reviews, and validations performed by Shared Services team members and Subject Matter Experts (SMEs). Detailed accomplishments which influenced the development of this FRD may be found in Section 3.0. A separate file (the repository listing) contains the requirements, process model, and other related information in spreadsheet format.

The project’s purpose is to develop functional requirements and business rules consistent with commercial industry best practices and compliance requirements (laws, regulations, and policies), and to map them to implementation level processes consistent with the BEA. The project objectives are to:

• Present standard functional requirements that can be implemented for any DoD system.

• Provide requirements detailed enough so that no functional interpretation is required by system implementers.

• Provide requirements that are necessary, achievable, uniquely identifiable, singular, concise, unambiguous, complete, consistent and testable.

• Provide relevant information related to the logistical and financial management of DoD events, enhancing system development.

1.4 Definitions

As used within this document, functional requirements, business rules, and best practices are defined as follows:

Functional Requirement – A statement that describes the intended behavior of a system by describing characteristics, attributes, conditions, constraints, or capabilities to which a system must conform in order to meet a need or objective.1 In this document, when the word “requirement” is used, it means functional requirement.

Business Rule – A statement that defines or constrains some aspect of the business or its architecture. It describes what a business must or must not do, or it describes the rules under which the architecture or its objects behave under certain conditions. Business rules are constraints that are process/activity specific and have no system impact.2

Best Practice – A management idea which asserts that there is a technique, method, process, activity, incentive or reward that is more effective at delivering a particular outcome than any other technique, method, process, etc. The idea is that with proper processes, checks, and testing, a project can be rolled out and completed with fewer problems and unforeseen complications. 3

1 SSD Road show Presentation 2 DoD Architecture Framework, Vol. II33 Wikipedia (www.wikipedia.com)

2

http://en.wikipedia.org/wiki/Technique

http://en.wikipedia.org/wiki/Management_fad

2.0The Enterprise Functional Requirements Program

2.1 Overview

The Enterprise Functional Requirements Program is a set of projects to develop standard functional requirements, business rules, and best practices for DoD finance and accounting operations and systems. The requirements and business rules will be architecture-driven – meaning that they will be aligned to processes in the DoD Finance and Accounting Operational Architecture, which itself is aligned with the DoD BEA (see Figure 1).

Compliance requirements, business rules, and best practices have already been developed at the DoD enterprise functional level as part of the BEA. In most cases, the compliance requirements do not contain all the functional information necessary for an acquisition program, like DAI, GFEBS, Navy ERP, DEAMS, or BEIS, to properly implement and test the acquisition system. Therefore, this program develops functional requirements down to the level of detail such that acquisition programs do not need to make functional interpretations. Yet these requirements should not constrain the implementation in the non-functional ways, for example, by defining system specific data elements names. The functional requirements and business rules were gathered from sources such as:

A Guide to Federal Requirements for Financial Management Systems (DFAS 7900.4G - Blue Book)

Business Enterprise Architecture Version 6.0 Business Modernization Reengineering (BMR) [E-Biz] Business Systems Modernization (BSM)/Enterprise Business System (EBS) Core Financial Systems Requirements (OFFM-NO-0106) Defense Federal Acquisition Regulation Supplement (DFARS) Defense Transportation Regulation (DTR) 4500.9-R, Part II, Chapter 210 DFAS, Deputy Director, Operations Memorandum, dated May 2006 DFAS 7000.10-I, Accounting High Performing Organization DoD 4000.25-7-M, MILSBILLS DoD Guidebook for Miscellaneous Payments DoD Instruction 8500.2, Information Assurance (IA) Implementation DoD Instruction 8510.01, DoD Information Assurance Certification and Accreditation

Process (DIACAP) DoD Directive 8000.01, Management of the Department of Defense Information

Enterprise DoD Directive 8500.01E, Information Assurance (IA) Defense Information Systems Agency (DISA), Security Technical Implementation

Guides (STIG): Access Control STIG V2R1 and Database STIG V8R1 DoD 4100.39-M, Volume 4, Federal Logistics Information System DoD 4140.1-R, DoD Supply Chain Management Regulation DoD Financial Management Regulation (DoD 7000.14-R)

3

Federal FM Guidance

OFFM, Treasury, SFFAS, SFIS

Architecture(BEA)

DoD FM Guidance(FMR & Blue Book)

DoD F&A Operational Architecture

DoD Finance & Accounting Requirements• Processes• Business Rules• Functional Requirements

Figure 1. Requirements Development Concept

DoD Guidebook for Miscellaneous Payments Federal Acquisition Regulation (FAR) Federal Financial Management Systems (FFMSR-8) Federal Financial Management Systems (FFMSR-00-01) GAO/AIMD-00-21.3.1, Standards for Internal Control in the Federal Government JFMIP-SR-99-8, Property Management Systems Requirements JFMIP-SR-99-14, Seized Property and Forfeited Assets System Requirements JFMIP-SR-00-4, Property Management System Requirements JFMIP-SR-01-01, Benefit System Requirements JFMIP SR-02-01, Core Financial Systems Requirements JFMIP SR-03-01, Revenue System Requirements JFMIP-SR-03-02, Inventory, Supplies, and Materials System Requirements National Institute of Standards and Technology (NIST) Special Publication 800-53,

Recommended Security Controls for Federal Information Systems and Organizations, Revision 3

National Institute of Standards and Technology (NIST) National Security Telecommunications and Information Systems Security Policy (NSTISSP), No. 11, Revised Fact Sheet

OMB Circular A-11, Preparation, Submission and Execution of the Budget OMB Circular A-127 Financial Management Systems OMB Circulars A-129 Policies for Federal Credit Programs and Non-tax Receivables OMB Circular A-130, Management of Federal Information Resources OMB Circular A-136, Financial Reporting Requirements OMB Memorandum 09-06, Implementation Guidance for the Federal Financial

Management Improvement Act (January 2009) OUSD (C) Memorandum, "Standard Financial Information Structure (SFIS)

Implementation Policy" (August 2005) OSD and DFAS Policies Statements of Federal Financial Accounting Standards (SFFAS) No. 1 SFFAS-3, Accounting for Inventory and Related Property SFFAS-6, Accounting for Property, Plant, and Equipment SFFAS-8, Supplementary Stewardship Reporting SFFAS-23, Eliminating the Category National Defense Property, Plant, and Equipment SFFAS-29, Heritage Assets and Stewardship Land Standards and Compliance (S&C) Treasury Financial Manual (TFM) Under Secretary of Defense, Deputy Chief Financial Officer Memorandum, dated

October 2002 5 CFR 1315 (Prompt Payment Act) 5 USC Section 522a (Privacy Act of 1974) 44 U.S.C. Section 3541, Information Security

4

http://www.law.cornell.edu/uscode/44/3541.html

http://en.wikipedia.org/wiki/Title_44_of_the_United_States_Code

1. Plan Project2. Develop Processes3. Identify and Gather Requirements,

Business Rules, and Best Practices4. Perform Mapping5. Perform Initial Validation6. Validate and Write Requirements7. Deliver Release 6.0 Requirements

and Documentation to Director, Shared Services for Approval

Table 2. High Level Development Tasks

However, most of the requirements derived from the above are too high-level to be readily implemented by system engineers in acquisition program offices. Therefore, a large part of the effort of these requirements projects has been to refine the requirements taken from the above to bring them down to the implementation level, i.e., eliminate any need for the system engineer to make functional interpretation.

All functional requirements will adhere to the following quality characteristics: necessary, achievable, correct, unambiguous, complete, consistent, concise, singular, implementation-free, and testable. Once approved, the enterprise functional requirements will be given to all finance and accounting system offices for implementation in their respective systems.

Because the DoD finance and accounting domain is so large, the enterprise functional requirements projects have been segmented into functional areas, similar to the chapters in “A Guide to Federal Requirements to Financial Management Systems”4.

The selected set of functional areas (i.e., requirements projects) is listed in Table 1. The first seven projects were executed in FY07 and are considered the Core Financial Finance and Accounting areas.

2.2 Functional Requirements Development Methodology

This, and each of the other requirements projects went through a similar process to gather, map, write, and validate requirements. Each project developed its own detailed work plan and detailed schedule taking into consideration their scope, priorities, and available resources. The SMEs were enlisted to help select those requirements that should be standardized, and they wrote additional requirements where the level of detail of those requirements initially gathered was not sufficient. The numerical order of the tasks in Table 2 indicates the approximate sequence of events.

2.3 Requirement Identification Format

The requirements are uniquely identified by a combination of letters and numbers broken down into several parts. The first part is shown by letters followed by a dash (-) that identifies which functional areas the requirement belongs. The first set of four-position numbers after the dash is a unique number assigned to the parent requirement. Subsequent sets of two-position numbers will be assigned to show children and/or grand children

4

? Formally, this document is entitled DFAS 7900.4-G, A Guide to Federal Requirements to Financial Management Systems, Feb., 2009. Informally, this book is sometimes referred to as the Blue Book.

5

Requirements Projects

Accounts Payable (Payment Mgmt)DisbursingRevenue and Accounts ReceivableGeneral LedgerFinancial ReportingCash AccountabilityIntra-governmentalInventory, Operating Materials and Supplies,

Stockpile MaterialsProperty, Plant and EquipmentManagerial Cost AccountingHuman Resources and PayrollFunds Control and Budgetary AccountingTravelGrantsAudit Trails and System ControlsSeized AssetsEliminations (Intra-Governmental)Field Level ReportingDirect LoansGuaranteed LoansBenefitsTime and AttendanceForeign Military Sales (Security Assistance

Accounting)

Table 1. Requirements Functional Areas

to a parental requirement. As an example, XX-0001.01.01 requirement number will be used as a reference.

XX-0001.01.01: 2 position identifier that delineates functional areas

XX- 0001.01.01: Indicates this as requirement number 1 of the functional areas

XX-0001.01.01: First child of parental requirement number 1

XX-0001.01.01: First child of child requirement number 1

6

3.0Accounts Payable (Public) Concept of Operation

In October 2006, the SSD was tasked to establish a set of functional requirements for Accounts Payable (Public). To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed.

First, the working group gathered existing Accounts Payable (Public) functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group.

Next, Accounts Payable (Public) SMEs were invited to participate in a series of Joint Application Development (JAD) sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all Enterprise Resource Planning (ERP) systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution.

From the BEA diagrams, the Accounts Payable (Public) Working Group determined what additional processes were needed. The group then identified gaps within the Accounts Payable (Public) process models and steps. The Accounts Payable (Public) Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify:

1) gaps in the objects and related descriptions included in the diagram,

2) the need for further decomposition or changes to the BEA baseline diagram, and

3) the need for additional functional requirements to complete the standard requirements package.

The accompanying spreadsheet contains the standard functional requirements, business rules, and best practices mapped to the appropriate process flows/steps.

3.1 Accounts Payable (Public) Functional Overview

Functional requirements developed for Accounts Payable (Public) are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Accounts Payable (Public) business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined.

As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Manage Liabilities), BEA process name (e.g. Manage Execution Fund Account) and the DFAS process name (e.g. Manage Prevalidation Requests).

It should be noted that only the process steps associated with Accounts Payable (Public) are being addressed by this document. Therefore, in some instances, the incorporated business

7

process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Accounts Payable (Public) requirements defined to date.The following process models are included:

Acknowledge Goods Tendered Perform Acceptance Procedures Validate Invoice Manage Liabilities * Manage Entitlement Process Payment Request Calculate Entitlement Manage Funds Validation Manage Execution Fund Account** Manage Payment Confirmation and Follow-Up Process Collections Against Entitlement

* The Manage Liabilities process model incorporated into this document is a subset of the BEA Manage Liabilities model and reflects the initial steps to Evaluate Liabilities Information and Establish Accounts Payable. It was also expanded to incorporate additional steps required in the processing of Accounts Payable transactions not currently depicted in the BEA. This diagram will be expanded to incorporate all BEA process steps as additional requirements are defined in later versions.

** The Manage Execution Fund Account process model incorporated into this document is an expanded version of the BEA Manage Execution Fund Account model. It reflects the process steps to be added to support the Entitlement process.

In order to make for a more manageable grouping of requirements, 12 Accounts Payable process areas were selected based on subchapters of the Accounts Payable (Payment Management) in the DFAS 7900.4G - Blue Book. In addition, these areas were supported by The Federal Acquisition Regulations (FAR), Defense Federal Acquisition Regulations Supplement (DFARS), and the Financial Management Regulation (FMR). The AP Project contained seven phases in Release 3.0, December 18, 2007. As each Release was updated, it was annotated in the Release/Version Control History table at the beginning of the document.

Release 3.0 added the process review and validation of functional requirements for Intra-governmental as well as a review and inclusion of the USSGL Accounting Transaction Categories to the previous releases/versions of: Receipt, Acceptance, and Recognition (Release 1.0), Managing Entitlements (Version 1.1), Invoices, Payment Terms and Prevalidation (Version 1.2); Transportation, Miscellaneous, and Scheduling Payments (Version 1.3); Workflow, Internal Controls, and Reports (Version 1.4); Accounting (Release 2.0); and Intra-governmental (Release 3.0) requirements and process areas.

Release 5.0 includes revised BEA 6.0 0V-6c process model for Manage Entitlement to the new Manage Supply Chain Entitlement and it’s newly created sub-processes: Calculate Supply Chain Entitlement, Prepare Certified Business Partner Payment, Manage Scheduled Payments, and

8

Monitor Payments. Accounts Payable cross-walked the functional requirements and business process models to the new BEA 6.0 0V-6c model for Manage Supply Chain Entitlement.

The repository listing contains the cumulative standard functional requirements, business process models, business rules and best practices. They were accepted and deemed valid by the Accounts Payable (Public) working group and SMEs. In addition to the new requirements for Intra-governmental transactions, requirements and processes from previous versions have been further refined. The requirements contained within the spreadsheet are grouped and sorted based on the business process model to which they apply. Combined, they define a set of standard processes that will optimize the effectiveness and efficiency of Accounts Payable operations throughout DoD. Upon completion of this project, this document will also provide a comprehensive repository of Accounts Payable requirements for future system development efforts.

3.2 Accounts Payable (Public) Practices

The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Accounts Payable (Public) DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies.

3.3 Release 6.0 Scope

3.3.1 Map Requirements to BEA Processes

During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.0, requirements were mapped to the lowest level possible within the BEA architecture and, if appropriate, to multiple lower levels. Once completed, the requirements functionally linked by architectural process were identified. Shared Services integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links.

3.3.2 Review Requirements Linked by Processes

The Shared Services Branches further integrated functional requirements by identifying requirements that were touch points between functions. The teams conducted cross team reviews and updated the requirements based upon touch points between the functions.

3.3.3 Validate Requirements Source Information

Authoritative Source updates to the requirements included Regulation or Policy changes received through September 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews.

3.3.4 Assign Reclassified Requirements to Other Core Teams

Release 6.0 includes requirements that were reclassified as being out of scope for Accounts Payable (Public). These requirements were identified and considered for inclusion in another team’s functional requirements.

3.3.5 Perform Team Quality Review of Requirements

In Release 6.0 the functional branches continuously performed internal team reviews of the requirements to ensure that all functional requirements adhered to the following quality

9

characteristics: necessary, achievable, correct, unambiguous, complete, consistent, concise, singular, implementation-free, and testable. All requirements that were not written to the standards above were either rewritten, rejected, or transferred for management decision.

3.3.6 Develop Additional Process Models

The Accounts Payable (Public) developed additional process models.

3.3.7 Close Out Open Issues

Issues identified during Release 6.0 were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE staff were transferred to the office that had responsibility for oversight of the respective issues. Once the issue was resolved, the issue was closed in the issue tracking tool.

3.3.8 Compare Requirements to DoD Transaction Library

There were Accounts Payable (Public) DoD Transaction Library requirements. The Accounts Payable (Public) requirements were compared to the DoD Transaction Library. Missing requirements were developed and included in the Accounts Payable (Public) database to encompass any gaps between the documents. The following requirements were not addressed in the DoD Transaction Library and need to be addressed in future revisions to the document: Accounts Payable (Public) requirements related to purchase returns, construction-in-progress, advances and prepayments, commitments/programs subject to apportionment, and expended/unexpended authority. These are business events that are not currently covered in the Treasury Financial Manual (TFM) but do occur within the DoD financial community and should result in transactions recorded in the General Ledger for DoD.

10

4.0Accounts Receivable Concept of Operation

In October 2006, the SSD was tasked to establish a set of functional requirements for Accounts Receivable. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed.

First, the working group gathered existing Accounts Receivable functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group.

Next, Accounts Receivable SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution.

From the BEA diagrams, the Accounts Receivable Working Group determined what additional processes were needed. The group then identified gaps within the Accounts Receivable process models and steps. The Accounts Receivable Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify:





4.1 Accounts Receivable Functional Overview

Functional requirements developed for Accounts Receivable are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Accounts Receivable business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined.

As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Order to Cash) and the BEA process name (e.g. Record and Manage Receivable).

It should be noted that only the process steps associated with Accounts Receivable are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Accounts Receivable requirements defined to date.

11

The following process model is included:

Record and Manage Receivable: - This process consists of three areas - Establish Receivable, Maintain Receivable and Apply Collection. The process involves the administration of monies owed to DoD. It includes recording the receivable, recognizing revenue earned, applying cash receipts and liquidating receivable. The Manage Receivable activity also includes billing, aging, dunning, write-off, adjustment, and the assessment of interest and penalties on outstanding receivable.

4.2 Accounts Receivable Practices

The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Accounts Receivable DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies.









Release 6.0 includes requirements that were reclassified as being out of scope for Accounts Receivable. These requirements were identified and considered for inclusion in another team’s functional requirements.


In Release 6.0 the functional branches continuously performed internal team reviews of the requirements to ensure that all functional requirements adhered to the following quality characteristics: necessary, achievable, correct, unambiguous, complete, consistent, concise, singular, implementation-free, and testable. All requirements that were not written to the standards above were either rewritten, rejected, or transferred for management decision.


The Accounts Receivable Working Group did not develop additional process models.

12




There were Accounts Receivable DoD Transaction Library requirements. Functional requirements were mapped to the DoD transaction library and their associated general ledger effects. Shared Services reviewed, analyzed and updated requirements based upon the general ledger scenarios. The requirements were updated to include the DoD Transaction Code (DTC) contained in the DoD Transaction Library. All transaction library scenarios and their general ledger effects were reviewed for possible inclusion in the requirements. This ensured related general ledger debits and credits were linked to the associated functional requirements.

13

5.0Audit Trails and System Controls Concept of Operation

In October 2006, the SSD was tasked to establish a set of functional requirements for Audit Trails and System Controls. To accomplish this mission it was necessary to map all requirements extracted from the authoritative sources listed in section 2.1 to the current BEA model and identify any gaps if they existed.

First, the work group gathered existing Audit Trails and System Controls functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group.

Next, Audit Trails and System Controls SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution.

The accompanying spreadsheet contains the standard functional requirements and best practices mapped to the appropriate DFAS process flows/steps.

5.1 Audit Trails and System Controls Functional Overview

Functional requirements developed for Audit Trails and System Controls are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model would be used as a starting point for the identification and development of more detailed Audit Trails and System Controls business processes. This includes identifying the BEA process diagrams, BEA process name, and the DFAS process name (e.g. Audit Trails). However, the BEA 6.0 does not provide business processes or diagrams for Audit Trails & System Controls. Therefore, the team developed a list of DFAS processes / activities.

The following are areas and their related DFAS processes / activities: Audit Trails

o Audit Trails Application Controls

o Document and Transaction Controlo Document Referencing and Modificationo Workflow/Messagingo Document Managemento Operations

General Controlso System-Generated Transactionso General Design/Architectureo Infrastructureo User interfaces

14

o Interoperabilityo Internet accesso Securityo Ad-hoc queryo Documentationo System performance

Because of ATSC pervasiveness to all business processes, it is impractical to develop models. Therefore, the processes / activities are identified within the functional requirements however, no process models were created.

5.2 Audit Trails and System Controls Practices

The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Audit Trails and System Controls DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies.



During Release 6.0 the Shared Services completed integration or cross function validation of the functional requirements. In Release 6.0 requirements were mapped to the lowest level possible within the BEA architecture and if appropriate to multiple lower levels. Once completed, the requirements functionally linked by architectural process were identified. Shared Services integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links.






Release 6.0 includes requirements that were reclassified as being out of scope for Audit Trails and System Controls. These requirements were identified and considered for inclusion in another team’s functional requirements.


In Release 6.0, the functional branches continuously performed internal team review of the requirements to ensure that all functional requirements adhered to the following quality characteristics: necessary, achievable, correct, unambiguous, complete, consistent, concise, singular, implementation-free, and testable. All requirements that were not written to the standards above were either: rewritten, rejected or transferred for management decision.

15


Audit Trails and System Controls did not develop additional process models for Release 6.0.




The Audit Trails and System Controls requirements were not compared to the DoD Transaction Library since Audit Trails and System Controls does not create transactions.

16

6.0Benefits Concept of Operation

In May 2009, the SSD was tasked to establish a set of functional requirements for Benefits. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed.

First, the working group gathered existing Benefits functional requirements from available sources. These requirements were consolidated, reviewed and pre-validated by the working group. The working group also documented the standard DFAS process.

Next, Benefits SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution.

From the BEA diagrams, the Benefits Working Group determined what additional processes were needed. The group then identified gaps within the Benefits process models and steps. The Benefits Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify:




The accompanying spreadsheet contains the standard functional requirements mapped to the appropriate process flows/steps.

6.1 Benefits Functional Overview

Functional requirements developed for Benefits are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Benefits business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined.

As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Manage Benefits), BEA process name (e.g. Manage Benefits) and the DFAS process name (e.g. Claims Acceptance and Tracking).

It should be noted that only the process steps associated with Benefits are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Benefits requirements defined to date.

17

The following process models are included:

Manage Benefits: This process supports DoD Quality of Life Programs as well as benefit eligibility, enrollment, termination and reporting. It includes provision of Morale, Welfare, and Recreation Programs (including Chaplain programs, commissary, exchange, and other Non-Appropriated Fund (NAF) operations). The process is associated with providing military Health programs and supporting individual elections of medical, dental, life, and long term insurance; pension/retirement programs; flexible spending programs; disability benefits; military housing; educational benefits; savings management (Thrift/Bonds).

6.2 Benefits Practices

The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Benefits DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies.









Release 6.0 includes requirements that were reclassified as being out of scope for Benefits. These requirements were identified and considered for inclusion in another team’s functional requirements.



18


The Benefits developed additional process models for Release 6.0.




The Benefits requirements were not compared to the DoD Transaction Library since transactions are not posted to a trial balance in this area. The general ledger resides within the ERP and records the effects of those events.

19

7.0Cash Accountability Concept of Operation

In October, 2006, the SSD was tasked to establish a set of functional requirements for Cash Accountability. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed.

First, the working group gathered existing Cash Accountability functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group.

Next, Cash Accountability SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. Cash Accountability functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting to make certain each functional requirement could be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements, as needed. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution.

The Cash Accountability Working Group mapped the standard functional requirements to the applicable BEA process diagram. The review of processes and mapping of functional requirements to business processes served to identify:




The accompanying spreadsheet contains the standard functional requirements and best practices mapped to the appropriate BEA process flows/steps for Release 6.0.

7.1 Cash Accountability Functional Overview

Functional requirements developed for Cash Accountability are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed.

As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Send Statement of Accountability or Transactions or Trial Balance to Treasury) and BEA process name (e.g. Manage Execution with Treasury).

It should be noted that only the process steps associated with Cash Accountability are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Cash Accountability requirements defined to date.

20

Release 6.0 contains the following process models:

Send Statement of Accountability or Transactions or Trial Balance to Treasury Reconcile Undisbursed Expenditure Account Ledger Generate Correcting Pro Forma Entries Verify Information Reconcile Deposits Document Results of Reconciliation Manage Execution with Treasury Capture Treasury Confirmation Data Capture Treasury Statements Reconcile Disbursements Create Anomaly Explanation

The repository listing contains the cumulative standard functional requirements, business process models, business rules and best practices. They were accepted and deemed valid by the Cash Accountability working group and SMEs. Upon completion of this project, a comprehensive repository of Cash Accountability requirements will be available for future system development efforts.

7.2 Cash Accountability Practices

The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Cash Accountability DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies.









21

Release 6.0 includes requirements that were reclassified as being out of scope for Cash Accountability. These requirements were identified and considered for inclusion in another team’s functional requirements.




Cash Accountability did not develop additional process models for Release 6.0. Possible gaps with the BEA were identified, however, and will be reviewed by the team to determine the need for developing additional process models to encompass these gaps.


Issues identified during Release 6.0 and previous releases were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE staff were transferred to the office that had responsibility for oversight of the respective issues. Once the issue was resolved, the issue was closed in the issue tracking tool.


The Cash Accountability requirements were not compared to the DoD Transaction Library since transactions are not posted to a trial balance in this area. The general ledger resides within the ERP and records the effects of those events.

22

8.0Direct Loan Concept of Operation

In May 2009, the SSD was tasked to establish a set of functional requirements for Direct Loans. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed.

First, the working group gathered existing Direct Loan functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group. The working group also documented the standard DFAS process.

Next, Direct Loan SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution.

From the BEA diagrams, the Direct Loan Working Group determined what additional processes were needed. The group then identified gaps within the Direct Loan process models and steps. The Direct Loan Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify:





8.1 Direct Loan Functional Overview

Functional requirements developed for Direct Loan are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Direct Loan business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined.

As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Record Loans and Grants), BEA process name (e.g. Record Loans and Grants) and the DFAS process name (e.g. Application Screening).

It should be noted that only the process steps associated with Direct Loans are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Direct Loan requirements defined to date.

23

The following process model is included:

Record Loans and Grants - This process records the financial impact of business events related to the award, origination, performance, payment, collection and closeout of direct loans, loan guarantees and grants

8.2 Direct Loan Practices

The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Direct Loan DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies.









Release 6.0 includes requirements that were reclassified as being out of scope for Direct Loan. These requirements were identified and considered for inclusion in another team’s functional requirements.




The Direct Loan team developed additional process models for Release 6.0.

24




The Direct Loan requirements were not compared to the DoD Transaction Library during Release 6.0. The DTCs will be mapped to the test scenarios. Then the requirements will be updated with the DTC information in a maintenance release.

25

9.0Disbursing Concept of Operation

In October 2006, the SSD was tasked to establish a set of functional requirements for Disbursing. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed.

First, the working group gathered existing Disbursing functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group.

Next, Disbursing SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. Disbursing functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution.

From the BEA diagrams, the Disbursing Working Group determined what additional processes were needed. The group then identified gaps within the Disbursing process models and steps. The Disbursing working group then mapped the standard Disbursing functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify:





9.1 Disbursing Functional Overview

Functional requirements developed for Disbursing are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Disbursing business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined.

As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process diagram (e.g. Manage Disbursements), BEA process name (e.g. Cancel Payments) or the DFAS diagram name (e.g. Disbursing Accountability).

As an incremental project, the Disbursing FRD expanded with each subsequent version to incorporate the applicable process models and requirements. Each Version 1.x document was a cumulative document, and incorporated all functional requirements mapped to applicable processes which were finalized with Release 6.0. The process models continued to be refined in

26

later versions of the FRD as additional requirements were identified and existing requirements were assessed in detail.

It should be noted that only the process steps associated with Disbursing are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Disbursing requirements defined to date.


Manage DisbursementsCancel PaymentsConvert United Sates Dollar Equivalent to Foreign EquivalentCreate Check Print FileCreate Electronic Fund Transfer FileDisburse Disburse Cash Issue Cancel Payment NoticeManage Returned PaymentsPrepare Paid Disbursement Voucher Process IPAC Reject Ready-To-Pay File InformationReturn Cancel Payment RequestValidate Cancel Payment Request InformationValidate Ready-To-Pay File Information

Manage CollectionsAdd Voucher to Collection Voucher Control LogCollectPrepare Advice of Collection Prepare Deposit Ticket & Advice of Collection Prepare Collection Voucher & DepositReceive Collection ReceiptsReceive Debit VouchersReceive Other Receipts

Manage Execution with TreasuryReconcile Disbursements Reconcile Deposits

The repository listing contains the cumulative standard functional requirements, business process models, business rules and best practices. They were accepted and deemed valid by the Disbursing working group and SMEs. Requirements and processes from previous versions have been further refined. The requirements contained within the spreadsheet are grouped and sorted based on the business process model to which they apply. Combined, they define a set of standard processes that will optimize the effectiveness and efficiency of Disbursing operations

27

throughout DoD. Upon completion of this project, a comprehensive repository of Disbursing requirements will be available for future system development efforts.

9.2 Disbursing Practices

The requirements were developed for all systems and business operations to be compliant with the Disbursing DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies.









Release 6.0 includes requirements that were reclassified as being out of scope for Disbursing. These requirements were identified and considered for inclusion in another team’s functional requirements.




The Disbursing working group modified the DFAS process models which were previously delivered going from three to two. For Release 4.0, the DFAS process models were Reconcile Disbursing Officers Accountability; Disbursing Administration, Management & Oversight; and Manage Returned Payments. At the completion of Version 6.0, the DFAS Activities are Disbursing Accountability and Disbursing Administration, Management & Oversight. The previously released Reconcile Disbursing Officers Accountability is now Disbursing

28

Accountability. There was no change to Disbursing Administration, Management & Oversight. The Manage Returned Payments was incorporated into the BEA 6.0 Activity Manage Disbursement process diagram.


Issues identified during Release 6.0 and previous releases were documented and tracked in the issue tracking tool until resolution. Those issues that were not resolved by the FMCoE staff were transferred to the office that has responsibility for oversight of the respective issues. Once the issue was resolved, the issue was closed in the issue tracking tool.


The Disbursing requirements were not compared to the DoD Transaction Library since transactions are not posted to a trial balance in this area. The general ledger resides within the ERP and records the effects of those events.

29

10.0 Field Level Reporting Concept of Operation

In October 2006, the SSD was tasked to establish a set of functional requirements for Field Level Reporting. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed.

Field Level Reports can be either mandatory reports in compliance with regulatory requirements or discretionary reports in support of other requirements. The scope of this project is limited to mandatory reports as listed in Table 3. The end product will also concentrate on ensuring requirements produce standardized Field Level Reports throughout DFAS to ensure complete and timely financial data.

Field Level ReportsInternational Balance of Payments (IBOP)Forest Product Sales Program Reports

Actual Revenue and Obligation RCS: DD-A&T(Q&A) 1649 Quarterly Forest Products Program DD-A&T(Q&A) 1649 Annual Forest Products Program Budget DD-A&T(Q&A) 1649

Monthly Receivables Data (MRD) ReportForeign Currency Fluctuations, Defense Report (DD-COMP(M)) 1506Foreign Currency Fluctuations, Construction, Defense Report (DD-COMP(M)) 1761Current Status of Accounts Receivable from Foreign Obligors

Table 3 - Field Level Reports

First, the Field Level Reporting Internal Work Group (IWG) requested a list of current field level reports from Standards & Compliance (S&C). The IWG reviewed the list of reports provided by S&C to validate the authoritative sources and it applicability across the entire DFAS accounting network. The list of reports in Table 1 was derived from this analysis.

Next, the IWG gathered existing Field Level Reporting functional requirements and business rules from available authoritative sources. These requirements were analyzed, mapped to Field Level Reports, and pre-validated by the IWG.

Next, a selected set of Field Level Reporting SMEs were invited to JAD sessions to review and validate the requirements for applicability as a DoD standard in each Field Level Report. The Field Level Reporting functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting results when each functional requirement is implemented in the financial reporting system.

At the completion of each JAD session, the IWG reviewed the comments and new requirements and prepared issues where needed. The SMEs re-convened to validate the updated documentation. As issues were uncovered, they were documented, analyzed, and worked toward resolution.

30

10.1 Field Level Reporting Functional Overview

Functional requirements developed for Field Level Reporting are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Field Level Reporting business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined.

As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Capture Financial Transaction Report), BEA process name (e.g. Perform Financial Reporting) and DFAS process name (e.g. Management Report).

It should be noted that only the process steps associated with Field Level Reporting are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Field Level Reporting requirements defined to date.


Perform Financial Reporting: The Perform Financial Reporting model describes how DoD will develop and release their Financial Statements. Prior to developing the Financial Statement all of the financial transactions must be consolidated from the subsidiaries and necessary adjustments must be made to close the General Ledger. Once this is complete all of the agencies Ledgers will be compiled and a corporate view will be generated. Elimination entries will occur and anomaly explanation reports will be developed. After all compilations and eliminations are complete the Financial Statements and Footnotes will be created and sent to the internal auditors for review. Once the review and necessary adjustments are made the Final Financial Statements and briefing package will be made and released.

10.2 Field Level Reporting Practices

The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Field Level Reporting DoD financial and accounting requirements. In addition, sample report formats are provided for each of the Field Level Reports as Attachment 1 to this FRD. By complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies.




31





10.3.4 Assign Rejected Requirement to Other Core Teams

Release 6.0 includes requirements that were reclassified as being out of scope for Field Level Reporting. These requirements were identified and considered for inclusion in another team’s functional requirements.




Field Level Reporting did not develop additional process models.




The Field Level Reporting requirements were not compared to the DoD Transaction Library since Field Level Reporting does not create transactions.

32

11.0 Financial Reporting Concept of Operation

In October 2006, the SSD was tasked to establish a set of functional requirements for Financial Reporting. To accomplish this mission it was necessary to map all requirements extracted from the authoritative sources listed in section 2.1 to the current BEA model and identify any gaps if they existed.

First, the work group gathered existing Financial Reporting functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group.

Next, Financial Reporting SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution.

From the BEA diagrams, the Financial Reporting Working Group determined what additional processes were needed. The group then identified gaps within the Financial Reporting process models and steps. The Financial Reporting Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify:





11.1 Financial Reporting Functional Overview

Functional requirements developed for Financial Reporting are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Financial Reporting business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined.

As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Capture Financial Transaction Report), BEA process name (e.g. Perform Financial Reporting), and the DFAS process name (e.g. Manage Financial Reporting Requirement).

It should be noted that only the process steps associated with Financial Reporting are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model

33

are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Financial Reporting requirements defined to date.

The following is one of the process models that are included:


11.2 Financial Reporting Practices

The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Financial Reporting DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies.



During Release 6.0 the Shared Services completed integration or cross function validation of the functional requirements. In Release 6.0 requirements were mapped to the lowest level possible within the BEA architecture and if appropriate to multiple lower levels. Once completed, the requirements functionally linked by architectural process were identified. Shared Services integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links.






Release 6.0 includes requirements that were reclassified as being out of scope for Financial Reporting. These requirements were identified and considered for inclusion in another team’s functional requirements.


In Release 6.0, the functional branches continuously performed internal team review of the requirements to ensure that all functional requirements adhered to the following quality

34

characteristics: necessary, achievable, correct, unambiguous, complete, consistent, concise, singular, implementation-free, and testable. All requirements that were not written to the standards above were either: rewritten, rejected or transferred for management decision.


Financial Reporting did not develop additional process models for Release 6.0.




The Financial Reporting requirements were not compared to the DoD Transaction Library since Financial Reporting does not create transactions.

35

12.0 Foreign Military Sales Concept of Operation

In July 2009, the SSD was tasked to establish a set of functional requirements for Foreign Military Sales. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed.

First, the working group gathered existing Foreign Military Sales functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group. The working group also documented the standard DFAS process.

Next, Foreign Military Sales SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution.

From the BEA diagrams, the Foreign Military Sales Working Group determined what additional processes were needed. The group then identified gaps within the Foreign Military Sales process models and steps. The Foreign Military Sales Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify:





12.1 Foreign Military Sales Functional Overview

Functional requirements developed for Foreign Military Sales are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Foreign Military Sales business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined.

As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Accounts Payable/Accounts Receivable), BEA process name (e.g. Conduct Payables/Conduct Receivables) and the DFAS process name (e.g. Foreign Military Sales).

It should be noted that only the process steps associated with Foreign Military Sales are being addressed by this document. Therefore, in some instances, the incorporated business process

36

models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Foreign Military Sales requirements defined to date.

The FMS process is unique in that a majority of FMS requirements resides in Accounts Payable, Accounts Receivable, Financial Reporting, Funds Control and Budgetary Accounting, General Ledger, and Managerial Cost Accounting. Another portion of the FMS unique financial requirements are performed by DFAS-IN and Defense Contract Management Agency (DCMA) and not in the ERPs.

12.2 Foreign Military Sales Practices

The requirements in the database were developed for all systems and business operations to be compliant with the Foreign Military Sales DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies.









Release 6.0 includes requirements that were reclassified as being out of scope for Foreign Military Sales. These requirements were identified and considered for inclusion in another team’s functional requirements.



37


The Foreign Military Sales developed additional process models for Release 6.0.




The Foreign Military Sales transactions were not compared to the DoD Transaction Library since Foreign Military Sales does not create transactions.

38

13.0 Funds Control and Budgetary Accounting Concept of Operation

In October 2008, the SSD was tasked to establish a set of functional requirements for Funds Control and Budgetary Accounting. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed.

First, the working group gathered existing Funds Control and Budgetary Accounting functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group.

Next, Funds Control and Budgetary Accounting SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. However, SMEs were not available for this release.

From the BEA diagrams, the Funds Control and Budgetary Accounting Working Group determined what additional processes were needed. The group then identified gaps within the Funds Control and Budgetary Accounting process models and steps. The Funds Control and Budgetary Accounting Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify:




The accompanying spreadsheet contains the standard functional requirements and business rules mapped to the appropriate process flows/steps.

13.1 Funds Control and Budgetary Accounting Functional Overview

Functional requirements developed for Funds Control and Budgetary Accounting are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Funds Control and Budgetary Accounting business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined.

As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Financial Visibility) and BEA process name (e.g. Perform Planning, Programming, Budgeting, Funds Distribution and Control).

It should be noted that only the process steps associated with Funds Control and Budgetary Accounting are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Funds Control and Budgetary Accounting requirements defined to date.

39


Execute Apportionment and Allocate Funds Execute Continuing Resolution Manage Report of Programs Manage Execution Fund Account Perform Budgeting Perform Reprogramming and Transfers Execute Rescission, Cancellation and Deferrals Financial Visibility Manage Execution Fund Account Post General Ledger Manage General Ledger Perform Financial Reporting

13.2 Funds Control and Budgetary Accounting Practices

The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Funds Control and Budgetary Accounting DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies.









Release 6.0 includes requirements that were reclassified as being out of scope for Funds Control and Budgetary Accounting. These requirements were identified and considered for inclusion in another team’s functional requirements.

40




The Funds Control and Budgetary Accounting did not develop additional process models.




The Funds Control and Budgetary Accounting requirements were compared to the DoD Transaction Library. Missing requirements were developed and included to encompass any gaps between the documents.

41

14.0 General Ledger Concept of Operation

In October, 2006, the SSD was tasked to establish a set of functional requirements for General Ledger. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed.

This document establishes the context for the DoD standard functional requirements in the area of General Ledger. General Ledger Management is the central function of the Core financial management system. All transactions to record financial events must post to the general ledger, regardless of the origin of the transaction. Transactions originating in other systems may post to the general ledger at a summary level, depending on an agency’s overall financial management system design and need. At a minimum, summary transactions must post at a level that maintains the accounting classification elements and attributes needed to support central agency reporting. The General Ledger project is focused on developing standardized functional requirements pertaining to General Ledger only. Intergovernmental to include Interfund and Intragovernmental Payment and Collection (IPAC), Accounts Receivable, Accounts Payable, and Disbursing requirements are out of scope. The related requirements for Cash Accountability and Financial Reporting are out of scope, but will be shared accordingly as touch-points and interfaces captured during the integration portion of the project. Managerial Accounting & Budget and Funds Distribution & Internal Controls are also out of scope. These functional requirements apply to both general funds and working capital funds.

First, the working group gathered existing General Ledger functional requirements and business rules from available sources. These requirements were consolidated, reviewed, mapped to business processes, and pre-validated by the working group.

The General Ledger Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify:




Next, General Ledger SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution.

At the completion of the JAD session, the General Ledger working group reviewed the comments and new requirements developed by the SMEs and prepared issues where necessary. Then, the SMEs re-convened the JAD session to validate their earlier work and each SME was given the opportunity to provide their comments and rationale regarding each requirement. As issues were uncovered, they were documented, logged, analyzed, and worked toward final resolution.

42

14.1 General Ledger Functional Overview

Functional requirements developed for General Ledger are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed General Ledger business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined.

As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Post General Ledger Transactions) and BEA process name (e.g. Post to General Ledger).

It should be noted that only the process steps associated with General Ledger are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the General Ledger requirements defined to date.


Manage Financial Management Policy: The Manage Financial Management Policy process begins from receiving a new requirement from an internal or external customer. The process determines whether notification to the OUSD(C) is required or not. The requirements are then analyze to identify proposals for implementation. Control Board approval is required for changes to the Chart of Accounts, SFIS Attributes, Pro Forma Entries or Calendar. There should be relevant coordination within DoD prior to processing the policy changes.

Manage General Ledger: This process includes the ability to record financial transactions as updates to specific proprietary, budgetary, and memorandum general ledger accounts in accordance with Federal Accounting Standard Advisory Board (FASAB) standards, General Accepted Accounting Principles (GAAP) and regulatory requirements; to define the use of, and rules to, control General Ledger accounts; and to conduct General Ledger analyses and reconciliations.


Post to General Ledger: This process model describes how DoD will account for all of their journal entries. The process captures all of the pro forma entries, which collects all of the un-posted charge/credits or cash receipts from the subsidiary ledgers, either by batch number or by entry date and then generates the transactions that will be placed into the General Ledger. Once all of the transactions are developed they will be summarized by account and optionally

43

by charge/credit code, and then adds them to the General Ledger with the corresponding credit and debit amounts. This posting maintains a complete audit trail of all transactions within DoD and records the business events and reports the financial condition of the Department of Defense.

14.2 General Ledger Practices

The requirements in the accompanying spreadsheet were developed to allow the DoD financial community the ability to record proprietary and budgetary general ledger transactions in accordance with FASAB standards, GAAP and regulatory requirements. These requirements, business rules, and best practices will be utilized to define the use of, and rules to, control general ledger accounts and to conduct analyses and reconciliations. This will ensure that Organizations across the enterprise network are able to support and post to a DoD corporate general ledger in a standard, consistent manner that satisfies federal regulatory requirements. Consistent use of the general ledger provides enhanced audit ability and analytical transparency. The requirements in the accompanying spreadsheet reflect the to-be model for the General Ledger processes. There is a current and on-going effort to refine the U.S. Standard General Ledger (USSGL) Transaction Library in an attempt to identify the business events that are unique to the DoD business. The development of the standard functional requirements for the general ledger project coupled with the refining of the USSGL Transaction Library will ensure that all general ledger postings are consistent and that all gaps are filled.



During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.0, requirements were mapped to the lowest level possible within the BEA architecture and, if appropriate, to multiple lower levels. Once completed, the requirements functionally linked by architectural process were identified. Shared Services integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. Missing requirements were developed and included in the General Ledger requirements database to encompass any gaps between the documents.


The Shared Services Branches further integrated functional requirements by identifying requirements that were touch points between functions. The teams conducted cross team reviews and updated the requirements based upon touch points between functions.




Release 6.0 includes requirements that were reclassified as being out of scope for General Ledger. These requirements were identified and considered for inclusion in another team’s functional requirements.

44




General Ledger did not develop additional process models for Release 6.0.




For Release 6.0, there were no General Ledger DoD Transaction Library requirements. However, as a part of Release 4.0, functional requirements were mapped to the DoD transaction library and their associated general ledger affects. Shared Services Functional Branches reviewed, analyzed, and updated requirements based upon general the ledger scenarios. The requirements from other functional areas were updated to include the DTC contained in the DoD transaction Library. All transaction library scenarios and their general ledger affects were reviewed for possible inclusion in the requirements. This ensured general ledger debit and credit pairs were linked to the associated functional requirements.

45

15.0 Guaranteed Loans Concept of Operation

In May 2009, the SSD was tasked to establish a set of functional requirements for Guaranteed Loans. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed.

First, the working group gathered existing Guaranteed Loans functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group. The working group also documented the standard DFAS process.

Next, Guaranteed Loans SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution.

From the BEA diagrams, the Guaranteed Loans Working Group determined what additional processes were needed. The group then identified gaps within the Guaranteed Loans process models and steps. The Guaranteed Loans Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify:





15.1 Guaranteed Loans Functional Overview

Functional requirements developed for Guaranteed Loans are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Guaranteed Loans business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined.

As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Manage General Ledger), BEA process name (e.g. Record Loans and Grants) and the DFAS process name (e.g. Lender Eligibility Process).

It should be noted that only the process steps associated with Guaranteed Loans are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model

46

are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Guaranteed Loans requirements defined to date.


Manage General Ledger - The ability to record financial transactions as updates to specific proprietary, budgetary, and memorandum general ledger accounts in accordance with Federal Accounting Standard Advisory Board standards, General Accepted Accounting Principles and regulatory requirements; to define the use of, and rules to, control General Ledger accounts; and to conduct General Ledger analyses and reconciliations.

Record Loans and Grants - This process records the financial impact of business events related to the award, origination, performance, payment, collection and closeout of direct loans, loan guarantees and grants.

15.2 Guaranteed Loans Practices

The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Guaranteed Loans DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies.









Release 6.0 includes requirements that were reclassified as being out of scope for Guaranteed Loans. These requirements were identified and considered for inclusion in another team’s functional requirements.


In Release 6.0 the functional branches continuously performed internal team reviews of the requirements to ensure that all functional requirements adhered to the following quality characteristics: necessary, achievable, correct, unambiguous, complete, consistent, concise,

47

singular, implementation-free, and testable. All requirements that were not written to the standards above were either rewritten, rejected, or transferred for management decision.


The Guaranteed Loans developed additional process models.




The Guaranteed Loan transactions were not compared to the DoD Transaction Library during Release 6.0. The DTCs will be mapped to the test scenarios. Then the requirements will be updated with the DTC information in a maintenance release.

48

16.0 Human Resources and Payroll – Civilian Concept of Operation

In November 2008, the SSD was tasked to establish a set of functional requirements for Human Resources and Payroll – Civilian. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed.

First, the working group gathered existing Human Resources and Payroll – Civilian functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group. The working group also documented the standard DFAS process.

Next, Human Resources and Payroll – Civilian SMEs were invited to participate in a series of Joint Application Development (JAD) sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all Enterprise Resource Planning (ERP) systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution.

From the BEA diagrams, the Human Resources and Payroll – Civilian Working Group determined what additional processes were needed. The group then identified gaps within the Human Resources and Payroll – Civilian process models and steps. The Human Resources and Payroll – Civilian Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify:





16.1 Human Resources and Payroll – Civilian Functional Overview

Functional requirements developed for Human Resources and Payroll – Civilian are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Human Resources and Payroll – Civilian business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined.

As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process diagram (e.g. Personnel Visibility), BEA process name (e.g. Develop Human Resources) and the DFAS diagram name (e.g. Civilian Pay).

49

It should be noted that only the process steps associated with Human Resources and Payroll – Civilian are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Human Resources and Payroll – Civilian requirements defined to date.


Personnel Visibility: Personnel Visibility (PV) is a process defined as the fusion of accurate human resources information and secure, interoperable technology. PV is defined as having reliable information that provides visibility of military Service members, civilian employees, military retirees, contractors (in theater), and other U.S. personnel, across the full spectrum – during peacetime and war, through mobilization and demobilization, for deployment and redeployment, while assigned in a theater of operation, at home base, and into retirement. This includes ensuring timely and accurate access to compensation and benefits for DoD personnel and their families and ensuring that Combatant Commanders have access to the timely and accurate data on personnel and their skill sets.

16.2 Human Resources and Payroll – Civilian Practices

The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Human Resources and Payroll – Civilian DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies.








50


Release 6.0 includes requirements that were reclassified as being out of scope for Human Resources and Payroll – Civilian. These requirements were identified and considered for inclusion in another team’s functional requirements.




The Human Resources and Payroll – Civilian developed additional process models.




The Human Resources and Payroll – Civilian requirements were not compared to the DoD Transaction Library since transactions are not posted to a trial balance in this area. The general ledger resides within the ERP and records the effects of those events.

51

17.0 Human Resources and Payroll – Military Concept of Operation

In November 2008, the SSD was tasked to establish a set of functional requirements for Human Resources and Payroll – Military.

First, the working group gathered existing Human Resources and Payroll – Military functional requirements from available sources. These requirements were consolidated, reviewed and pre-validated by the working group.

The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all Enterprise Resource Planning (ERP) systems.

The accompanying spreadsheet contains the standard functional requirements mapped to the appropriate process flows/steps.

17.1 Human Resources and Payroll – Military Functional Overview

Functional requirements developed for Human Resources and Payroll – Military are driven by operational architecture and compliance requirements. The Human Resources and Payroll – Military functional requirements were not mapped to the BEA 6.0 OV-6c diagrams and processes, but will be in future releases.

17.2 Human Resources and Payroll – Military Practices

The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Human Resources and Payroll – Military DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies.



In Release 6.0, the requirements were not mapped within the BEA architecture. However, the team did map all functional requirements to the DFAS process. The mapping to BEA processes will occur within a future maintenance release.






Release 6.0 includes requirements that were reclassified as being out of scope for Human Resources and Payroll – Military. These requirements were identified and considered for inclusion in another team’s functional requirements.

52




The Human Resources and Payroll – Military did not develop additional process models. The team will document the DFAS processes in a future maintenance release.




The Human Resources and Payroll – Military requirements were not compared to the DoD Transaction Library since transactions are not posted to a trial balance in this area. The general ledger resides within the ERP and records the effects of those events.

53

18.0 Intra-governmental Concept of Operation

In October 2006, the SSD was tasked to establish a set of functional requirements for Intra-governmental. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed.

First, the working group gathered existing Intra-governmental functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group. The working group also documented the standard DFAS process.

Next, Intra-governmental SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution.

From BEA diagrams, the Intra-governmental Working Group determined what additional processes were needed. The group then identified gaps within the Intra-governmental process models and steps. The Intra-governmental Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify:





18.1 Intra-governmental Functional Overview

Functional requirements developed for Intra-governmental are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Intra-governmental business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined. Since Intra-governmental is contained within multiple areas such as Accounts Payable and Accounts Receivable, there is no specific BEA Intra-governmental diagram.

The requirements contained within, represent a set of standard requirements that will optimize the effectiveness and efficiency of Intra-governmental Buyer and Seller operations throughout DoD. These standard functional requirements will also provide a comprehensive repository of Intra-governmental requirements for future system development efforts.

54

18.2 Intra-governmental Practices

The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Intra-governmental DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies.









Release 6.0 includes requirements that were reclassified as being out of scope for Intra-governmental. These requirements were identified and considered for inclusion in another team’s functional requirements.




The Intra-governmental developed an additional DFAS process model.



55


Functional requirements were mapped to the DoD transaction library and their associated general ledger affects. Shared Services reviewed, analyzed and updated requirements based upon general the ledger scenarios. The requirements were updated to include the DTC contained in the DoD Transaction Library. All transaction library scenarios and their general ledger affects were reviewed for possible inclusion in the requirements. This ensured general ledger debit and credit pairs were linked to the associated functional requirements.

The Intra-governmental requirements were compared to the DoD Transaction Library. Missing requirements were developed and included in the Intra-governmental Transactions database to encompass any gaps between the documents.

56

19.0 Intra-Governmental Eliminations Concept of Operation

In November 2008, the SSD was tasked to establish a set of functional requirements for Intra-Governmental Eliminations. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed.

First, the working group gathered existing Intra-Governmental Eliminations functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group.

Next, Intra-Governmental Eliminations SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution.

From the BEA diagrams, the Intra-Governmental Eliminations Working Group determined what additional processes were needed. The group then identified gaps within the Intra-Governmental Eliminations process models and steps. The Intra-Governmental Eliminations Working Group then mapped the standard functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify:





19.1 Intra-Governmental Eliminations Functional Overview

Functional requirements developed for Intra-Governmental Eliminations are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Intra-Governmental Eliminations business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined.

As the intra-governmental elimination processes were identified, the functional requirements were mapped to a DFAS process diagram developed by the Working Group.

It should be noted that only the process steps associated with Intra-Governmental Eliminations are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an

57

indication that they are not applicable to the Intra-Governmental Eliminations requirements defined to date.

The following DFAS process model is included:

DFAS Elimination Process - The DFAS Elimination Process Model is intended to demonstrate the flow of intra-governmental transactions between field level accounting offices, departmental accounting offices and OMB/Treasury.

19.2 Intra-Governmental Eliminations Practices

The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Intra-Governmental Eliminations DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies.

A current DoD accounting system has not been put into place to identify IG transactions for elimination. As a result, the multiple accounting systems in use by DoD do not capture and maintain all of the data required for balancing accounts, or capture the data in a standard format that permits easy cross-referencing. These accounting systems do not capture trading partner information at the transaction level; therefore, current systems cannot identify those transactions to be eliminated for reporting purposes.

Currently, eliminations are done at the entity code level and reported through the Defense Departmental Reporting System (DDRS). Interfaces between the various accounting systems and DDRS are manual and accomplished through a business practice of data calls, journal vouchers, crosswalk tables, and an import spreadsheet. The level of detail is determined by the users and customers and varies significantly. The elimination of Intra-governmental transactions is currently accomplished by forcing the buyer’s books to match the seller’s.

The future or “to-be” environment shall contain the proper data elements such as Business Partner Number (BPN) and common document number (linking buyer to seller) to process, trace, and eliminate Intra-Governmental transactions. It shall also have the capability to accept files or data from an accounting entitlement system, or ERP module. It will compare, match, or suspend transactions (or business processes) that fail validation. The system must also allow interface or online entry of customer and line of accounting data, order and bill data, access controls, internal controls, and business process suspension when the corresponding buyer/seller transactions are not in balance. The buyer/seller must be linked from end-to-end upon establishment of the buyer/seller agreement. All Standard Financial Information Structure (SFIS) mandatory data elements will be used, and a drill down reporting capability will exist on all data elements relevant to analysis, research, and reporting. The functional requirements shall enable the processing and facilitation of proper elimination at all levels of Intra-governmental transactions. Until end-state, when ERP systems are integrated, the DoD will provide seller reports to buyers and reconcile and balance Intra-Governmental transactions as instructed in TFM Bulletin 07-03.



During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.0, requirements were mapped to the lowest level possible within the BEA architecture and, if appropriate, to multiple lower levels. Once completed, the

58

requirements functionally linked by architectural process were identified. Shared Services integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links.






Release 6.0 includes requirements that were reclassified as being out of scope for Intra-Governmental Eliminations. These requirements were identified and considered for inclusion in another team’s functional requirements.




The Intra-Governmental Eliminations Working Group developed additional process.




Intra-Governmental Elimination transactions do not impact General Ledger accounts. General Ledger accounts are impacted at the time an accounting transaction is initially input. Intra-Governmental Elimination transactions merely separate previously recorded intra-governmental accounting transactions from public accounting transactions for reporting purposes. Because of this, the Intra-Governmental Elimination requirements were not compared to the DoD Transaction library.

59

20.0 Inventory, Operating Materials and Supplies, and Stockpile Materials Concept of Operation

In May 2009, the SSD was tasked to establish a set of functional requirements for IOMSSM. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed.

First, the working group gathered existing IOMSSM functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group.

Next, IOMSSM SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The IOMSSM functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements, as needed. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution. Since no issues materialized, no issue papers were written and a JAD session was not held.

From the BEA diagrams, the IOMSSM Working Group determined the DFAS processes that were needed. The group then identified gaps within the IOMSSM process models and steps. The IOMSSM working group then mapped the standard IOMSSM functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify:




The accompanying spreadsheet contains the standard functional requirements mapped to the appropriate process flows/steps for Release 6.0.

20.1 Inventory, Operating Materials and Supplies, and Stockpile Materials Functional Overview

This project includes the recording and reporting of IOMSSM financial information outside the core financial system. Functional requirements developed for IOMSSM are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed.

As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process, diagram, and activity. IOMSSM is part of the Property and Material activity in the BEA. Even IOMSSM encompasses both Financial Visibility and Material Visibility diagrams within BEA Property and Materiel activity, the requirements in this project only impact Financial Visibility.

60

20.2 Inventory, Operating Materials and Supplies, and Stockpile Materials Practices

The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the IOMSSM DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies.



During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.0, requirements were mapped to the lowest level possible within the BEA architecture and, if appropriate, to multiple lower levels. Once completed, the requirements functionally linked by architectural process were identified. Shared Services integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. The IOMSSM working group gathered the business rules from the BEA 6.0.






Release 6.0 includes requirements that were reclassified as being out of scope for IOMSSM. These requirements were identified and considered for inclusion in another team’s functional requirements.




The IOMSSM did not develop additional process models.



61


The IOMSSM requirements were not compared to the DoD Transaction Library since transactions are not posted to a trial balance in this area. The general ledger resides within the ERP and records the effects of those events.

62

21.0 Managerial Cost Accounting Concept of Operation

In October 2008, the SSD was tasked to establish a set of functional requirements for MCA. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current Business Enterprise Architecture model and identify any gaps if they existed.

First, the working group gathered existing MCA functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group.

Next, MCA SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements, as needed. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution.

From the BEA diagrams, the MCA Working Group determined what additional processes were needed for MCA. The group then identified gaps within the MCA process models and steps. BTA and the MCA working group then mapped the standard MCA functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify:




The accompanying spreadsheet contains the standard functional requirements, business rules, and best practices mapped to the appropriate process flows/steps for Version 1.0.

21.1 Managerial Cost Accounting Functional Overview

Functional requirements developed for MCA are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed MCA business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined.

As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Perform Managerial Cost Accounting), BEA process name (e.g. Define Cost Performance Model) and the DFAS process name (e.g. Identify Costs).

As an incremental project, the MCA FRD will expand with each subsequent version to incorporate the applicable process models and requirements. Each Version 1.x document will be a cumulative document, and will incorporate all functional requirements mapped to applicable

63

processes which are finalized with subsequent versions. The process models will continue to be refined in later versions of the FRD as additional requirements are identified and existing requirements are assessed in detail.

It should be noted that only the process steps associated with MCA are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the MCA requirements defined to date.


Perform Managerial Cost Accounting Define Cost Performance Model* Populate Cost Performance Model** Perform Cost Analysis***

* The Define Cost Performance Model process incorporated into this document is a subset of the BEA Perform Managerial Accounting model and reflects the initial steps to Define Cost Performance Model and establishes Managerial Cost Accounting. Define Cost Performance Model is further broken down into DFAS lower-level processes: Identify Costs, Assign Costs, and Maintain Cost Information. This diagram will be expanded to incorporate all BEA process steps as additional requirements are defined in later versions.

** The Populate Cost Performance Model process incorporated into this document is also a subset of the BEA Perform Managerial Accounting model and reflects the initial steps to Populate Performance Model. Populate Cost Performance Model is further broken down into DFAS lower-level processes: Accumulate Costs, Distribute Costs, Record Costs, Allocate Costs, and Send/Transfer Costs.

*** The Perform Cost Analysis process incorporated into this document is also a subset of the BEA Perform Managerial Accounting model and reflects the initial steps to Perform Cost Analysis. Perform Cost Analysis is further broken down into DFAS lower-level processes: Calculate Costs, Produce/Provide Costs, Reconciliation Costs, and Capture Costs.

21.2 Managerial Cost Accounting Practices

The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the MCA DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies.



The Shared Services completed integration or cross-function validation of the functional requirements. Requirements were mapped to the lowest level possible within the BEA architecture and, if appropriate, to multiple lower levels. Once completed, the requirements functionally linked by architectural process were identified. Shared Services integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links.

64




Authoritative Source updates to the requirements included Regulation or Policy changes received through March 2009. Shared Services updated the requirements based upon peer and Branch Supervisory reviews.


Release 6.0 includes requirements that were reclassified as being out of scope for MCA. These requirements were identified and considered for inclusion in another team’s functional requirements.


The functional branches continuously performed internal team reviews of the requirements to ensure that all functional requirements adhered to the following quality characteristics: necessary, achievable, correct, unambiguous, complete, consistent, concise, singular, implementation-free, and testable. All requirements that were not written to the standards above were either rewritten, rejected, or transferred for management decision.


The MCA team developed additional process models.




The MCA were not compared to the DoD Transaction Library since MCA does not create transactions.

65

22.0 Property, Plant, and Equipment Concept of Operation

In May 2009, the SSD was tasked to establish a set of functional requirements for Property, Plant, and Equipment. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed.

First, the working group gathered existing Property, Plant, and Equipment functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group.

Next, Property, Plant, and Equipment SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements, as needed. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution. Since no issues materialized, no issue papers were written and a JAD session was not held.

From the BEA diagrams, the Property, Plant, and Equipment Working Group determined the DFAS processes that were needed. The group then identified gaps within the Property, Plant, and Equipment process models and steps. The Property, Plant, and Equipment working group then mapped the standard Property, Plant, and Equipment functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify:




The accompanying spreadsheet contains the standard functional requirements and business rules mapped to the appropriate process flows/steps.

22.1 Property, Plant, and Equipment Functional Overview

This project includes the recording and reporting of Property, Plant, Equipment, Seized Property, and Forfeited Assets financial information outside the core financial system. Functional requirements developed for Property, Plant, and Equipment are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Property, Plant, and Equipment business processes.

As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process, diagram, and activity. Property, Plant, and Equipment is part of the Property and Material activity in the BEA. Property, Plant, and Equipment

66

encompasses both Financial Visibility and Material Visibility diagrams within BEA Property and Materiel activity, the requirements in this project only impact Financial Visibility.

22.2 Property, Plant, and Equipment Practices

The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Property, Plant, and Equipment DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies.



During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.0, requirements were mapped to the lowest level possible within the BEA architecture and, if appropriate, to multiple lower levels. Once completed, the requirements functionally linked by architectural process were identified. Shared Services integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links. The working group gathered the business rules from the BEA 6.0.






Release 6.0 includes requirements that were reclassified as being out of scope for Property, Plant, and Equipment. These requirements were identified and considered for inclusion in another team’s functional requirements.




The Property, Plant, and Equipment Working Group did not develop additional process models.


Issues identified during Release 6.0 were documented and tracked in the issue tracking tool until resolution. Those issues that could not be resolved by the FMCoE staff were transferred to the

67

office that had responsibility for oversight of the respective issues. Once the issue was resolved, the issue was closed in the issue tracking tool.


The Property, Plant, and Equipment requirements were not compared to the DoD Transaction Library since transactions are not posted to a trial balance in this area. The general ledger resides within the ERP and records the effects of those events.

68

23.0 Time and Attendance Concept of Operation

In February 2009, the SSD was tasked to establish a set of functional requirements for T&A. To accomplish this mission, it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed.

First, the working group gathered existing T&A functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group.

Next, T&A SMEs were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The T&A functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SMEs felt additional requirements should be written to add clarity or detail, they drafted new requirements, as needed. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution.

The T&A working group mapped the standard Time and Attendance functional requirements to the applicable process diagram. The review of processes and mapping of functional requirements to business processes served to identify:





23.1 Time and Attendance Functional Overview

Functional requirements developed for T&A are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed T&A business processes. When needed, the BEA processes are further decomposed to provide additional detail and to ensure that a standard comprehensive process is defined.

As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Personnel Visibility), BEA process name (e.g. Manage Personnel and Pay) and the DFAS process name (e.g. Human Resources and Payroll).

As an incremental project, the T&A FRD will expand with each subsequent version to incorporate the applicable process models and requirements. Each Version 1.x document will be a cumulative document, and will incorporate all functional requirements mapped to applicable processes which are finalized with subsequent versions. The process models will continue to be refined in later versions of the FRD as additional requirements are identified and existing requirements are assessed in detail.

69

It should be noted that only the process steps associated with T&A are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the T&A requirements defined to date.


Record Time and Attendance Personnel Visibility * Manage and Sustain Personnel** Manage Personnel and Pay ***

* The Personnel Visibility Model process incorporated into this document is a subset of the BEA Record Time and Attendance model and reflects the initial steps to Personnel Visibility Model and establishes Time and Attendance. Personnel Visibility Model is further broken down into DFAS lower-level processes. This diagram will be expanded to incorporate all BEA process steps as additional requirements are defined in later versions.

** The Manage and Sustain Personnel Model process incorporated into this document is also a subset of the BEA Record Time and Attendance model and reflects the initial steps to Manage Personnel Model. Manage and Sustain Personnel Model is further broken down into DFAS lower-level processes.

*** The Manage Personnel and Pay process incorporated into this document is also a subset of the BEA Record Time and Attendance model and reflects the initial steps to Manage Personnel and Pay. Manage Personnel and Pay is further broken down into DFAS lower-level processes.

23.2 Time and Attendance Practices

The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the T&A DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies.



During Release 6.0 the Shared Services completed integration or cross-function validation of the functional requirements. In Release 6.0 requirements were mapped to the lowest level possible within the BEA architecture and, if appropriate, to multiple lower levels. Once completed, the requirements functionally linked by architectural process were identified. Shared Services integrated these requirements by reviewing, analyzing and updating the requirements based upon missing or necessary architectural and functional links.



70




Release 6.0 included requirements that were reclassified as being out of scope for T&A. These requirements were identified and considered for inclusion in another team’s functional requirements.




The T&A team developed additional process models for Release 6.0.




The T&A requirements were not compared to the DoD Transaction Library since transactions are not posted to a trial balance in this area. The general ledger resides within the ERP and records the effects of those events.

71

24.0 Travel Concept of Operation

In October 2008, the SSD was tasked to establish a set of functional requirements for Travel. To accomplish this mission it was necessary to map all requirements extracted from the sources listed in section 2.1 to the current BEA model and identify any gaps if they existed.

First, the working group gathered existing Travel functional requirements and business rules from available sources. These requirements were consolidated, reviewed and pre-validated by the working group.

Next, Travel SME’s were invited to participate in a series of JAD sessions to review and validate the requirements for applicability as a DoD standard in each process area. The Travel functional requirements were defined to a level ensuring consistency of internal controls, reporting, and accounting and to make certain each functional requirement can be implemented consistently across all ERP systems. If SME’s felt additional requirements should be written to add clarity or detail, they drafted new requirements, as needed. If issues were uncovered at any time during this development process, they were identified, logged, and worked toward resolution.

The Travel working group mapped the standard functional requirements to the applicable process step. The review of processes and mapping of functional requirements to business processes served to identify:




The accompanying spreadsheet contains the standard functional requirements and best practices mapped to the appropriate BEA process flows/steps.

24.1 Travel Functional Overview

Functional requirements developed for Travel are driven by operational architecture and compliance requirements. One of the features of this project is the validation of the BEA processes and their extension, where needed. As such, the business processes models defined in the BEA 6.0 OV-6c model have been used as a starting point for the identification and development of more detailed Travel business processes. When needed, the BEA processes are further broke down to provide additional detail and to ensure that a standard comprehensive process is defined.

As the processes were identified, the functional requirements were mapped to them. This includes identifying the BEA process flow (e.g. Perform Travel Pay), BEA process name (e.g. Define Travel Pay Model) and the DFAS process name (e.g. Identify Travel Pay Costs).

As an incremental project, the Travel FRD will expand with each subsequent version to incorporate the applicable process models and requirements. Each Version 1.x document will be a cumulative document, and will incorporate all functional requirements mapped to applicable processes which are finalized with subsequent versions. The process models will continue to be refined in later versions of the FRD as additional requirements are identified and existing requirements are assessed in detail.

72

It should be noted that only the process steps associated with Travel are being addressed by this document. Therefore, in some instances, the incorporated business process models will not completely reflect the BEA model. If process steps in the BEA process model are omitted from this document, it is NOT indicating they are not required. It is only an indication that they are not applicable to the Travel requirements defined to date.


Perform Travel Pay Define Travel Pay Performance Model* Populate Travel Pay Model**

* The Define Travel Pay Performance Model process incorporated into this document is a subset of the BEA Perform Managerial Accounting model and reflects the initial steps to Define Travel Pay Performance Model and establishes Travel Pay Accounting.

** The Populate Travel Pay Performance Model process incorporated into this document is also a subset of the BEA Perform Travel Pay model and reflects the initial steps to Populate Performance Model.

24.2 Travel Accounting Practices

The requirements in the accompanying spreadsheet were developed for all systems and business operations to be compliant with the Travel DoD financial and accounting requirements. Additionally, by complying with these requirements, systems and business operations will be compliant with the applicable laws, regulations and policies.









Release 6.0 included requirements that were reclassified as being out of scope for a specific functional area. These requirements were identified and considered for inclusion in another team’s functional requirements.

73




Travel did not develop additional process models.




The Travel requirements were not compared to the DoD Transaction Library since transactions are not posted to a trial balance in this area. The general ledger resides within the ERP and records the effects of those events.

74

25.0 Shared Services Points of Contact

25.1 Shared Services Division Hotline Email

The SSD has established a hotline email address which may be used to provide comments or request information regarding the use of the functional requirements and FRD. The Shared Services Hotline email is [email protected].

25.2 World Wide Web

The FMCoE, SSD has established a web site titled "Standard Finance & Accounting Requirements" which may be used to access the functional requirements documentation. The web site URL is: http://www.dfas.mil/more/fmcoe/standardfinanceaccountingrequirements.html

25.3 Scenario Database

In Release 4.0, Shared Services implemented a Scenario Database for writing, storing, updating and retrieving the functional requirements for mapping to various Scenarios. Requirements for all functional areas are included in the Database. Tailored Access Reports are available for staff use; however, tailored Access Reports can be made available for customer use upon request.

25.4 BEA 6.0 Architecture

Below is the link to the BEA 6.0 architecture where you can view diagrams, processes, and activity models.

http://www.bta.mil/products/bea/html_files/dodaf.html

75

http://www.bta.mil/products/bea/html_files/dodaf.html

http://www.dfas.mil/more/fmcoe/standardfinanceaccountingrequirements.html

mailto:[email protected]

Appendix 1 – Acronyms

AP Accounts PayableAR Accounts ReceivableBEA Business Enterprise ArchitectureBEIS Business Enterprise Information SystemBEP Business Enterprise PriorityBID Business Integration DivisionBPM Business Process ModelBPN Business Partner NumberBPR Business Process ReengineeringBTA Business Transformation AgencyCA Cash AccountabilityCCB Configuration Control BoardDDRS Defense Departmental Reporting SystemDEAMS Defense Enterprise Accounting and Management SystemDFAS Defense Finance and Accounting ServiceDISB DisbursingDMI Desktop Management InitiativeDOORS Dynamic Object-oriented Requirements SystemDoD Department of DefenseERP Enterprise Resource PlanningFASAB Federal Accounting Standards Advisory BoardFASB Financial Accounting Standards BoardFBS Functional Business SupportFMCoE Financial Management Center of ExcellenceFMR Financial Management RegulationsFR Financial ReportingGAAP Generally Accepted Accounting PrinciplesGAO Government Accountability OfficeGFEBS General Fund Enterprise Business SystemGL General LedgerHPO High Performing OrganizationIG Intra-GovernmentalIGE Intra-Governmental EliminationsIT Information TechnologyJAD Joint Applications DevelopmentMCA Managerial Cost AccountingOA Operational ArchitectureOMB Office of Management and BudgetSME Subject Matter ExpertSSD Shared Services DivisionTFM Treasury Financial ManualWBS Work Breakdown Structure

76

functional requirement document

Documents

new functional requirements

reclassified requirements

accounts receivable

bea processes

tomanagerial cost accounting

payroll military inventory

stockpile material property

operating materials