**Appendix D: Contributors**

**JFMIP White Paper:  Financial System Data Conversion Considerations**

**White Paper:**

**Financial Systems Data Conversion –**

**Considerations**

###### December 20, 2002

## TABLE OF CONTENTS

Background3

Data Conversion Issues/Questions4

Scope of the Project4

I.Conversion Tasks

Pre-Conversion5

Develop Conversion Plan5

Define Function and Data in Legacy System6

Identify Interfaces6

Define Functions and Date in New System6

Determine Security Rights6

Risk Assessment and Management6

Determining Data Conversion Requirements7

Data Mapping8

Data Clean-Up8

Ensuring Integrity of Edits and Validation in the New System9

Establishing and Testing Set-Up Data and Configuration9

Cutover Tasks9

Post Installation tasks10

II.System Data Conversion

System Conversion Timing

Conversion Options12

Beginning-of-the-Year Conversions12

Mid-Year Conversions12

Incremental Approach to Data Conversion13

System Conversion Options13

Direct Conversion Options

Opting Not to Conduct a Data Conversion14

Processing New Transactions and Activity Only14

Establishing Transaction Balances in the New System for Reporting

Purposes14

Converting Open Transactions from the Legacy System14

Closed Prior Year Transactions with New Activity15

III.Definitions16

IV.Contributors17

## BACKGROUND

Of the many critical tasks necessary to successfully implement a new financial system, data conversion**is one of the most frequently underestimated. From the outset, it should be understood that financial systems data conversion is a complex and difficult task that requires highly skilled staff to conduct successfully.  If data conversion is done right, the new system has the opportunity for success.  However, converting data incorrectly has lengthy and long-term repercussions.

This "JFMIP White Paper" is intended to raise awareness of financial systems data conversion considerations to be addressed by financial management executives and project managers, when planning or implementing a new financial management system.  (This is not a how-to manual.)  This White Paper updates selected information currently contained in the JFMIP *Framework for Federal Financial Management Systems*, FFMSR-0, issued in January 1995, regarding transitioning to a new system.  This document is not intended to be a comprehensive system conversion check list.  A more comprehensive plan would have to be developed to guide development of system conversion.  Software vendors frequently have methodologies defined based on lessons learned.

Data conversion is defined as the modification of existing data to enable it to operate with similar functional capability in a different environment.

## Automated versus Manual Conversion.

Automated conversion is the process of transferring selected transactions from the legacy system to the new one, through use of an automated tool or custom developed software.  It could also be considered an interface.  The development of interface software to support the conversion may be unavoidable for large systems.  Prior to determining that an automated conversion is required, full cost of the conversion should be developed.  Careful consideration should be given to the cost-effectiveness of developing custom software to perform what is essentially a one-time task.  The conversion might be scrutinized to determine if modifying the data is a more cost-effective approach.  Conversions become more-than-one-time tasks if the implementation methodology includes multiple, comprehensive testing cycles of the new system or dry-runs of the conversion software/processes.  Also, if the legacy system continues to operate then the conversion software may be needed for future conversions to the new system.  Lastly, some conversion software can become operational interfaces. The feasibility, risk and resources required for developing custom software should be carefully evaluated.  The volume of data and difficulty in performing an automated conversion are examples of factors that are considered in determining whether to use a manual or automated conversion process.

## Data Conversion Issues/Questions

There are also specific issues that apply uniquely to the replacement of a financial system. This includes:

· identifying specific open transactions and balances to be established;

· consideration of data conversion approaches and implications;

· analysis and reconciliation to validate transactions and data; and

· establishing transactions and balances in the new system through an automated or manual process.

This paper addresses the following questions:

· What are the key considerations regarding data conversion and cutover to the new system?

· What are the best approaches for completing the data conversion and cutover?

· What are the benefits and processes to reduce risks of the various approaches?

***Scope of the Project***

Prior to proceeding on to the conversion process, the scope of the project needs to be determined.  The scope of the project will determine the cost, length of time for the conversion, and the number of personnel or contractors involved.  Answering the following questions may be useful for determining the scope.

· What are the outputs of the current system?

