Commerce Administrative Management System (CAMS) Program Management Plan (PMP)

• Improve financial management across NIST, allowing NIST to fully meet new and evolving legislative and performance requirements, while maintaining history of sound financial management practices and unqualified audit opinions.


• Provide single entry, source capture of financial data at the point of origin


• Verify funds availability as part of the creation and approval of a document


• Utilize online edits and embedded intelligence to improve data integrity and reduce the need for corrections and adjustments


• Provide online data entry and access to up-to-date financial information based on user security profiles


• Automate integration of system components to eliminate existing manual reconciliations


• Collect accurate, timely, complete, reliable, and consistent information


• Provide for adequate agency management reporting


• Support government-wide and Commerce level policy decisions regarding financial systems


• Provide input into budget formulation processes and support execution of agency budgets


• Facilitate the preparation of financial statements and other financial reports in accordance with Federal accounting and reporting standards


• Provide information for budgeting, analysis, and Government-wide reporting, including consolidated financial statements


• Provide a complete audit trail to facilitate audits


• Utilize modern technology on individual Bureau platforms


• Coordinate software changes with all DOC Bureaus

Figure 4.1 graphically depicts the Financial Management System at NIST, as it will exist following the Core CAMS Implementation currently scheduled for October 2003. The following sub-sections summarize the components of the CAMS at a process level. Due to many non-CFS systems currently being deployed or enhanced at NIST, this “To-be” picture may change over time. The CAMS Implementation Team will continue to develop and revise the “To-be” picture, mapping current NIST financial management system functionality to the CAMS. The CAMS “To-be” picture may change as more system details and requirements are gathered over the next several months; this document will be updated quarterly to reflect those changes.

A single financial event will require processing by more than one module within CFS. An example of a financial event affecting multiple functions is a payment including additional charges not previously recorded, such as interest costs due to late payment or additional shipping charges allowed by the contract. In this example, the transaction will originate in the Payment Management function, be edited for funds availability, update balances in the Funds Management function for the excess costs, move the undelivered order amount to an expenditure status, update cost amounts controlled by the Cost Management function, update the GL balances in the GL Management function, be edited against reference data, and update audit trails in the CFS.

The following sub-section provides more detailed information on the functionality included in the CFS modules and NIST specific information as known.

NIST currently allocates funds by coding cost centers in the Title File. The final decisions on implementing the ACCS is expected to occur in May. Particular attention will be made to utilizing the project and task fields of the ACCS, which will most likely replace the cost center. The CAMS Implementation Team will work closely with the various users within NIST, ensuring that cost centers are properly crosswalked to the ACCS and implemented. The ACCS is a Department-wide approved structure that will be used by NIST as CAMS is implemented. A generic description of the CAMS ACCS is illustrated below:

CAMS utilizes a standard ACCS structure composed of 9 individual elements: Bureau Code, Fiscal Year, Fund, Organization, Program, Project, Task, Object Class, and User-Defined Field. The following information provides a description for each of the individual elements:

Bureau Code
The Bureau Code identifies the Bureau codes used by NFC. DOC has many Bureaus and the codes assigned to the Phase III Bureaus are: NIST - 57, NTIA - 61, and TA - 33.

Fund Code Fiscal Year (FY)
The Fund Code Fiscal Year is recorded as part of each transaction within CFS. Although a two-digit fiscal year code is displayed on the CFS screens, all date fields are stored in a four-position structure (FY always representing YYYY). This field relates to the appropriation being referenced.

Fund Code
The Fund Code identifies the type of funding to be used (e.g., STRS=01; ITS=02; CRF=03; G&B expenditures=85; G&B receipts=86; WCF=98). Within an appropriation, there may be multiple fund code identifiers.

Organization Code
The Organization Code is a 16-digit value, consists of up to seven levels, and represents codes used by NFC. It uniquely identifies an organization within a specific bureau. Within CAMS’ ACCS, the Organization Code will be used to capture the organization of the person executing the transaction (i.e., the “participating” organization). The organization “sponsoring” the project will already be captured during the project set-up process.

Program Code
The Program Code includes the activity, sub-activity, line item, and Bureau-unique information. It refers to the agency’s programs based on their budget submissions. Programs may have multiple projects, fiscal years, and fund codes. It has been decided that Program Code will represent the NIST budget line items. The last three digits of the Program Code will be populated to represent OU-specific programs.

Project Code
The Project Code is a seven-digit value that accumulates cost in the CFS application. Project Codes are unique within a Bureau and relate to only one fund and program combination. The decision has been made to populate project code with the NIST seven-digit cost center structure.

Task Code
The Task Code separates the project code into task related activities and can be used for added intelligence at the OU’s discretion.

Object Class Code
The Object Class Code identifies the type of expense, and determines the General Ledger account where the specified activity will be recorded. NIST, TA, and NTIA will use a four-digit object class code.

User-Defined Field Code
The User-Defined Field Code was provided to meet Bureau-specific needs. The User- Defined Field will be populated with zeros in CFS but it is available for use at a Bureau’s discretion to provide additional detail to the ACCS.

Certain ACCS elements will be populated based on defaults or values entered in previous fields. For example, fund and program codes will be determined based on the project-task entered by a user. Default values may be established for the Bureau, fiscal year, and organization.