· Are there new data requirements that the new system must meet?

· What are the priorities and risks with the data conversion?

· How will continuity be maintained during the conversion/cutover period?

· Are adequate funds available for the project?

· Are qualified staff dedicated to the project?

· How much time will be required to complete the data conversion strategy that has been chosen?

Examples of issues and questions for consideration when developing the scope of a data conversion project:

· How far back will data in the general ledger and other systems be converted?

· Will data in funds that have been closed (expired for over five years) be converted into the new system or archived?

· Does the accounting classification coding structure in the legacy system comply with Federal standards and requirements?

· Will necessary, trained staffing resources be available to complete the conversion tasks on a timely basis?

· Will agency personnel or contractors review and clean-up current data in the old system prior to conversion?

· Is there sufficient time to conduct adequate testing of the conversion process to detect and correct errors prior to the conversion?

**CONVERSION TASKS.**

There are three primary phases in a data and system conversion.  Each of the phases has multiple tasks attached to it.  Pre-Conversion is the most extensive involving multiple tasks.  Cutover may be the second phase but it is really the last milestone on a critical path.  Post-Installation may seem like a time to celebrate; however, there are tasks critical to a successful data and system conversion.

1. *Pre-Conversion.*  Activities**prior to and leading up to the conversion, such as determining the scope and approach or method, developing the conversion plan, data clean-up and validation, ensuring data integrity, and conducting necessary analysis and testing.

2. *Cutover.*  Activities to actually convert the legacy data to the new system, such as testing system process and data edits, testing system interfaces, both incoming and outgoing, managing the critical path, supervising workload completion, and reconciliation.

3. *Post-Installation.*  Activities such as verifying data integrity, final disposition of the legacy system data and monitoring of the first reporting cycle.

## Pre-Conversion.

Pre-conversion requires many actions.  However, if properly executed, these tasks significantly reduce the risks associated with the cutover process.  Some of the actions are consecutive; however, many can be performed concurrently.

1. Develop conversion plan, including the milestones;

2. Define functions and data used in the legacy system;

3. Identify interfaces, both input and output;

4. Define functions and data needed in the new system;

5. Determine security rights;

6. Risk

a. Perform risk assessment;

b. Develop risk management plan

7. Determine data conversion requirements;

8. Map data from legacy to new system;

9. Perform data clean-up;

10. Ensure integrity of edits and validations in the new system;

11. Establish and test set-up data and configurations

An example of concurrent actions are numbers one, two, and three above.  Each of those actions can be performed independently of the others.  Action #11, testing, is an essential element of several of the above actions and time should be allowed for it.

*Conversion Plan.*  A comprehensive, detailed conversion plan, including time frames for various tasks in the phase, is essential.  The plan also needs to include adequate time for testing, especially when intensive data mapping and data clean-up are expected.  The task of financial systems data conversion can be a significant part of the financial system implementation in terms of workload, complexity, risk and cost.  As such, the conversion strategy, methodology, resources, timelines, and dependencies should be considered early as part of overall strategic and project planning for the system implementation.  The conversion plan should fully and clearly identify and document the scope of the conversion, specific transactions and data to be converted (budget, single year, multi-year, and no-year appropriations), legacy data to be archived, system inputs and outputs, methodology to be followed, time and resource constraints.  The plan should also identify all dependencies impacting or impacted by the conversion.  Finally, the conversion plan should include a clear communication strategy, particularly for concurrent and shared tasks, and performance metrics to ensure tasks are accomplished in accordance with plan.

*Legacy System Function and Data.*  The functions and data of the current, legacy system need to be defined or described:

· what data is used in the system;

· how is it used within the system;

· what does the system produce (reports, etc.);

· who uses the information produced by the system;

· are the outputs of the system used or essential?

*Interface Identification.*  Another part of defining the current system is identifying all interfaces both input and output interfaces.

· What systems does the legacy system receive data from and what data is it?

· Does the legacy system feed data to another system, if so, what does it provide?

*New System Functions and Data.*  Financial information is used in conjunction with programmatic data for analysis and decision-making.  Management’s need for financial information should be considered along with accounting requirements when considering data conversion scope and timing.

*Security Rights.*  Management is not only responsible for identifying features that are required or desirable in the target system.  Management also determines security rights and access as part of this process.  Security rights includes documentation of:

· who will have access to add or change data within the system;

· who can develop reports and management information from data in the system without adding or changing data within the system; and

· who will have read-only access.

The project office will need to be working with users to determine system control definitions.  System control definitions define the procedures that govern daily work flow and business processes.  They also determine how new features will dictate how the systems are executed and how business processes function.

*Risk.*  The data conversion scope must be determined within the context of risk assessment.  Risk assessment is the systematic approach to identifying and analyzing risk.  It is asking the question:  What can go wrong?  Risk management is controlling areas or events with a potential for causing unwanted change.  Potential risks are rated as:

· Low – requires some attention as a good business practice.  The risk can cause delays or additional work that could be contained with existing contingency plans or resources.

· Moderate – requires attention in the near future.  The risk can cause slight delay or additional work for a given deliverable or task but will not impact the overall project/program budget or end date.

· High – requires immediate attention.  The risk can cause significant disruption to the project/program.

With a risk plan, risks to the conversion are assessed and systematically managed to reduce them to an acceptable level.  Risk is a measure of the inability to achieve overall conversion objectives within defined cost, schedule, and technical constraints and has two components:

· The probability of failing to achieve a particular outcome and

· The consequences of failing to achieve that outcome.

Constraints on time or funding, can increase or decrease the risk of an incomplete or poorly functioning new system.  Risk factors for consideration:

· Will any attributes and criteria be compromised with the approach being taken?

· Will the approach taken degrade performance?

· Will the preferred approach allow the system conversion to be completed within the allowable time frame?

· Will failure to accurately convert cause any risks?

· Will the approach impact the critical delivery of products and services produced from this system or another system?

· Will failure of the system to convert on schedule jeopardize another system or adversely impact a project’s critical path?

· Does the recommended or selected approach increase or decrease the expected amount of testing?

· Are the automated tools that are being utilized favor one approach over another?

· If there is a contractor involved, does the contractor have the ability to perform the conversion?

When developing the risk management plan, there should be coordination with the Office of the Inspector General and other offices that would or may be affected by the conversion.  The OIG can assist with compliance issues that may arise when changing business processes or making the cutover to the new system.  Risk assessment and management provides measures to effectively identify risk, detect problems early, and take corrective action to eliminate the risk or alleviate the impacts of the risk.

*Data Conversion Requirements.*  Once the scope of the conversion is determined, the choices made may result in great variations in the complexity, timelines, cost, risk and likely success.  The requirements to be met by the new system provide the basis for determining the specific data to be converted.  The legacy system data should be converted to the new system based on a determin-ation that a valid need for it exists.  Examples of actions taken in the conversion process include:

· How data will be translated and cross-walked between the two systems where different accounting classification coding structures may exist.

· Differences in functionality, work flow processes, and new accounting requirements.

There should be clear documentation of how data in the legacy system will be translated.  A crosswalk between the data elements in the old and new systems should be defined, mapped, and tested.

Consideration should also be given to other systems, both financial and programmatic, that interface and use elements of the accounting classification coding structure; particularly with an implementation that is phased by accounting function.  The conversion plan should include the approach and schedule for updating all systems that utilize the accounting classification coding structure.

*Data Mapping.*  Data mapping is the identification of legacy data elements that will be continued and converted and the identification of the data elements required in the new system.  Data mapping is done in order to ensure that each legacy data element is identified and earmarked to be continued as a new data element or discontinued.  Converted document and account balances including those coming from manual systems must be traceable to audited sources from the legacy system in order to support opening balances and related supporting transactions under the new automated or manual system.  Once the mapping is complete, there needs to be a method of testing the process to assure completeness and correctness.