Within CFS, data from other CFS and CAMS modules are recorded to the GL. As part of the audit trail, the system will also identify the individual who inputs a specific transaction. The GL maintains detail transactions comprising Standard General Ledger (SGL) account balances. The number of subsidiary ledgers maintained outside of the CFS will be reduced, which in turn will reduce the amount of time spent on manual reconciliation.

Financial reports to OMB and Treasury are generated from the GL allowing authorized users to establish accounting periods and transaction codes, process multiple closings for both the current period and year-end, and to record transactions concurrently for both the new and prior fiscal year. Special capabilities of the GL module include: drill-downs to view originating documents online, query by data element, and online real-time funds verification. The automated GL will significantly reduce the number of JVs currently being processed by the NIST Financial Management System.

In summary, the CAMS consolidates GL balances into financial statement formats and facilitates user efficiency providing more time to focus on data analysis and financial planning.

The CFS AP module enables authorized users to record, monitor, and control all activities related to the expenditure and disbursement of funds. Online maintenance, transaction, and lookup screens allow users to process payments of goods and/or services while tracking the progress of each document through the disbursement process. This application also performs all financial, cost accounting, and reporting functions associated with these processes.

The system allows authorized users to: establish and maintain vendor information, record receipts and inspections, record vendor invoices and applicable Treasury accomplishment information, issue advances, process expense documents, set-up recurring accruals, and all other related AP processes. When creating no-match accruals, users can verify funds availability.

4.1.5   Accounts Receivable (AR)
A number of enhancements have been made to the AR module that the current production AR module lacks. There are plans to rewrite and migrate these enhancements into the production environment for NIST Customer Bureaus. These enhancements include, but are not limited to, a Graphic User Interface (GUI) based environment providing users with a windows-type environment, online maintenance, transaction, and lookup screens allow users to generate invoices from a schedule, generate IPAC billing files, an adjustment tab enhancement requiring less data entry by the users, and a dunning notices enhancement providing the technological capability for a daily dispatch of dunning notices.

The AR module within CFS is designed to accept records, which may be interfaced from an outside system or “feeder system”. Approved transactions within AR automatically update the GL. In cases where a vendor is also a NIST customer, CFS provides the capability to offset outstanding delinquent receivables against pending payments to the vendor.

NIST currently has a number of systems that produce customer invoices or provide data for invoicing customers. Because of the programmatic nature of these feeder systems, they will not be replaced by CFS. The invoicing records will be passed from these systems through an interface and recorded in the AR module. Fields are provided in CFS to reference the customer number and invoice number from the originating system.

4.1.5.1   Receipts Management (RM)
CFS allows automation of most of the processes needed to immediately prepare and record invoices and adjustments for NIST’s accounts receivables (AR). This function allows authorized users to maintain customer master records, process customer invoices, credit memos, adjustments, customer payments, and cash receipts.

4.1.5.2   Reimbursable Agreements
The CFS functionality applicable to Reimbursables is included in the FM (Budget Execution), CM (Cost Allocation), and AR modules. The reimbursable process includes establishing a reimbursable project, recording the reimbursable agreement and unfilled customer order which determines the budget authority for a reimbursable customer, and accumulating costs against the reimbursable project. Reimbursable billings are processed through the AR module. CFS allows for one or more reimbursable agreements to be associated with a project and one or more projects related to an agreement, however, there may only be one customer/sponsor per agreement. Temporary work authority may be established so that commitments can be approved for a project before a formal agreement has been received.

Once the required maintenance screens have been established, invoices for advance customers can be created, or CFS will automatically generate advance invoices from a billing schedule. CFS performs processes to accumulate unbilled costs against reimbursable projects to generate customer invoices or offset advance amounts previously collected.

4.1.6   Cost Management (CM)
The Cost Management process is a systematic way of distributing cost across projects/tasks. Work performed by a Bureau is different for certain projects and cannot be divided into per unit cost. In order to allocate this cost, a basis for distribution must be created. The Bureau dictates the percentages to be used in the cost allocation process to properly reflect the project/task share of expenses. The CM module is also used to apply surcharge rates for overhead, leave, depreciation, etc. to one or more expense ACCS codes, and reallocate any income or expense posted to the GL. The Cost Management module incorporates two processes: (1) the allocation of reimbursable costs to external customers with a customer defined as another DOC bureau cross-serviced by NIST or any other DOC bureau, Federal agency, or public or private sector customers and (2) the allocation of overhead costs within a bureau, either within the same fund or between two different funds.

4.1.6.1   Cost Allocation
Cost Allocation provides two related but distinct functions: reimbursable program management and income/expense allocation. Within this module, reimbursable activities include establishing a reimbursable project, recording reimbursable agreements, recording customer budget authority as unfilled customer orders, collecting actual costs, and allocating collected costs to customers. CFS allows users to (1) manually allocate costs as specific dollar amounts, (2) automatically create a pro-rata formula based upon application of a known rate to a base or series of bases, or (3) allocate costs based upon a known pro-rata percentage basis.

The functionality pertaining to income/expense allocation enables authorized users to redistribute any income or expense posted to the general ledger from one or more ACCS codes to other ACCS codes. Cost Allocation allows for:

• The accumulation of allocations where the results from the first rate charge are included in the base for the second rate charge.


• An estimated overhead to be collected with over and under adjustments made to net to the actual overhead.


• The base to be defined by SGL account, sub-account, or any combination of ACCS values either singularly or in ranges.