Data relationships in the legacy system and the new system must be documented and understood.  To accomplish this a data dictionary should be established crosswalking the legacy data elements to the new system data elements.  For example, the element PURCHASE_ORDER_NUMBER may be defined as “[t]he number assigned by the Office of Procurement to uniquely identify a contractual obligation.  The value contained in this field applies to all contractual documents and not just ‘purchase orders’.  The data dictionary also contains a description of each of the data elements, including the file length of the element and whether it is alpha, numeric, or both.  As part of data dictionary development, parent/child relationships need to be determined; the parent/child relationships are particularly important when loading data into the new system.  Besides the elements previously mentioned, a data dictionary should contain the following:

· Data Element Definitions, such as those previously mentioned.

· Table Definitions (if the system is table driven).

· Database Schema.

· Entity-Relationship Model of Data.

The data mapping effort will include the identification of systems tables, fields, field length, attributes, whether or not they are required, default value if required, and source.  The actual translation may take place manually, through the use of automated tools, or through the use of software developed specifically for the conversion.  In any case, the data elements existing in the legacy system must be translated and matched to the new system including text fields.  Adequate testing will need to be planned.  Overlooking this step may result in significant delays and increased risk.

*Data Clean-Up.*  The objective of data clean-up is to ensure that the data conforms to business rules and processes and that it is consistent and complete.  The validation and adjustment of open transactions and data in the legacy system is an essential prerequisite to the conversion process.  The legacy system may contain erroneous and duplicative data, inactive transactions that should have been closed, open transactions with error conditions, suspended transactions, and other undesirable conditions.  Errors existing in the legacy system should not be perpetuated in the new one.  Generally it is much easier to perform data clean-up prior to deployment of the new system than after.  Data validation rules must be identified and implemented.  If the format for date is YYYYMMDD then that rule must be established, checked, and tested.  Any other format for date would not pass edit checks.  Since the data clean up task may be labor intensive, a separate plan, and possibly a task force, for data clean up may be warranted.  There are automated tools available to assist with this task.  Documentation of the process can provide quality assurance.  Significant lead-time may also be required.  Particular attention should be paid to potential problem areas, such as:  inventories, physical assets, contracts, accounts receivable, or accounts payable.  A test database should be developed to ensure that the data meets all rules and requirements and findings must be documented.

*Ensuring Integrity of Edits and Validation.*  Maintaining data integrity in the new system is critical.  As transactions are entered, they should be subjected to full data edit and validation.  All transactions, whether entered manually or through an automated process, should be subjected to the same edit and validation procedures applied to any transaction.  Bypassing the systems data edit and validation steps during the conversion process may result in difficult data integrity deficiencies down the road and increase the risk of future problems.  However, depending on the system, some edits/setups may need to be “turned off” or not implemented in order to perform data conversion and loading in a reasonable amount of time.  Careful consideration should be given to any conversion methodology that requires bypassing system processes that are designed to perform data edit and validation.  Only data that has been thoroughly cleaned and has been tested to ensure that it meets all business rules and requirements should be allowed to pass when edits/setups are turned off during transfer.

*Establish and Test Set-Up Data and Configuration.*  Configuration and set up data and user-defined parameters reflect the agency’s business rules and govern how transactions will be processed where variations are allowed to be uniquely determined.  A successful conversion is dependent upon complete configuration of set up data, business rules and other user defined parameters in the new system.  A key objective should be to ensure that set-up data is correctly established and tested prior to conversion.  Incomplete set up data will likely result in rejected transactions and confusion during the conversion process.  Adequate testing should also be factored into the conversion plan to ensure that required data edit and validation tables and values are complete and accurate and that transactions to be compared against them conform to edit and validation rules and codes.

## Cutover Tasks.

This is the period for implementation of the new system.  All of the pre-conversion efforts have been completed.

· analyses and mapping of the data are complete and have been tested;

· the data has been cleaned-up and meets all the edits of the new system; and

· everything has been tested.

At this point a cutover plan has to be developed and tasks scripted, tested and rehearsed.  The cutover plan will define the criteria for success of the cutover.  Also, there needs to be a back-up plan in case the new system fails to operate as expected or there is a failure during entry of the data.  By this time, there should be a test database that has been used to test the data mapping process and test data  to ensure that it meets all rules and requirements.  Findings from these tests need to be documented and resolved as a quality assurance procedure.