• The unlimited designation of overhead pools and cumulative levels.

CPCS is integrated to CFS for payment of purchase card invoices. The CPCS has the capability to distribute a transaction across multiple ACCS codes and to accommodate adjustments to the ACCS after transactions have been disbursed. CPCS provides user-defined automated approval routing and alternate approval routing for purchase card transactions, special approvals for personal property and training, and electronic notifications of approvals in waiting. Functionality also includes the capability for cardholders to electronically match and certify purchases and an automated process for resolution of improperly billed items.

4.2.4.2   Commerce Standard Acquisition and Reporting System (CSTARS)
Main Function the Interface Supports
The Commerce Standard Acquisition Reporting System (CSTARS) is the DOC-wide procurement system initiative implemented and in production at NIST. CSTARS is a commercial off-the-shelf (COTS) package designed to support e-Government programs. It provides a procurement system that allows users to generate a requisition, route it for approval, turn it into an award document, and track its status. The system provides full range of functionality needed by the contract staff to: process simplified acquisitions, solicitations and contracts, manage workloads, and administer contacts. CSTARS sends the Cost Accounting System an obligation file that is rolled-up to the Fiscal Year, Award Number, Cost Center, and Object Class level. In addition, a commitment file is sent to the Corporate Information System (CIS) once every pay period.

Overview of How Interface Will Be Integrated With CFS
An Obligation Standard Interface (OSI) will be developed for feeding the obligation data of Travel Manager, GMIS and CSTARS into the CFS FM040 Purchase Order Transaction Screen. The CSTARS portion of this interface will be developed to automatically transmit obligation information from NIST’s procurement system into CFS. Following a daily manual call to a batch data extraction process, the OSI will load obligation data from the CACI Out-Queue into preliminary OSI staging tables for processing through a comprehensive set of CFS edits. Records that successfully pass are prepared for posting to CFS and placed in the NIST In-Queue and the final OSI staging table. Records that fail are returned to CSTARS for correction and subsequent reprocessing.

4.2.4.3   Commerce Standard Acquisition Reporting System (CSTARS) Boulder/Mountain Administrative Support System Interface
Main Function the Interface Supports
The procurement activities of NIST Boulder are cross-serviced by NOAA’s Mountain Administrative Support Center (MASC). The Commerce Standard Acquisition Reporting System (CSTARS) is the DOC-wide procurement system initiative implemented and in production at NIST. CSTARS is a commercial off-the-shelf (COTS) package designed to support e-Government programs. It provides a procurement system allowing users to generate a requisition, route it for approval, and track its status. The system provides a full range of functionality needed by the contract staff to: process simplified acquisitions, solicitations and contracts, manage workloads, and administer contacts. Currently, NIST sends requisition information to MASC for the generation of an award document. MASC then returns the CSTARS-generated award documents to NIST Boulder where all necessary information is manually input into the NIST Boulder Access Database. An obligation file is generated once a week out of this NIST Boulder Access Database and transmitted via file transfer protocol (FTP) to NIST Gaithersburg for uploading into the Cost Accounting system. Additionally, once every pay period, a commitment file containing a cumulative record of all remaining commitments is sent to the Accounting department for uploading into the Corporate Information System (CIS).

Overview of How Interface Will Be Integrated With CFS
An Obligation Standard Interface (OSI) will be developed for feeding the obligation data of Travel Manager, GMIS and CSTARS into the CFS FM040 Purchase Order Transaction Screen. This interface will utilize an EAI tool being developed by the CSC. MASC obligations will be keyed directly into CFS until such time that the EAI tool is modified to include functionality allow records from NOAA to be fed directly into NIST's instance of CFS. The obligation file, containing all necessary obligation data, will be fed into the OSI, while the commitment file will be fed into the CAMS Portal.

4.2.2   NFC Labor Module
Main Function the Interface Supports
Payroll processing at NIST is outsourced to the Department of Agriculture National Finance Center (NFC). NIST currently uses a series of manual and automated processes within its current Financial Management System to send and receive data from the NFC. A single NFC to CFS interface and NFC Labor Module has been developed and implemented at DOC-CAMS Bureaus to communicate labor and cost information between both systems. The Interface and labor module are part of the Core CAMS, maintained by CSC, and planned for the NIST Implementation.

The NIST Labor system receives, edits, and processes labor data from the National Finance Center (NFC) for NIST, NTIA, and TA. The NIST Labor system also processes NIST-12 changes, calculates comp time amounts, and processes overhead and personal benefits charges. The NIST Labor system also produces reports showing gross labor, payroll payables, and productive labor. Cost center switches and year-to-date corrections are also processed through the NIST Labor system that feeds data to the payroll and accounting system.

Overview of How Interface Will Be Integrated With CFS
NIST Time and Attendance (T&A) data will be received by NIST every pay period from the NFC. This data will then be loaded into the NFC Labor system for processing. In order for NIST to operate on an accounting month schedule, pay periods for which data has not been processed or received from the NFC will be estimated by the NFC Labor system using prior pay period/month data. The NFC Labor system is a module of CAMS that feeds labor charges from the NFC directly into CFS. Since labor comprises the majority of the costs that NIST recognizes, labor data must be available at the end of every pay period to allow for forcasting and solvency analysis. Therefore, the feasibility of having web T&A data will also directly feed the CAMS Portal to provide labor information and allow for surcharges to be calculated on a pay period basis within the CAMS Portal is being analyzed. Additionally, the NFC Labor system will allow for payroll charges to post to the correct appropriations. Therefore, NTIA and TA Labor charges will be directly charged rather than flowing through the working capital fund.

4.2.2.1   Human Resources & Payroll System
The centralized Human Resources Management Division (HRMD) within the DA/CFO supports the human resources function at NIST. This office works closely with the staff in the OUs to ensure personnel actions are accomplished in a timely and accurate manner. Functions supported by this Division include:

• Hiring / Recruitment


• Time and Attendance / Payroll / Benefits


• Training


• Performance Review


• Awards


• Security Clearance

The primary interaction between the NIST Financial Management system and the Human Resource System is the Time and Attendance / Payroll / Benefits functionality. CFS will interface with these systems, through the NFC labor module, which is maintained by CSC and in production at various DOC Bureaus.

4.2.2.2   Time and Attendance
Currently, the Time and Attendance system at NIST is a DOS-based, manually intensive system. Every pay period, employees maintain and update a manual time sheet, submitting the document to their group timekeeper at the end of the pay period. Timekeepers, personnel assigned to record staff time, record all entries into the Time and Attendance system, consolidating the records, saving the information on a diskette and sending it to the group supervisor. The Time and Attendance system resides locally on every timekeeper’s workstation. There are approximately 300 timekeepers throughout NIST. AOs for each OU use the data on diskette to consolidate information from each group and send the file to the Management Information Computer Facility (MICF). The Time and Attendance file is then sent to NFC through a secure line.

A DOC initiative is underway to convert timekeeping to a Web-based Time and Attendance system. The system is currently being piloted at part of DOC and may be implemented at NIST during FY02. Financial data will be fed back to CFS via the NFC Labor Interface.

4.3   Specific Interface Backgrounds and Overviews

4.3.1   Travel Manager Interface
Main Function the Interface Supports
Travel Manager, developed by GELCO, allows travelers to electronically submit and route travel authorizations, vouchers, reclaims and local vouchers to the NIST Accounting System through an existing travel interface. Currently, only NIST Gaithersburg, NIST Boulder and NTIA Boulder campuses use Travel Manager. The NTIA and TA bureaus, located elsewhere, manually submit travel documents to the NIST Travel Office for processing into an in-house developed dbase program. Travel Manager does not have the functionality to process long-term and relocation documents therefore these transactions are processed through the dbase program. Itinerary and payment information from the dbase program and Travel Manager is warehoused in the S2K Travel Payment Database.

Overview of How Interface Will Feed Financial Data To CFS
The Travel Manager Interface (TMI) will be implemented to transmit travel orders, vouchers, re-claim and local vouchers from Travel Manager to CFS. The TMI design will incorporate modules to handle the different types of transactions currently processed through Travel Manager. An Obligation Standard Interface (OSI) will be developed for Travel Manager, GMIS and CSTARS obligation transactions and will be incorporated as a module of the TMI. The TMI will initially have the following modules to process travel orders and vouchers:

• Travel Order Upload Module to transmit travel orders to the FM040 Obligation screen in CFS.


• Pre-Processing Module that will incorporate matching, exception reporting and re-formatting of orders, vouchers and tickets prior to sending to the Voucher Processing Module.


• Voucher Processing Module that will take the formatted transactions and transmit the data through the Accounts Payable Standard Interface (APSI) to the PM003 Vendor Invoice Transaction screen.

Functionality that is not currently captured within Travel Manager (i.e., relocations, long-term travel) will be analyzed and processed manually outside the interface.

In addition, reclaims and local travel documents will not be obligated. They will be processed through the APSI to the PM003 Vendor Invoice Transaction screen.

4.3.2   Grants Management Information System (GMIS)
Main Function the Interface Supports
The Grants Management Information System (GMIS), planned for full implementation by October 2002, is a software package that manages and processes grants and cooperative agreements. The system is designed to fully automate the Federal Financial Assistance workflow process and to establish a single NIST-wide system for the creation and approval of financial transactions related to grants and cooperative agreements. All operating units at NIST will use GMIS as the means of reviewing, selecting, awarding and administering all NIST-issued grants and cooperative agreements. By the beginning of fiscal year 2003, GMIS functionality will fully replace the Legacy Procurement Database, eliminating the need to re-key grant obligation information. With the implementation of the GMIS/Automated Standard Application for Payment (ASAP) Interface, grant officials will also be able to better track grant disbursement activity as the Federal Reserve Bank of Richmond (FRBR) will provide a daily report of this information back to GMIS.

Overview of How Interface Will Be Integrated With CFS
An Obligation Standard Interface (OSI) will be developed for feeding the obligation data of Travel Manager, GMIS and CSTARS into the CFS FM040 Purchase Order Transaction Screen. The GMIS component of the OSI Interface will enable the real-time transmission of obligated awards from NIST’s grant system into CFS. Subsequently, CFS will transmit all necessary grant information to ASAP, eliminating the need for the Grants Office staff to re-key grant information into ASAP. Following the disbursement of grant monies, the FRBR will send disbursement notification through the ASAP system and the CFS/ASAP interface will automatically post grant disbursement information to the General Ledger. Upon implementation of the OSI, disbursement information captured in CFS will be automatically sent to GMIS. This will allow NIST staff to view the status of a grant’s unliquidated obligation balance and disbursement patterns. In addition, commitment tracking will be enabled as GMIS will be sending commitment data to the CAMS Portal in real-time.