At this point the actual cutover tasks need to be scripted, tested and rehearsed.  Scripting is:

· delineating each step in the cutover process;

· what is to be performed at that step; and

· performance expectations.

Also there should be a review of the data dictionary to ensure that the parent/child relationships are adhered to in developing the cutover process.  Again, the script should be checked to ensure that all the automated inputs and interfaces are included.  Script should include expected results of tests.  Finally there should be a mock conversion of the entire process with all players involved.  The mock conversion should include the possibility of a failure in the data transfer and the need to fall back to the alternative plan, which may be a return to the legacy system while the conversion process is reviewed to determine the cause of failure.

Once the script has been developed, data relationships checked, and a mock conversion run, the actual cutover is ready to begin.  Following is a list of the steps in the cutover process.

· Processing in the legacy system is stopped

· Automated inputs and interfaces are re-routed to the new system.

· Legacy data is run through a conversion interface and imported into the new system following a pre-determined sequence of entry.

· Based on degree of success of initial operation, a go/no-go decision will be made.

· Assuming success of the conversion, there should be a reconciliation of data in the new system with data from the legacy system.

· Reports should be printed from the new system and compared and reconciled with legacy reports.

· Document adjustments made to converted data as a result of reconciliation to provide a clear audit trail.

***Post Installation Tasks***

These tasks may seem minimal, but they are as important as any of the conversion tasks.  At this point the user is faced with a new system that may have new data input and edit requirements.  There may also be changes in the business rules and processing methods.  Users may need some “hand-holding” until they become familiar with all of the changes in data input, edit routines, and required adjustments.  The program office will also be involved in:

· Archiving master and transaction files;

· Archiving or warehousing closed account data;

· Confirming that converted data is functioning as designed;

· Performing post conversion data clean-up;

· Assessing abnormalities that may appear;

· Reviewing how manual entries were handled;

· Verifying that edits function as designed.

***System Conversion Timing***

## Conversion Options.

Key considerations for the data conversion timetable are:

· What will the live cutover date be?

· When will new transactions be entered into the new system and which ones?

· How much data clean-up will be required?

· What is the timetable for converting legacy transactions and balances?

The “go live” or cutover date is frequently, but not always, the beginning of the fiscal year.  From that point forward, all new transactions will presumably be recorded in the new system and pre-existing transactions and balances from the legacy system(s) are established as planned.  Although accounting standards govern the timing of when financial transactions constructively occur, there is some flexibility as to when both new and prior year transactions and balances must be actually recorded in the new system.  An analysis of when data is effectively needed for accounting compliance facilitates development of a timetable for an incremental conversion that meets compliance criteria, while being cost effective.  However, OMB reporting deadlines for closing the year and auditing financial statements quickly close that window.  Keeping the legacy system working also invokes complexities for budgeting (e.g. revolving/no-year funds), consolidated financial reporting (e.g. FACTS I), training, change management, and reconciliations (e.g. Treasury cash), dictating that the legacy system should be closed out as soon as possible.

### Beginning-of-the-Year Conversion.

A key consideration in determining the cutover date for the new system is whether it will occur at the beginning or during the fiscal year.  The assumption for a beginning-of-the-year conversion is that at the start of the fiscal year, new-year transactions will be entered into the new system.  From that point forward, only adjustments to open prior year transactions would be updated to the legacy system, until converted.  Conducting the conversion at the beginning of a fiscal year facilitates tracking of like transactions and allows time for the prior year legacy transactions to be validated and/or closed.  On the contrary, conducting the conversion at the same time as year-end closing must compete for resources that are also directed to year end closing.

### Mid-Year Conversion. 

A mid-year conversion may be more difficult to manage in that it requires careful consideration of the timing of when open transactions and balances will be converted to the new system, given that new activity may be taking place concurrently.  This places a greater burden on managing cut-off dates, timelines, internal controls and reconciliations.  Risk is also greater in a mid-year conversion.  A mid-year conversion will also involve more transactions (e.g. transactions for the year-to-date) that are not a consideration in a conversion performed at the beginning of the year where the prior years have been closed and the legacy system retired.  On the contrary, it can also be scheduled at a time of less activity, allowing staff to devote more time and energy to the conversion.