4.3.3   Calibrations Interface
Main Function the Interface Supports
The Calibrations program office provides calibration and measurement services to both commercial and federal customers. Calibrations is the second largest fee-producing program sending billing information to the Accounts Receivable (AR) group. The web-based Information System to Support Calibrations (ISSC) is used to record purchase orders received and customer billing information. Currently, the Calibrations program office maintains 12 different databases, one for each operating unit, with each containing its own customer and order information. Each pay period, an invoice file is generated out of the ISSC and transmitted to the AR Billing system.

Overview of How Interface Will Feed Financial Data To CFS
Although customer invoices will continue to be generated directly from the ISSC, the implementation of the Accounts Receivable (AR) Module of the Core Financial System (CFS) will require that a Calibrations Interface file be created to upload Calibration billing information into the AR Module through an AR Standard Interface (ARSI). The current ISSC system will need to be modified in order to capture the required Accounting Classification Code Structure (ACCS) information and any required fields needed for creating a receivable record in the AR module.

The ISSC system will produce a Standard AR Billing file that will capture these required fields from the ISSC and upload them into the AR module through the ARSI as approved and open receivables. The Calibrations Interface file will also populate the Mixed System Fields, optional fields in the AR module used to reference the customer number and system-generated invoice number derived from the Calibrations feeder system.

4.3.4   Standard Reference Materials (SRM) Interface
Main Function the Interface Supports
The Standard Reference Materials (SRM) program office ensures accurate and compatible measurements through the development, certification, and distribution of Standard Reference Materials for use by commercial and federal customers, alike. The largest fee-producing program at NIST, SRMs make up approximately 90% of the invoices currently submitted to the Accounts Receivable (AR) Group. Each pay period, the SRM program office generates an invoice file that is uploaded into the AR Billing system.

Overview of How Interface Will Feed Financial Data To CFS
Although customer invoices will continue to be generated directly from the SRM system, the implementation of the Accounts Receivable (AR) module of the Core Financial System (CFS) will require the creation of an SRM Interface file to upload SRM billing information into the AR module through an AR Standard Interface (ARSI). The current SRM system will need to be modified in order to capture the required Accounting Classification Code Structure (ACCS) information and any required fields needed for creating a receivable record in the AR module.

The SRM system will produce a Standard AR Billing file that will capture the required fields from the SRM system for upload into the AR module through the ARSI as approved and open receivables. The SRM Interface file will also populate the Mixed System Fields, optional fields in the AR Module used to reference the customer number and system-generated invoice number derived from the SRM feeder system.

Overview of How Interface Will Feed Financial Data To CFS
The implementation of the Accounts Receivable (AR) module of the Core Financial System (CFS) will require that a Lockbox Interface file be developed to upload and record the receipt of payment and deposit ticket information into the required fields of the new AR module. The Lockbox Interface file will populate the required fields in the Receipt Log and Deposit Ticket screens of the AR module, creating active receipts and open deposit tickets.

The interface file will first create an open deposit ticket and auto-populate all the required fields in the Deposit Ticket screen. Upon creation of the deposit ticket, the interface file will load the receipts assigned to the batch into the Receipt Log screen and automatically assign them to the corresponding deposit ticket. An AR Standard Interface (ARSI) will be developed to process all AR related data files. The Lockbox Interface file will be fed into CFS using this interface.

4.3.6  Plant Interface
Main Function the Interface Supports
The Plant division has implemented Maximo, a commercial off-the-shelf system to track all charges, work orders and labor costs. The system allows users to directly enter work orders and labor hours. Maximo currently provides a text file of all Plant charges to Accounting and Reports to be interfaced into the Cost Accounting system

Overview of How Interface Will Feed Financial Data To CFS
Maximo will be modified as needed to provide data for the Summary Level Transfer (SLT) Interface to CFS. Maximo will generate a file in the SLT required format to be loaded into the SLT Interface for processing into CFS. This file will contain all Plant charges for the current period. The Plant division maintains the system through an on-sight Maximo consultant. This consultant will be responsible for the necessary changes to the system to create the output file.

4.3.7   Shops Interface
Main Function the Interface Supports
The Shops system was designed by NIST to track costs on inter-division work orders received from NIST divisions and from outside customers to fabricate, modify or repair scientific instruments. The Shops system captures daily labor charges and other objects pay period charges. The system produces internal job status reports, production reports and pay period reports for NIST customers and their Administrative Officers (AOs). The pay period Time and Attendance (T&A) reports are used as data entry into the NIST T&A System. The Shops system currently provides a text file with all Shops charges for the current pay period to Accounting and Reports to be interfaced into the Cost Accounting system.

Overview of How Interface Will Feed Financial Data To CFS
The Shops system will be modified as needed by K-Forms to provide data for the Summary Level Transfer (SLT) Interface to CFS. The Shops system will generate a file in the SLT required format to be loaded into the SLT Interface for processing into CFS. This file will contain all Shops charges for the current period.