## Incremental Approach to Data Conversion.

An incremental approach may result in greater control over data and more cost-effective use of resources.  Financial transactions are uniquely identifiable, allowing for extensive classification of like transactions and data.  This allows for sorting and segmenting transactions as needed and enables priorities to be assigned for converting specific transactions and data, based on when those specific transactions are required. 

***System Conversion Options***

*Direct or Flash Conversion*.  In this, there is start-up of the new system and an immediate discontinuance of the old system.  Open data is converted and transferred from the old system to the new.  This would require that all the data in the legacy system has been cleaned-up and validated prior to transfer to the new.  Testing of the data being transferred for validity and of the edit processes is critical.  If the pre-conversion actions are done well, there is a low risk of data conversion failure.

*Parallel Operation*.  Under this option, both the old and new systems run simultaneously for a period of time.  This method is expensive and only desirable in limited, special cases; when there is a need to retain detailed legacy data to support specific legal requirements or critical transactions that can only be captured in the legacy system.  Also this may be an appropriate option when business processes have changed and produce different data or when quality of data in the legacy system is suspect.

*Pilot Conversion*.  One or more locations are converted to the new system prior to extending the system to the entire agency.  The pilot program might be used when conversion of the data is complex.  When data clean-up is difficult, this method is used to verify that the data conversion approach used functioned as planned.  This involves less risk than a total direct conversion of the entire agency.  This may be preferred when the new system involves new processes and changes in method of data input and validation.  This process may be used to develop a knowledgebase that can be used throughout the organization.  Pilot conversion may be useful in documenting configuration using COTS to achieve a standard system in an agency.

## Data Conversion Options.

# The following should be considered when determining the scope and timelines of the data conversion.  A single conversion option need not be selected for all data; different categories of data could be converted using different options, depending upon such factors as volume, amount of detail required and frequency of reference.

· **Opting Not to Conduct a Data Conversion.**  In cases where the legacy system data is considered too inaccurate or unsupported, the best option may be not to convert specific data.  Under this scenario, all new transactions at the beginning of a fiscal year would be entered into the new system and prior year transactions would remain in the legacy system where initially recorded, until closed.  The key advantages to this option are cost avoidance for a difficult data clean-up.  This method ensures that only valid transactions that can pass all the edits are entered into the new system.  Under this method, the legacy and the new system operate in parallel until the legacy data can be re-entered from source documents or transactions in the legacy system can be closed.

· **Processing New Transactions and Activity Only**.  It is assumed that all new transactions against the current fiscal year’s appropriations will be processed in the new system as in a phase-in conversion.  After the new system goes live, the legacy system will contain all transactions relating to prior periods until the time it is decided that they will be converted.  It should be noted that, following the fiscal year end close, numerous open transactions are closed over time, and the pool of legacy data to be converted becomes gradually smaller.  Financial systems staff conducting the conversion should analyze the estimated volume of open transactions expected and determine the most advantageous time to convert.   Simultaneously, the planned production schedule of the new system should be analyzed to identify deadlines and hence windows, within which the data must be converted.  For example, new year transactions may be delayed while operational staff are conducting year-end close.  It may or may not be desirable to delay or suspend entering new transactions during the conversion period.  Considering all of these items on balance will help determine the best conversion schedule.  This may allow some flexibility in balancing workload between current operations and conversion tasks.  This also involves operating two systems in parallel.  Those providing data input will have to know two systems and business processes and be able to recognize which data goes into which system.  There is a risk that data will be input into the wrong system and increases time spent on reconciling accounts.

##### · Establishing Transaction Balances in the New System for Reporting Purposes.  Account balances may need to be established in the new system to produce timely and accurate reports in the new year and also for funds control.  If the new financial system will produce financial statements, then prior year data will be required for producing prior year reports as well as current year balances that require prior year or opening balances in the computation.  An analysis of when transaction balances are needed to maintain financial compliance during the transition must be conducted.  This may require that an interface or manual process be developed.  The key advantage is that greater financial compliance is achieved in the new system and the scope of reporting capabilities is broadened while avoiding the workload of converting large volumes of legacy detailed transactions.