4.3.8   Computer Services Interface
Main Function the Interface Supports
The Computer Services System accumulates usage data from the Scientific Computing Facility (SCF) computers. The Computer Services System currently provides a text file of usage charges for all users holding an account on SCF computers to Accounting and Reports to be interfaced into the Cost Accounting system. The Computer Services System also generates reports as needed by the SCF.

Overview of How Interface Will Feed Financial Data To CFS
Computer Services will be modified as needed to provide data for the Summary Level Transfer (SLT) Interface to CFS. The Computer Services System will generate a file in the SLT required format to be loaded into the SLT Interface for processing into CFS. This file will contain all Computer Services charges for the current period.

4.3.9   Federal Workforce Transportation System (FWTS) Interface
Main Function the Interface Supports
The Federal Workforce Transportation System (FWTS) was designed by NIST to facilitate the distribution of Metrocheks to the employees who qualify for the Federal Workforce Transportation (FWT) program, effective October 1, 2000. Facilities Services Division is responsible for the development, record keeping, distribution, and maintenance of the FWT program. The FWTS will account for the purchase and balance of Metrocheks before and after they are distributed to employees. Under the Federal Workforce program, qualified employees are eligible for Metrocheks with a maximum value of $100 per month to utilize approved mass transportation as their means of commuting to and from work. The FWTS currently provides a text file of all Federal Workforce Transportation charges each month to Accounting and Reports to be interfaced into the Cost Accounting system.

Overview of How Interface Will Feed Financial Data To CFS
FWTS will be modified as needed to provide data for the Summary Level Transfer (SLT) Interface to CFS. The FWTS will generate a file in the SLT required format to be loaded into the SLT Interface for processing into CFS. This file will contain all Federal Workforce Transportation charges for the current period.

4.3.10  Storeroom Inventory System (SIS) Interface
Main Function the Interface Supports
The Storeroom Inventory System (SIS) tracks the status of available inventory of the internal NIST Storerooms items and serves as the official record keeping system for all storeroom supplies. SIS is responsible for recording, tracking, accounting, procurement, issuance, disposal, archiving and reporting on all items that are received. The Storeroom Inventory System currently reports all charges through a receipts file, an issues file, and a surcharge file to Accounting and Reports to be interfaced into the Cost Accounting system. The receipts file records the receipt and adjustment of goods received to replenish the Storeroom inventories. The issues file contains the transactions for re-issuing the Storeroom supplies to NIST internal customers. The surcharge file contains the surcharge on the Storeroom issues.

Storeroom Issues and Adjustments File
The Storeroom system will generate the Storeroom Issues file and an Adjustments file in the Summary Level Transfer (SLT) required format to be loaded into the SLT Interface for processing into CFS. This file will contain all Storeroom Issues Charges for the current period.

Storeroom Surcharges
The Storeroom system will generate the Storeroom Surcharges file in the SLT required format in a similar manner as currently exists. This file will be provided from the Storeroom in the correct SLT format to be loaded into the SLT Interface for processing into CFS. This file will contain all Storeroom surcharges for the current period.

4.3.11   Oracle Assets Interface
Main Function the Interface Supports
Oracle Assets is the system of record for tracking of all NIST property items. Oracle Assets provides amortization charges to NIST’s accounting system in an amortization text file. Other functions of the Property group, such as reclassifications, adjustments or additions to existing property items are tracked through the Oracle Assets system and manually transferred to NISTs accounting system. The Oracle Assets system receives input on property items from CTARS, QPS, and MASC. A surcharge is applied to all amortization charges each pay period.

Overview of How Interface Will Feed Financial Data To CFS
Oracle Assets will provide amortization data for the Summary Level Transfer (SLT) interface. Oracle Assets will generate a file in the SLT required format to be loaded into the SLT Interface for processing into CFS. The Oracle Assets system will not need to be modified since the Accounting Classification Code Structure (ACCS) values are already included in its table structures. The amortization file will contain all property amortization charges for the current period. All other transactions that take place in Oracle Assets that need to be fed into CFS will be performed by manual entry into CFS. The property surcharge will also be calculated by the Property group in the SLT Format and processed through the SLT interface.

4.3.12   Verizon/Washington Interagency Telecommunications System
Main Function the Interface Supports
The Verizon/Washington Interagency Telecommunications System (WITS) Phone Charges business process incorporates the NIST Gaithersburg and Boulder local and long-distance service phone bills. The NIST Gaithersburg local phone service is under a contract with the WITS program of Verizon. The current process is still in the initial stages due to difficulties with billing. The proposed As-Is process for sending the invoice transactions to the current NIST accounting system will involve receiving an electronic bill and uploading the file into the MANKON system to create an extract file for the Cost Accounting system. Verizon sends the cost per phone line and its associated cost center. The long-distance service provider is MCI WorldCom. These charges are billed to an overhead cost center. Only a minority of charges is expensed back to the actual owner of the phone line, however, in the future it may be determined to charge all long-distance charges back to the owner. Boulder long-distance charges will be on a separate bill in the near future. NTIA and TA phone bills are paid through the Online Payment and Collection system.

Overview of How Interface Will Feed Financial Data To CFS
The NIST local phone services invoice will be processed as a mixture of no-match and matched transactions interfacing directly to CFS through the Accounts Payable Standard Interface (APSI). The MANKON system will produce a file that contains the phone charge amount, project, telephone number and type of service. The required accounting elements for CFS is fiscal year, project, task code, organization code and object class. The values can be defaulted when the file is loaded to APSI. The project code is currently captured within the file. The task code could potentially be used to help specify whether the charge is for long-distance or local service, but further analysis of this option is needed. The organization code always corresponds to the Telecommunications Office organization code, which can be defaulted. The object class is always defaulted to the same value for all transactions. Further information such as the phone number and type of service will be transmitted to CFS for reporting purposes.

The NIST long-distance phone bill will be processed through the Summary Level Transfer (SLT) interface.

Overview of How Interface Will Feed Financial Data To CFS
Estimated accruals will be interfaced through the Estimated Accrual module of the Accounts Payable Standard Interface (APSI). Generally, systems will produce a high volume of estimated accruals at year-end. Estimated accruals may be submitted on a excel spreadsheet, uploaded into the APSI staging tables and sent to the APSI administrator for processing through the APSI.

• Vehicle Rental,


• Equipment Rental*,


• Instrument Shops,


• Plant,


• Storeroom,


• Printing Services, and


• NOAA Billing**.

*The Equipment Rental system will be retired in the near future.
**The NOAA Billing information is only provided to NOAA and stripped out of the file sent to NIST.

After the six systems submit their information to the Other Objects system, the information is summarized at an object class level and then sent on to NIST Gaithersburg to be fed into the Cost Accounting system. The charges are fed through the central Other Objects database so that they can be marked as cross services charges or reimbursable charges and combined so that only a single IPAC receivable or payable will need to be set up for all of NIST Boulder Other Objects charges. The cross services charges are those charges for which a payable must be set up to NOAA and the Reimbursable charges are those for which a receivable to NIST will be set up. The cross service charges make up the majority of the charges that are received from the Boulder Other Objects system.

Overview of How Interface Will Feed Financial Data To CFS
The five feeder systems to the Boulder Other Objects system will be modified as needed to provide data necessary for the Accounts Payable Standard Interface (APSI) and Summary Level Transfer (SLT) interface to CFS. The Other Objects system will also need to be modified to handle the new data elements from the feeder systems.

The Boulder Other Objects system will generate a file in the APSI required format to be loaded into the APSI for processing into CFS. This file will contain all Boulder Cross Services charges for the current period.

Reimbursable charges will be provided in a separate file in the SLT interface format.

Note, the five feeder systems that feed the Boulder Other Objects system have already been modified to incorporate the ACCS for the NOAA implementation. This may diminish the work effort necessary include the ACCS values in these systems and the files that they provide. The CAMS Interface team will analyze these systems to determine if additional modifications need to be made for the NIST implementation of CAMS.

Overview of How Interface Will Feed Financial Data To CFS
The Boulder Plant system will be modified as needed to provide data for the Summary Level Transfer (SLT) Interface. The Boulder Plant system will generate a file in the SLT required format to be loaded into the SLT Interface for processing into CFS. This file will contain all Boulder Plant charges for the current period. NOTE: NTIA changes processed through the Boulder Plant Interface will be processed through the APSI.

Overview of How Interface Will Feed Financial Data To CFS
The NIST CAMS Portal will replace the functionality of the Financial Management Extension of CIS. CIS will remain for historical data and the Personnel Extension. The vision for the NIST Portal is to provide CAMS users with a user-friendly, central location to retrieve timely financial management and accounting information. The CAMS Portal will provide functionality similar to CIS, including standard and canned reports, “slice and dice” functionality, ad hoc querying, and data downloads. The CAMS Portal will contain a day-old copy of CAMS/CFS Production data as well as data entered through established interfaces.

Overview of How Interface Will Feed Financial Data To CFS
The NIST CAMS Portal will replace the functionality of the Financial Information System. The vision for the CAMS Portal is to provide CAMS users with a user-friendly, central location to retrieve timely financial management and accounting information. The CAMS Portal will provide the analytical capabilities currently available within FIS through a variety of built-in analysis tools. Users will be able to generate forecasting and solvency reports through the “My Tools” section of the CAMS Portal as well as track commitments interfaced into CFS or entered directly through the CAMS Portal screens.

Overview of How Interface Will Feed Financial Data To CFS

Bankcard Transactions
The Commerce Purchase Card System (CPCS) is used to track, reconcile, and approve all purchases made with a Bankcard. The system also allows officials to search, edit, or create records for Bankcard users and officials. CPCS receives transaction data in the form of text downloads from the Commerce Bankcard Center (CBC) that is uploaded to automatically populate CPCS screens. A daily download from the CBC will populate Cardholders’ log screen that will in turn be used for commitment tracking purposes in the Portal. Cardholders are then able to match their transactions to their daily log and reconcile them to the appropriate ACCS. Reconciled transactions are passed to the necessary official for approval within CPCS. After approval, transactions are posted to CFS to be picked up by the disbursement process. Two days before the monthly payment is due to Citibank, any transactions that have not been reconciled will be ‘swept’ out of CPCS and posted to the Invoice Transaction Screen to ensure that payments are made for the full amount and dispersed on time in accordance with prompt pay laws. Disbursements to Citibank are rolled up to a single payment for each bureau per month. A nightly interface will run to extract all reconciled and approved transactions from CPCS and post them to CFS via the PM003 Vendor Invoice Transaction screen. Transactions that have not been reconciled prior to the due date of payment to Citibank are extracted from CPCS through a process called ‘Sweep’ and posted to CFS in a default account associated with each cardholder. The interface will extract these ‘swept’ transactions from CPCS after they are modified to the correct ACCS and post them to CFS via the PM006 Advice of Corrections Screen.