· **Converting Open Transactions from the Legacy System.**This assumes that a full or partial conversion of open detail transactions in the legacy system will take place as in a direct conversion.  The advantages of a full conversion may be in cost avoidance of maintaining the legacy system and in achieving full financial compliance in the new system at the earliest possible date. This requires that resources are available and a successful data clean up has been completed.  A variation of this option is to consider migrating transactions to the new system only as new activity against prior year transactions occurs, similar to a phase-in conversion.  Under this scenario, transactions would be closed in the legacy system on a transaction-by-transaction basis and re-established in the new system simultaneously as new activity against the specific accounting event occurs.  This approach may be precluded by large volumes and may cause consolidated reporting and reconciliation issues.

· **Closed Prior Year Transactions with New Activity.**It is assumed that it is unnecessary to convert closed detail data in the legacy system.  The closed, detail data is archived.****There are occasions however, when subsequent activity associated with a closed transaction occurs.  For this scenario, consideration should be given to whether the new data will be established in the new system as a new transaction against a prior year or processed in the legacy system.  Some “closed” transactions” (e.g. disbursements) cannot easily be moved to the new system; therefore, the latter option is mandatory.  Data mapping becomes important in situations such as this; enabling the development of interfaces that can move data from the archive into the new system and process it.

**Definitions**

Account Coding Structure – Sometimes called the line of accounting used to identify the type of transaction.

Attributes – Field or column that belongs to an entity.  Some attributes are dependent upon the value of other attributes on the same record.

Conversion – Modification of existing data to enable it to operate with similar functional capability in a different environment.

Entity – Group of related attributes that roughly correspond to a table

**Contributors**

***Joint Financial Management Improvement Program (JFMIP) Steering Committee***

Joseph L. Kull, Chair, Office of Management and Budget

Karen Cleary Alderman, Executive Director, JFMIP

Jeffrey C. Steinhoff, General Accounting Office

Robert Reid, Department of the Treasury

Kathleen Turco General Services Administration

Kathleen M. McGettigan, Office of Personnel Management

###### Joint Financial Management Improvement Program

# Stephen A. Balsam, Systems Accountant

Bruce Turner, Systems Accountant

Elvon C. Lloyd, Project Manager

###### Office of Personnel Management

# Maurice O. Duckett

###### General Accounting Office

# John C. Martin

###### Office of Management and Budget

# Jean Holcombe

###### Department of the Interior

# Chet Mills

***Additional Contributors***

Jerry L. Moran, NAID, Inc.

Jack T. Vile, NAID, Inc.

Suzanne Hack, ALLTEL Corporation

Simcha Kuritzky, American Management Systems

� Since the Framework document was last issued in 1995, both technology and implementation practices have evolved.  Because the Framework document is comprehensive, this white paper, as well as others to come, is designed to update and expand upon selected topics that are of critical interest to agencies and oversight communities.  The goal is to provide current information through posting the White Papers series on the JFMIP Knowledebase at www.jfmip.gov and to provide a method to vet topics that will be incorporated into a later update of the Framework document.

� Data edit and validation refers to the internal system processes used to validate data such as matching with values in user defined tables and other internal processes.

� Reference tables that are populated with unique agency specific values that are used for edit and validation. Examples are: appropriations, organizational structure, programs and activities, object classes, identification of business partners, etc., and supporting accounting classification/coding structure

� The official date at which time the new system becomes operational and the new system of record.

� E.g., financial transactions such as undelivered orders, unfilled orders, accounts payable and receivable, etc. are uniquely identifiable by transaction type, fiscal year, budget year, fund, appropriation, program, oprganization, objectclass, etc.

� For instance, appropriations, apportionments, allotments, undelivered orders, unfilled orders, payables, receivables, etc.

**96  Acquisition/Financial Systems Interface Requirements**

**Federal Financial Systems Framework2**

# _1056889965.unknown