Overview of How Interface Will Feed Financial Data To CFS
The Travel Order Entry System will not be interfaced with CFS. Rather, the transactions that are currently entered into the dbase program will be incorporated into CFS or replaced by Travel Manager. It has been proposed to implement Travel Manager for NTIA and TA. Reimbursements will be handled through the Accounts Receivable module of CFS. Advances will be entered through Travel Manager and interface through the Travel Manager Interface (TMI) (reference the TMI summary section). Long-term and relocation transactions will be further analyzed for incorporation into CFS or Travel Manager.

4.3.20   Government Travel Account (GTA) Interface
Main Function the Interface Supports
The implementation of the Government Travel Account (GTA) Interface will provide a more integrated, accurate, and reliable means of managing travel ticket expenses for NIST, NTIA, TA and the Phase II customer bureaus. The GTA Interface will automate the existing process of manually re-keying Scheduled Airline Ticketing Office (SATO) travel ticket expenses into the Core Financial System (CFS) for the customer bureaus. Therefore, the NIST Financial Services Group (FSG) will no longer depend on the current time-consuming accounting processes that are more prone to human error. The NIST, NTIA, TA implementation will enhance their current method for processing SATO transactions and will transmit the data into CFS.

Overview of How Interface Will Feed Financial Data To CFS
The GTA Interface will reduce processing time by loading the travel agency data into staging tables of the interface. The interface will also facilitate the process of validating and correcting errors in the SATO file using reports and correction screens. After the data is validated it will be transmitted to the Accounts Payable Standard Interface (APSI) to post transactions into CFS. Release 4.0 will implement the GTA Interface to the Phase II customer bureaus whereas Release 2.0 will add additional functionality required by NIST, NTIA and TA that includes matching the ticket to the travel order.

Once the agreement is confirmed, the OIA office sends the NIST Guest Researcher agreement to the Accounts Payable Office. Accounts Payable enters the obligation into the Guest Researcher Program, a dBase application. The subsistence and travel expenses are obligated for the entire length of the agreement unless there is a continuing resolution, in which the agreement is obligated on a monthly basis. The Guest Researcher dBase program generates an obligation and payment files for the NIST Cost Accounting system.

In early 2003, the OIA office may implement the NIST Associates Information System (NAIS). The system will track Guest Researcher agreements and may have the capability to send accounting data to the Core Financial System (CFS) upon implementation in FY ‘04. However, this system is under development and may not be fully implemented by the CAMS deployment date. At the time of this writing, due to the continuing resolution, the contract support to assist with the implementation of NAIS by January 2003 has been postponed.

Obligations will be manually entered into CFS until changing to the NAIS system can be incorporated to capture the CFS require data elements. Payments will be processed using the Recurring Vendor Invoice functionality within CFS. The Recurring Vendor Invoice functionality will be used to automate the process and reduce the time rather than manual entry of invoices each month.

• Summary Balance Information,


• ACCS codes,


• Document Numbers,


• Quantities and Dollar Amounts, and


• Vendor Names.

The Data Warehouse does not display confidential information such as Social Security Numbers, Employee Information, ABA/TIN numbers or other banking information.

The CAMS Implementation Team is planning to deploy the Data Warehouse to the NIST Customer Bureaus during FY02. The CAMS Implementation Team will conduct a detailed analysis of CIS and FIS to ensure the Data Warehouse functionality meets NIST reporting requirements.

4.3.23   e-Approval System
The e-Approval system is a BizFlow software package by Matcom designed to allow NIST to conduct business more efficiently. Some key features of the system will allow NIST to:

• Electronically route work between campuses and buildings
  Support digitally signed documents


• Automatically reroute work to alternates


• Provide remote access to support routing and signing of documents while on travel or telecommuting


• Act as a conduit between administrative systems


• Enhance security and privacy

The system is currently being piloted and tested in the Office of the Director, TS, DA/CFO, MEL, and Divisions 890 and 896 within ITL and is planned for a NIST-wide implementation during FY02. The initial deployment will implement the ad hoc routing capability, followed by a phased in standardized workflow.

4.4   System Architecture and Infrastructure
The Baseline Technical Architecture Plan describes and depicts the technical architecture components that provide the underlying support for the DCFO’s financial and accounting processes, including the CAMS system in production for NIST Customer Bureaus. Due to security reasons the architecture information is not contained within the PMP. See figure 4.2 for an example of the type of data contained in the Technical Architecture Plan. To request a copy of the CAMS Baseline Technical Architecture Plan, contact the DCFO Office.

Based on extensive research and collaboration with ITL, the CAMS Implementation Team developed a recommendation for the To-be technical architecture, which will support Phase I, II, and III CAMS users. The recommendation centered around a goal of consolidation of individual technical architecture components (e.g., servers). This approach will allow ITL to streamline the network infrastructure that supports financial processing at NIST, thereby reducing overall maintenance costs and simplifying system administration across NIST.

The CAMS Implementation Team is continuing to work with ITL to ensure that key milestones toward consolidation are met. To obtain an update of the current state of the technical architecture, please contact Wende Wiles, the CAMS Configuration Manager.

Figure 4.2 CAMS/OS Production Flow