IFCAP VISN/Integration Software Requirements Specification ...

IFCAP VISN/Integration Software Requirements Specification Draft

SRS Draft

November 1997 SOP# PL 192-7 9/19/97

Revision History Note: The revision history cycle begins once changes or enhancements are requested to an approved SRS. Date Revision Description Author 11/04/97 1.0 Initial Version Washington CIO FO

Table of Contents

• 1. INTRODUCTION • 1.1. PURPOSE • 1.2. SCOPE • 1.3. ACRONYMS AND DEFINITIONS

• 1.3.1. Acronyms • 1.3.2. Definitions

• 1.4. REFERENCES • 1.4.1. SAAN Web site: http://www.saan.org • 1.4.2. VISN/Integration PRD

• 2. OVERALL DESCRIPTION • 2.1. PRODUCT PERSPECTIVE

• 2.1.1. User Interfaces • 2.1.2. Hardware Interfaces • 2.1.3. Software Interfaces • 2.1.4. Communications Interface • 2.1.5. Memory Constraints • 2.1.6. Special Operations • 2.1.7. Implementation Requirements

• 2.2. PRODUCT FUNCTIONS OVERVIEW • 2.2.1. Connect multi- GIP Primaries to a single FCP (PRD 5.2) • 2.2.2. Transfer stock from one Primary to another using Distribution Orders (PRD (5.3) • 2.2.3. Allow more than one supply fund warehouse in a single station. (PRD 5.5) • 2.2.4. Combine requests from one or more FCP in the same station on one order (PRD 5.1 *changed to *local only*) • 2.2.5. Enhanced Printing Capabilities (PRD 5.8)

• 2.3. USER CHARACTERISTICS • 2.4. CONSTRAINTS • 2.5. APPORTIONING OF REQUIREMENTS

• 3. SPECIFIC REQUIREMENTS • 3.1 DATABASE REPOSITORY • 3.2 SYSTEM FEATURES

3.2.1. Ability to connect multi- GIP Primaries to a single FCP (PRD 5.2)

3.2.2.Ability to transfer stock from one Primary to another using Distribution Orders (PRD 5.3)

3.2.3. Ability to have more than one supply fund warehouse in a single station (from issue Books only). (PRD 5.5)

3.2.4. Combining requests from one or more stations in the same station on one order (PRD 5.1) 3.2.5. Enhanced Printing Capabilities (PRD 5.8)

• 3.3. PERFORMANCE REQUIREMENTS • 3.4. DESIGN CONSTRAINTS • 3.5. SECURITY • 3.6. PORTABILITY • 3.7. OTHER REQUIREMENTS

• 4. FUNCTION POINT ESTIMATION • 5. REVISIONS (OPTIONAL) • 6. GLOSSARY

1. Introduction

1.1. Purpose

The VISN/Integration Software Requirements Specification (SRS) provides more detail to the features described in the VISN/Integration Product Requirements Document (PRD). It is intended to serve as an agreement between the VISN/Integration Technical Advisory Group (TAG) and the Washington Chief Information Office Field Office (WCIOFO) on the specific functionality and attributes needed to expand IFCAP acquisition and supply capabilities.

1.2. Scope

The IFCAP VISN Integration Patch will provide expanded automated solutions to the changing acquisition and materiel management structures and processes within the Veterans Healthcare Administration (VHA). It will allow supplies to be transferred, shared, or purchased and consolidation of orders within a single station, billing, and distribution in a flexible enough manner to accommodate as many of the following models as possible:

• Single VISTA Procurement Model - everything is entered and stored on one single-site station. More FCPs are defined to enable tracking of funds/purchases at the individual station level within a service.

• Centralized Procurement Model - all Purchasing Agents are at one location. They dial in to each site to procure requests.

• Distributed Model - Virtual contracting and separate materiel management at sites. • Combination Centralized/Distributed Procurement Model - Single procurement activity for multiple locations

which may or may not have a warehouse attached.

The requested product will allow:

• Capability to combine 2237s from multiple FCPs within a single fund at one station and appropriation onto one Purchase Order

• Multiple Inventory Points to be attached to single FCP • Multiple Inventory Points to be defined as Warehouse type • Multiple Inventory Points to be defined as SPD type • Conversion of Secondary Inventory Points to Primary Inventory Points • Primary to transfer stock (Quantity and Value) to another Primary even if attached to different FCPs. • Secondary to buy from multiple primaries • Greater printing flexibility

1.3. Acronyms and Definitions

1.3.1. Acronyms

AAC Austin Automation Center A&MM Acquisition and Materiel Management AEMS/MERS Engineering Package FCP Fund Control Point FMS Financial Management System GIP Generic Inventory Package

IFCAP Integrated Funds Distribution, Control Point Activity, Accounting and Procurement package

IMF Item Master File PA Purchasing Agent PC Purchase Card PO Purchase Order SAAN VA Supply Automated Advisory Network SPD Supply, Processing, and Distribution inventory point TAG Technical Advisory Group VA Veterans Administration VHA Veterans Health Administration VISTA Veterans Health Information Systems Technology and Architecture

1.3.2. Definitions

A Glossary of IFCAP terms is provided in Section 6.

1.4. References

1.4.1. SAAN Web site: http://www.saan.org

1.4.2. VISN/Integration PRD

The PRD defines the high-level user needs and features of the IFCAP VISN/Network Integration Patch. It focuses on what changes are needed in the process for acquisition and distribution of supplies and their justification. It is available to TAG members on the VISN/Integration web page at http://www.saan.org/tag/visn/visn.htm or from the Washington CIO Field Office.

2. Overall Description

2.1. Product Perspective

2.1.1. User Interfaces

The reports, option and screen formats will conform to the existing VISTA conventions. All revised option processing and new and revised reports will be tested for usability by test site personnel. This will ensure that all new functionality meets the needs of the VHA users.

2.1.2. Hardware Interfaces

The new functionality will run on the standard hardware platforms used by Department of Veterans Affairs Healthcare facilities. These systems consist of standard or upgraded Alpha AXP clusters, and run either DSM on the VMS operating system or OpenM on the MS NT operating system.

2.1.3. Software Interfaces

2.1.3.1 Financial Management System (FMS): official ledger of accounts, pays bills, records obligations and amendments

• Restrictions placed on the process capabilities: o will allow one site to represent a network o can handle VISN level instead of local site level o cannot have VISN level and local level o can substitute at a level but cannot add levels o every order must be obligated up front whether from appropriated Fund Control Point or Supply Fund o once money is distributed at a site-level FMS cannot process a purchase order from multiple stations

2.1.3.2 Austin Automation Center: processes EDI orders, matches invoice order with receiving reports for FMS payment, maintains Vendor file

• EDI orders must process properly.

2.1.3.3 AEMS/MERS

• Must work with AEMS/MERS interface with Fixed Assets package for tracking of capitalized equipment $ values and must not negatively impact CMRs

2.1.3.4 All new functionality must provide an audit trail for money and non-expendable equipment.

2.1.3.5 FileMan V. 21.0 2.1.3.6 IFCAP V. 5.0 2.1.3.7 Kernel V. 8.0 2.1.3.8 Kernel Toolkit V. 7.3 2.1.3.9 MailMan V. 7.1

2.1.4. Communications Interface

All new functionality must provide secure messaging between stations (new) and work with interfaces between stations and Austin databases.

This product will make use of MailMan and TCP/IP.

2.1.5. Memory Constraints

There are no memory constraints.

2.1.6. Special Operations

There are no special operations.

2.1.7. Implementation Requirements

This product introduces several new site-configurable parameters.

2.1.7.1. For Requesting primary: Automatic Backorder Y/N - determines whether an item is to be filled only in full or whether partial filling with backorder is acceptable.

2.1.7.2. For Supplying primary: Allow to go into negative Y/N - allows supplying inventory to control emergency level stock

2.1.7.3. Restrict inventory points when more than one primary is attached to the FCP - allows the site-wide limitations on combined orders

2.1.7..4 Allow system to choose best way to fill orders Y/N - After polling item availability at listed warehouses, the system will suggest how order should be placed. The user will be able to override the suggestion.

2.1.7.5. Supply Site Parameter: Emergency level can be used to fill orders from another warehouse Y/N

2.1.7.6. Print 2237 in Accountable Officer - allows Accountable Officer to print 2237 to a specified printer or to P-Message

2.2. Product Functions Overview

2.2.1. Connect multi- GIP Primaries to a single FCP (PRD 5.2)

The product will provide an automated way for determining if more than one GIP primary is associated with a single FCP. Users would like to be able to enter the same FCP for more than one primary. It will also provide the ability to convert current secondaries to primaries and have the existing fields and information carried over automatically.

2.2.2. Transfer stock from one Primary to another using Distribution Orders (PRD (5.3)

• Primaries will be able to transfer stock to other primaries and have inventory quantities and values updated appropriately. Transfer of stock between primaries within a single control point, different control points, or substation numbers will be possible.

• A primary will be able to choose another primary as the mandatory source vendor. Primary will be able to autogenerate to another primary or create a distribution order to one or more vendors.

• In order to transfer stock from one primary to another on the same station, sites will be able to designate an inventory point as a vendor for an item even though the warehouse(s) is listed as the mandatory source within the Item Master File.

2.2.3.Allow more than one supply fund warehouse in a single station. (PRD 5.5)

• Recent trends toward integrating stations has created situations where the resulting institution has one Station but the individual facilities each have a supply warehouse and SPD. An SPD will be able to locate and procure supplies from other warehouses in the institution.

• Sites will be able to designate more than one supply warehouse in File 445

2.2.4. Combine requests from one or more FCP in the same station on one order (PRD 5.1 *changed to *local only*)

• The product will allow requests from multiple FCPs within a single station to be combined on one order.

Other issues affecting this functionality:

Jerry Napoli (FMS) will look into transferring medical care funds with a request.

2.2.5.Enhanced Printing Capabilities (PRD 5.8)

• Vendor FAX number will appear on forms 2138, SF-30, RFQ SF-18, and 2237. • Purchasing Agent or Contracting Office FAX numbers and e-mail address will be printed on Forms 2237, SF-30,

and RFQ SF-18. • Users will have a larger selection of user definable printers that certain forms will print to. Printers currently

defined as "fixed" printing locations in the IFCAP Site Parameter file will be presented to the user as the default printer. User's will be able to enter a question mark and get a location listing of other available IFCAP printers.

2.3. User Characteristics

The functionality provided in this product will be used by Accountable Officers, Purchasing Agents, Supply personnel.

2.4. Constraints

Limitations on the developer's options include:

• The originating site needs to be able to send correct Engineering documents to FMS. • Legislative and Policy restriction must be observed (i.e., ADP equipment can only be bought from certain FCPs) • All new functionality must provide secure messaging between stations (new) and work with interfaces between

stations and Austin databases. • Constraints placed by ACC, FMS and AEMS/MERS. See section 2.1.3.

2.5. Apportioning of Requirements

The enhanced printing capabilities will be developed concurrently and separately from the other features in this product.

3. Specific Requirements

This section (3) of the SRS should contain all the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements. Throughout this section, every stated requirement should be externally perceivable by users, operators, or other external systems. These requirements should include at a minimum a description of every input (stimulus) into the system, every output (response) from the system and all functions performed by the system in response to an input or in support of an output. As this is often the largest and most important part of the SRS, the following principles apply:

• Specific requirements should be cross-referenced to earlier documents that relate. • All requirements should be uniquely identifiable.

Careful attention should be given to organizing the requirements to maximize readability.

3.1 Database Repository

If a logical database design is a part of your system, it should be listed here. Logical database design should specify the logical requirements for any information that is to be placed into a database. This may include:

• Types of information used by various functions • Frequency of use • Accessing capabilities • Data entities and their relationships • Integrity constraints • Data retention requirements

3.2 System Features

A feature is an externally desired service by the system that may require a sequence of inputs to effect the desired result. For example, in an E-Mail system, features include Send a Message, Forward a Message, and Delete a Message. Each feature is generally described in a sequence of inputs and outputs.

3.2.x Specific Feature

3.2.x.x Functional Requirements

Functional requirements should define the fundamental actions that must take place in the software in accepting and processing the inputs and in processing and generating the outputs.

These include:

• Validity checks on the inputs • Exact sequence of operations • Responses to abnormal situations • Error handling and recovery • Effect of parameters • Formulas for input to output conversion • Help functions

It may be appropriate to partition the functional requirements into sub-functions or sub-processes. This does not imply that the software design will also be partitioned that way.

3.2.1. Ability to connect multi- GIP Primaries to a single FCP (PRD 5.2)

3.2.1.1. Functional Requirement 1

Users will be able to use the same FCP for more than one primary.

3.2.1.1.1. Prior to CPO sign-off and assignment of transaction number, ask which primary gets the due-ins.

3.2.1.1.2. Ask for inventory point at every point where 2237 can be created if and only if there are multiple entries for inventory points attached to that control point.

3.2.1.1.3. Store inventory point at the line level but do not show on hardcopy PO.

3.2.1.1.4. The Receiving Report needs to be broken out by line item.


The system will allow conversion of a secondary to a primary and have the existing fields and information carried over automatically.

3.2.1.2.1. Allow three choices for vendor field: warehouse(s), outside vendor(s), other primary(ies).

3.2.1.2.2. Fields to carry over automatically: Alternate vendor, default vendor (printer at supplying warehouse or p-message), items (Unit of issue and or Unit of receipt), and delivery location.

3.2.1.2.3. FCP will be updated by user, must be able to use FCP already tied to another primary

3.2.2. Ability to transfer stock from one Primary to another using Distribution Orders (PRD 5.3)


Primaries need to be able to transfer stock between primaries within the same control point or different control points within the same station and have inventory quantities and values updated appropriately

3.2.2.1.1. There will be a new option on the Inventory Point menu: Sale/Transfer stock from one Primary to another. Use of the option will be controlled by the MGR key.

3.2.2.1.1.1. If both primaries have same FCP, no transfer of funds is needed. Show Quantity and Value but not Cost.

3.2.2.1.1.2. If transfer of stock involves different FCP ask if Sale or Transfer? If a sale, ask for cost.. Notification to Fiscal will be manual. (no documents sent) Notes also say," if sale, IV document must go to Fiscal for review and to FMS" ?? Lyford's notes say, "Upon sale where the Supply Fund is not involved, a document must be generated to Fiscal and the Control Point Official's of each control point to alert them of the need to transfer funds. Fiscal will generate a document (perhaps SA) to transfer funds. The IFCAP software will not automatically transfer the funds."

3.2.2.1.1.3 Transaction Register Report and History of Distribution will have two new codes for transfers and sales.

3.2.2.1.2. Two new fields are needed for transfers and sales: $ Amount and Quantity (same as on Distribution Order).

3.2.2.1.3. An electronic signature is required for sales order to certify that funds are available for sales, cost transfers, or warehouse.

3.2.2.1.4. The system will provide two new reports: Transfer Report and Sales Report. See 3.2.2.2.1.

3.2.2.1.5. Two new site parameters will be added:

3.2.2.1.5.1 For Requesting primary: Automatic Backorder Y/N

3.2.2.1.5.1.1 If Y: fill remainder, issue picking ticket, show balance due

3.2.2.1.5.1.2 If N: see 3.2.3.1.1

3.2.2.1.5.2. For Supplying primary: Allow to go into negative Y/N W ?

3.2.2.1.5.2.1 If Y:

3.2.2.1.5.2.2 If N: post only what is on hand but make note on Demand Report.

3.2.2.1.6 Inventory Point information will be at the line item level.

3.2.2.1.6.1 Add a Site Parameter: Restrict inventory points when more than one primary is attached to the FCP

3.2.2.1.6.1.1 If Yes: User does not get option to combine orders

3.2.2.1.6.1.2 If No: Ask user if they want a separate or combined order

3.2.2.1.6.1.2.1 If Separate: User does not get option to combine orders

3.2.2.1.6.1.2.2 If Combined: User is presented with Combined input template. Are we still going the separate template route for combined orders?

3.2.2.1.6.1.3 If order is autogenerated to warehouse, do not allow order to be combined (primary issue books need to remain separate).

3.2.2.1.6.1.4 Tie inventory points at line item, but don't show them on the order

3.2.2.1.6.1.5 Allow the user to override the inventory point default - if not an autogenerated order, user must enter all information for each line item.

3.2.2.1.7 Picking Ticket

3.2.2.1.7.1 Add a Site Parameter: Allow system to choose best way to fill orders Y/N On what menu?

3.2.2.1.7.1.1 If Yes: Show user the system's choice, ask Do you want to accept this? Y/N

3.2.2.1.7.1.1.1 If Yes, proceed with order

3.2.2.1.7.1.1.2 If No, show what defined primaries have available. Primary B has xx amount on hand (see screen below).

3.2.2.1.7.1.2 If No (to site parameter): If No, show what defined primaries have available. Ask, "Which Primary do you want to order from?"

ITEM Amounts Available Elsewhere Gloves 36 in Primary B 25 in Primary C Which Primary do want to order this item from?

3.2.2.1.7.1.3 Print order to default printer of supplying primary as listed in set-up

3.2.2.1.8. Supplying Inventory Point will have an option to reject the order. On what menu?

3.2.2.1.8.1 Send picking ticket back to requesting primary

3.2.2.1.8.2 Eliminate due-in

3.2.2.1.8.3 At Requesting Primary: Convert picking ticket to 2237

3.2.2.1.8.4 At Requesting Primary: Recreate due-in

3.2.2.1.9. If order is from another FCP: sale

3.2.2.1.9.2 Generate document (need to check with Jerry N. to see if IV doc can be used if neither FCP is a supply fund.)

3.2.2.1.9.3 check supplying primary for stock on hand (see sscreen)

3.2.2.1.9.4 Show to Primary

3.2.2.1.9.5 Ask: Do you want to create this picking ticket? Y/N

3.2.2.2. Reports

3.2.2.2.1 New Sales and Transfer Reports show what $ Value is owed to you from whom.

3.2.2.2.1.1 User defines date range

3.2.2.2.1.1.1 Sort options: Control Point

3.2.2.2.1.1.2 Inventory point that stock went to

3.2.2.2.1.2 Information to show: Document #, amount sold, date of sale, IFCAP Item #, short description of item, Quantity, Dollar amount, subtotal $ by FCP and Inventory point within FCP, total.

3.2.2.2.2 Summary Sales and Transfer Reports: show how much owed to what FCP, how much owed by what FCP. subtotal $ by FCP and Inventory point within FCP

3.2.2.2.4 Notification to Fiscal will be manual.

3.2.2.2.2 Receiving Report will be broken down by line item showing what inventory point receives each item.


A primary needs to be able to override the mandatory source vendor.

3.2.2.3.1. When user is asked for source (File 440) allow user to set-up multiple. Choices will be: Mandatory Vendor, Primary Source Vendor (2237), Suggested Primary Source (Distribution Order).

3.2.2.3.2. In File 441, add Primary Source Vendor (2237) and Suggested Primary Source (Distribution Order) fields. A pointer to a subfile listing primaries is suggested. If left blank , do not autogenerate order.


Primary will be able to autogenerate a distribution order to another primary inventory point or to a vendor.

3.2.2.4.1 Generate 2237 for outside vendors, issue book for warehouse, sale/transfer document for another primary.

3.2.2.4.2 The current ability for a secondary to autogenetate a distribution order to a primary will not change.


The user will be able to autogenerate Distribution Orders to one or more vendors. Distribution Orders will reflect "Transfer" on the transaction register. The History of Distribution will include "Transfer".


The Repetitive Item List will allow a distribution vendor to be from another primary. It will create the Distribution Orders as well as Purchase Card Orders, Delivery Orders, and 2237s.

3.2.3. Ability to have more than one supply fund warehouse in a single station (from issue Books only). (PRD 5.5)


Recent trends toward integrating stations has created situations where the resulting institution is one station but the individual facilities each have a supply warehouse and SPD. An SPD needs the ability to locate and procure supplies from other warehouses in the institution. Sites need to be able to designate more than one supply warehouse in File 445.

3.2.3.1.1 In Item Master file, mandatory source field will be a multiple for entry of a warehouse progression

3.2.3.1.1.1 WHSE A, WHSE B, etc. until null entry

3.2.3.1.1.2 If multiple warehouses are not filled in, order from vendor

3.2.3.1.1.3 Order of warehouse entry determines the order in which they are used to fill an order.

Order is placed

WHSE A If order for item can be filled completely:

Post to warehouse, due-out created

Generate IV transfer document

If item can't be filled completely:

Kill Due-out

Kill Due-in

Create new transaction that references original transaction #

Look in next WHSE in progression

WHSE B Same as above

Etc.

3.2.3.1.1.3 If no more warehouses are defined in set-up or no warehouse in progression can fill total for item:

3.2.3.1.1.3.1 Post issue book

3.2.3.1.1.3.2 Create Due-out in warehouse

3.2.3.1.1.3.3 Poll warehouses in set-up

3.2.3.1.1.3.4 Present user with exception screen of unfilled items (see mock-up screen)

3.2.3.1.1.3.5 Exception screen only shown if multiple warehouses are listed in set-up. Shows only those items not filled in full.

3.2.3.1.1.3.6. Once user has completed exception handling, prompt for electronic signature.

ITEM QTY Ordered Qty Filled Amounts Available Elsewhere

Unit of Issue

1. Gloves 20 4 36 in WHSE B box of 100 2. 4x4 gauze 40 0 in WHSE B case of 12 box 25 in WHSE C box of 100

Actions available: Order Kill Backorder

ACTION:____ For what items?_____ (user can input one, several, range) ACTION:____ repeat until all exceptions are handled (What happens if null entry?) For what items?_____ (user can input one, several, range)

3.2.3.1.1.3.6 If Order:

3.2.3.1.1.3.6.1 Generate picking tickets after all exceptions are dealt with

3.2.3.1.1.3.6.2 Create new Issue Book for each supplying warehouse

3.2.3.1.1.3.6.2.1 reference original Transaction number.

3.2.3.1.1.3.6.2.2 reference supplying warehouse's unit of issue

3.2.3.1.1.3.6.2.3 allow user to edit new Issue Book

3.2.3.1.1.3.6.3 Create new entry in File 410 with new transaction/voucher # pointing to original transaction and e-sig

3.2.3.1.1.3.6.4 Requesting primary is listed as delivery point at the item level.

3.2.3.1.1.3.6.5 Create applicable document

3.2.3.1.1.3.7 IF Kill

3.2.3.1.1.3.7.1 Kill Due-out

3.2.3.1.1.3.7.2 Kill Due-In

3.2.3.1.1.3.7.3 Convert picking ticket to 2237

3.2.3.1.1.3.7.4 User chooses vendor

3.2.3.1.1.3.8 If Backorder

3.2.3.1.1.3.8.1 Fill partial

3.2.3.1.1.3.8.2 Reduce quantity ordered by amount filled (at supplying vendor)

3.2.3.1.1.3.8.3 Create new transaction for amount backordered (at ordering site)

3.2.3.1.2 Supply Warehouse Site Parameter: Emergency level can be used to fill orders from another warehouse Y/N


In order to transfer stock from one primary to another on the same station, sites need to be able to designate an inventory point as a vendor for an item even though the warehouse(s) is listed as the mandatory source within the Item Master file. Also see section 5.3.

3.2.3.2.1 Change File 445 to allow multiple warehouses.

3.2.3.2.1.1 IMF-Mandatory=WHSE (WHSE A, WHSE B, etc.)

3.2.3.2.1.2 WHSE GIP-Mandatory=Vendor

3.2.3.2.1.3 GIP=WHSE A, or B for autogen in set-up


3.2.3.3.1 Additional Reports needed for sites that have multiple warehouses set up in File 445

3.2.3.3.1.1 Consolidated Stock (Combined status of multiple warehouses)

3.2.3.3.1.2 Consolidated Voucher Summary report

3.2.3.3.1.3 Consolidated Inactive Item List

3.2.3.3.1.4 Turn-over Rate

3.2.4. Combining requests from one or more stations in the same station on one order (PRD 5.1)

Changed to: Multiple Fund Control Points of the Same Appropriation on a Single Purchase Order

3.2.4.1 Process

3.2.4.1.1 Ship To Location would be moved to the line item level. We still need to talk with Susan Thomason to ask if it is possible to have multiple Ship To Locations on a single order as sites consolidated under one station number may still be geographically distant from one another.

3.2.4.1.2 Accounting information will still need to be on the line item level. Also at the line level would be the Source Code, Discount (if any), Reason Code, Inventory Point and Delivery Location.

3.2.4.1.3 At the Source Code prompt, ask for the value and ask if this value is for all items. If not, then ask the Source Code value for those lines not included. (i.e. User is prompted for Source Code and enters '6'.

3.2.4.1.4 At the 'Which Lines: ' prompt the user enters 'ALL' or '3,7,8') If the user enters Source Code 'B' then prompt for the Reason Code. It was also discussed to make Source Code 'B' no longer selectable.

There was discussion as to how to infer or populate the Source Code without direct user input on the Purchase Order. Possibilities:

3.2.4.1.4.1. If contract # begins with 'V797P' or 'GS' then populate Source Code field with '6' and when a Purchasing Agent edits this field all other values than '6" would be screened out for selection.

3.2.4.1.4.2. A Source Code field could be added to the Vendor multiple of the Item Master file. The value here could be stuffed in the PO's Source Code field for Line Items referencing an Item Master file entry.

The Purchasing Agent would only have to answer the PO's Source Code field where the value is absent. The group decided that the Source Code/Reason Code issues are more complex than appear at first glance and that the issue should be referred to the Acquisition TAG.

3.2.4.1.5 Currently the Purchase Order's entire Shipping Charges are paid with the first Receiving Report partial. Unless this can be changed, this will complicate the combined Purchase Order as the site receiving the first partial may not be liable for the bulk of the Shipping Charges.

3.2.4.2 Modification to Existing Reports:

3.2.4.2.1. Purchase Order display should be modified to be more friendly for multiple FCP Purchase Orders. When the Control Point Clerk pulls up an order, he/she should be asked 'Do you want to see all the items on the order? NO// '. If the user accepts the default, he/she will see only those items ordered for his/her Control Point. If the response is 'YES' all items will display, just as the PO Display does now.

3.2.4.2.1. Receiving Reports - Modify so that there is a separate report for items at each Delivery Location. There should also be an option to print the entire partial across all Delivery Locations.

3.2.5. Enhanced Printing Capabilities (PRD 5.8)

• 7/30/97 The enhanced printing capabilities will be addressed as a separate but concurrent project. (PRD)


Add Vendor FAX number Form Form # Where

Purchase Order 2138 Vendor Information block near phone and account #

Amendment Form SF-30 Block 8, lower right Request for Quotation RFQ SF-18 Block 8, lower right

Request, Turn-in, and Receipt 2237 Vendor Information block near phone and account #s Need confirmation from TAG whether is correct


Print Purchasing Agent or Contracting Office FAX numbers and e-mail address Form Form # Where Purchase Order 2237 with phone # for Contracting Office Amendment Form SF-30 Block 16A Request for Quotation RFQ SF-18 Block 5B (also sent to VANs) in 840 transaction Request, Turn-in, and Receipt 2237 Removed 8/14/97 No request found for this feature.


Users need the ability to FAX vendors directly from the Device prompt

7/2/97 The VISN/Integration TAG will determine what information the vendor needs and redesign the form. (PRD)

No further discussions have taken place concerning FAX devices. Those sites which have set up the faxing of document, have had to buy additional hardware or software and achieved this result by different means. The use of Steve Pollocks' Class III software would require the purchase of specific hardware the reformatting of some documents. Lyford believes that this issue is on hold. Need confirmation from TAG.


Users need a larger selection of user definable printers that certain forms will print to. 411,11 PRINTER USE 2;0 SET Multiple #411.02

DESCRIPTION:

This is information about the printer.

411.02,.01 PRINTER LOCATION 0;1 SET (Multiply asked)

'F' FOR FISCAL (P.O.,1358);

'FR' FOR FISCAL (REC.REPORTS);

'R' FOR RECEIVING (SUPPLY);

'S' FOR SUPPLY (PPM);

'S8' FOR SUPPLY 2138;

'S9' FOR SUPPLY 2139;

'A' FOR ACCOUNTS REC.;

'UB' FOR UB-82;

'IFP' FOR IMPREST FUNDS P.O.;

'IFR' FOR IMPREST FUNDS RECEIVING REPORT;

'M' FOR MAILMESSAGE;

LAST EDITED: FEB 12, 1993

HELP-PROMPT: Select an Admin Activity printer location to

be used for certain reports that are

automatically printed in various locations.

DESCRIPTION: This is the administrative activity printer

location.

CROSS-REFERENCE: 411.02^AD^MUMPS

1)= I $P(^PRC(411,DA(1),2,DA,0),U,2)]"" S ^PR

C(411,DA(1),2,"AC",X,$E($P(^(0),U,2),1,30),DA

)=""

2)= I $P(^PRC(411,DA(1),2,DA,0),U,2)]"" K ^PR

C(411,DA(1),2,"AC",X,$E($P(^(0),U,2),1,30),DA

)

This cross reference is set on one of the

valid codes used to indicate the printer

location. The set of codes is stored in the

Printer Location sub-field of the Printer

Use field.

CROSS-REFERENCE: 411.02ÂF^MUMPS

1)= I $P(^PRC(411,DA(1),2,DA,0),U,3)]"" S ^PR

C(411,DA(1),2,"AE",X,$P(^(0),U,3),DA)=""

2)= I $P(^PRC(411,DA(1),2,DA,0),U,3)]"" K ^PR

C(411,DA(1),2,"AE",X,$P(^(0),U,3),DA)

This cross reference is used to set the "AE"

cross reference. The "AE" cross reference

is set on the name of the device.

411.02,1 DEVICE 0;2 FREE TEXT (Required)

INPUT TRANSFORM: S DIC="^%ZIS(1,",DIC(0)="EMQZ" D ^DIC K:Y'>0

X S:$D(X) X=$P(Y(0),U,1) K DIC

LAST EDITED: JUL 17, 1985

HELP-PROMPT: Select the printer device assigned to this

location

DESCRIPTION: This is the printer device assigned to this

location.

EXECUTABLE HELP: S ZD=D,X="?",DIC="^%ZIS(1,",DIC(0)="EMZ" D ^D

IC S DIC=DIE,D=ZD K ZD

NOTES: XXXX-CAN'T BE ALTERED EXCEPT BY PROGRAMMER

CROSS-REFERENCE: 411.02ÂC^MUMPS

1)= S ^PRC(411,DA(1),2,"AC",$P(^PRC(411,DA(1)

,2,DA,0),U,1),$E(X,1,30),DA)=""

2)= K ^PRC(411,DA(1),2,"AC",$P(^PRC(411,DA(1)

,2,DA,0),U,1),$E(X,1,30),DA)

This cross reference is set on the device

name.

411.02,2 STACK DOCUMENTS 0;3 SET

'0' FOR NO;

'1' FR YES;

LAST EDITED: APR 23, 1992

HELP-PROMPT: ENTER A '1' (YES) IF YOU WISH TO HOLD

DOCUMENTS FOR LATER RELEASE

DESCRIPTION: YES indicate that the documents will be held

for later release.

CROSS-REFERENCE: 411.02ÂE^MUMPS

1)= S ^PRC(411,DA(1),2,"AE",$P(^PRC(411,DA(1)

,2,DA,0),U),X,DA)=""

2)= K ^PRC(411,DA(1),2,"AE",$P(^PRC(411,DA(1)

,2,DA,0),U),X,DA)

This cross reference is set on the name of

the Fiscal stacked documents printer.

411.02,3 DAYS FOR DOCUMENTS RETENTION 0;4 NUMBER

INPUT TRANSFORM: K:+X'=X!(X>90)!(X<1)!(X?.E1"."1N.N) X

LAST EDITED: AUG 06, 1992

HELP-PROMPT: Type a Number between 1 and 90, 0 Decimal

Digits

DESCRIPTION: This field is used to calculate the date

to stop purging of this file's entries. If

this field is blank, the default will be 7

days so that entries older than 7 days are

purged when the background job to purge this

file runs.

NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER

3.2.5.4.1. The following changes were proposed:

3.2.5.4.1.1. Mnemonic 'F' be changed to 'F-PO' (Purchase Order) and code should be changed so that Purchase Orders for Fiscal print to this device.

3.2.5.4.1.2. Mnemonic 'F1358' (1358) should be added and the code for printing 1358 changed to reference this mnemonic.

3.2.5.4.1.3. Mnemonic 'F30' (Amendment) should be added and the code changed so that amendments print there.

3.2.5.4.1.4. Mnemonic 'S' should be eliminated.

3.2.5.4.1.5. Mnemonic 'S-2237R' (Regular Request) should be added and code for printing non-Federal 2237s should be changed to print to this device.

3.2.5.4.1.6. Mnemonic 'S2237I' (Issue Book (form type 5)) should be added and code for printing Issue Books should be changed to use this device.

3.2.5.4.1.7. Mnemonic 'S2237F' (Federal Vendor Request) should be added and code for printing Federal 2237s should be changed to use this device.

3.2.5.4.1.8. Mnemonic 'SR' should be added and code for printing Obligated Requisitions in Supply PPM changed to use this device.

3.2.5.4.1.9. Mnemonic 'S-AV' (Adjustment Voucher (PPM)) should be added and code for printing Adjustment Vouchers in PPM should be changed to use this device.

3.2.5.4.1.10. Mnemonic 'S-AmendF' (Amendment to requisition (PPM)) should be added and code for printing Amendments to Requisitions in PPM should be changed to use this device.

3.2.5.4.1.11. Mnemonic 'S8' should be changed to 'S-PO' (Purchase Order) and code changed for printing Purchase Orders in Supply.

3.2.5.4.1.12. Mnemonic 'S9' should be eliminated.

3.2.5.4.1.13. Mnemonic 'S30' (Amendment) should be added and code for printing Amendments changed to use this printer.

3.2.5.4.1.14. Mnemonic 'S18 R' (Request for Quotation) should be added and code for printing Requests for Quotations changed to use this printer.

3.2.5.4.1.15. Mnemonic 'S ADJ' (Adjustment to Receiving report) should be added and code for printing adjustments to receiving reports should be changed to use this printer.

3.2.5.4.2. The implementation of this change will necessitate a change in the definition for the PRINTER LOCATION field (411.02,.01) from a set of codes to a pointer to a dictionary file of printer mnemonics. During the installation of this patch, the data in this field should be converted from the string of the mnemonic to the internal entry number of the corresponding dictionary entry with the following mapping:

F -> ien of F-PO FR -> ien of FR R -> ien of R S -> ien of S-2237R

add entry for S2237I, copying fields for former S entry add entry for S2237F, copying fields for former S entry add entry for SR, copying fields for former S entry add entry for S-AV, copying fields for former S entry add entry for S-AmendF, copying fields for former S entry add entry for S-PO, copying fields for former S entry add entry for S30, copying fields for former S entry add entry for S ADJ, copying fields for former S entry A -> ien of A UB -> ien of UB IFP -> ien of IFP IFR -> ien of IFR M -> ien of M

Then kill ^PRC(411,DA(1),2,"AC") and ^PRC(411,DA(1),2,"AE") and reindex "AD" and "AF" cross references on field #.01.

3.2.5.4.3. The set of routines that need to be checked and probably modified includes but is probably not limited to:

PRCFACB, PRCFACBT, PRCHQ2B, PRCHQM1, PRCHQUE, PRCHRPT, PRCHRPT6, PRCHRPT7, PRCPAWR0, PRCPSMCL, PRCSAPP2

3.2.5.4.4. The TAG members should specify wherever, background printer selection should be changed to an 'On Device' prompt with default, or vice versa.


Some printing issues will be addressed by patch PRC*5*69.


Printing from Accountable Officer's menu within option Process a Request Select Accountable Officer Menu Option: PROCESS a Request in PPM Select STATION NUMBER ('^' TO EXIT): 688// WASHINGTON, DC Enter ELECTRONIC SIGNATURE CODE: Thank you. PROCESS ISSUE BOOK ORDERS? NO// Y (YES) Processing Issue Book Orders--Please Wait! Transaction No.: 688-98-1-120-0005 2237 TRANSACTION NUMBER: ? Answer with REQUEST WORKSHEET 2237 TRANSACTION NUMBER Choose from: 688-98-1-120-0006 Pending Accountable Officer Sig. OBL BAXTER SC IENTIFIC PR ARM BOARD 9 INCH LONG

2237 TRANSACTION NUMBER: 688-98-1-120-0006 OBL BAXTER SCIENTIFIC PR ARM BOARD 9 INCH LONG Pending Accountable Officer Sig. TYPE OF REQUEST: ? Choose from: 1 UNPOSTED 2 POSTED 3 SERVICE 4 BULK SALE 5 NX POSTED TYPE OF REQUEST: 2 POSTED SOURCE OF REQUEST: ? Choose from: 1 VA STOCK 2 GSA/DLA STOCK 3 EXCESS 4 NOT AVAILABLE FROM ANY OF THESE SOURCES SOURCE OF REQUEST: 4 NOT AVAILABLE FROM ANY OF THESE SOURCES CURRENT STATUS: Pending Accountable Officer Sig.// 70 Sent to Purchasing & Cont racting 70 DEVICE: Default// IF new Site Parameter Switch 'Print 2237 in Accountable Officer' is set to 'YES' go into On Device logic; Default from S-2237R, which may specify a actual printer (i.e. Remote TCP/IP Printer) or P-Message DEVICE: P-MESSSAGE-HFS// <cr> HFS FILE==>MAILMESSAGE Moving text to MailMan message... (Creating now) Subject: 2237 for T. Wolgamott<cr> User inputs subject END OF FILE Send mail to: Accountable Officer's Name// Wolgamott, Terry<cr> [email protected] User inputs recipient And send to: <cr>.. Message subject: 2237 for T. Wolgamott Message number: 235097 2237 TRANSACTION NUMBER: Select Accountable Officer Menu Option: Note: The issue was raised as to whether this Process a Request in PPM option is in fact necessary with today's business rules.


Change default from 'Yes' to 'No' for the 'Print last page of 2237?' prompt in options New 2237 (Service) Request [PRCSENRB] and Edit a 2237 (Service) [PRCSEDTD] of the Process a Request Menu ... [PRCSER]. The current dialog follows: Would you like to review this request? No// y (Yes) Print last page of 2237? Yes// (Yes) DEVICE: HOME// Lyford is somewhat perplexed by this one. Whether you answer 'Yes' or 'No' on our test system you are shown the same data. The difference appears to be that you may have an additional page break and header displayed. Is this what users are seeing in the field? If so, why not eliminate the 'Print last page of 2237?' question and display the form as it does now for the 'No' response.

3.3. Performance Requirements

This subsection should specify dynamic numerical requirements placed on the software or on human interaction with the software as a whole. Numerical requirements may include:

• The number of simultaneous users to be supported • Dynamic numerical requirements may include, for example, the numbers of transactions and tasks and the amount

of data to be processed within certain time periods for both normal and peak workload conditions.

All of these requirements should be stated in measurable terms.

For example,

95% of the transactions shall be processed in less than 1 s.

Rather than,

An operator shall not have to wait for the transaction to complete.

1. Numerical limits applied to one specific function are normally specified as part of the processing subparagraph description of that function.

3.4. Design Constraints

All money and inventory tracking must adjust correctly. All new functionality must provide an audit trail for money and non-expendable equipment.

3.5. Security

All new functionality must provide secure messaging between stations (new) and work with interfaces between stations and Austin databases. This product will conform to all existing IFCAP security measures.

3.6. Portability

All code will conform to VA SAC and Financial Integrity and portability standards.

3.7. Other Requirements

There are no further requirements.

4. Function Point Estimation

This section of the SRS should detail the function point estimation for the project. Since the analysis is more complete than that of the PRD, the estimate should generally be higher. After documenting the estimation here, it must be entered into the Productivity Management software and a snapshot must be taken.

5. Revisions (Optional)

This optional section should detail the revisions made after the SRS has been signed off.

6. Glossary

1358 Estimated Miscellaneous Obligation or Change in Obligation. 2138 VA Form 90-2138, Order for Supplies or Services. First page of a VA Purchase Order. 2139 VA Form 90-2139, Order for Supplies or Services (Continuation). This is a continuation sheet for the

2138 form. 2237 VA Form 90-2237, Request, Turn-in and Receipt for Property or Services. Used to request goods and

services. A&MM Acquisition and Materiel Management Service. AACS Automated Allotment Control System--Central computer system developed by VHA to disburse

funding from VACO to field stations. Accounting Technician Fiscal employee responsible for obligation and payment of received goods and services. Accounting

Technicians process accounting transactions and transmit them to FMS. Activity Code The last two digits of the AACS number. It is defined by each station. ADP Security Officer The individual at your station who is responsible for the security of the computer system, both its

physical integrity and the integrity of the records stored in it. Includes overseeing file access. Agent Cashier The person in Fiscal Service (often physically located elsewhere) who makes or receives payments on

debtor accounts and issues official receipts. ALD Code Appropriation Limitation Department. A set of Fiscal codes which identifies the appropriation used

for funding. Allowance table Reference table in FMS that provides financial information at the level immediately above the AACS,

or sub-allowance level. Amendment A document which changes the information contained in a specified Purchase Order. Amendments are

processed by the Purchasing & Contracting section of A&MM and obligated by Fiscal Service. AMIS Automated Management Information System. Application Coordinator The individuals responsible for the implementation, training and trouble-shooting of a software

package within a service. IFCAP requires there be an Application Coordinator designated for Fiscal Service, Supply Service, and for the Control Points (Requesting Services).

Approve Requests The use of an electronic signature by a Control Point Official to approve a 2237, 1358 or other request form and transmit said request to Supply/Fiscal.

Authorization A charge to an obligated 1358. Each authorization represents a deduction from the balance of a 1358 to cover an expense. Authorizations are useful when you have expenses from more than one vendor for a single 1358.

Authorization Balance The amount of money remaining that can be authorized against the 1358. The service balance minus total authorizations.

Batch Number A unique number assigned by the computer to identify a batch (group) of Code Sheets. Code Sheets may be transmitted by Batch Number or Transmission Number.

Breakout Code A set of A&MM codes which identifies a vendor by the type of ownership (e.g., Minority-owned, Vietnam Veteran Owned, Small Business Total Set Aside, etc.).

Budget Analyst Fiscal employee responsible for distributing and transferring funds. Budget Object Code Fiscal accounting element that tells what kind of item or service is being procured. Budget object

codes replace subaccounts in IFCAP 5.0. Budget object codes are listed in the left column of MP-4 Part V, Appendix B-1.

Budget Sort Category Used by Fiscal Service to identify the allocation of funds throughout their facility. Ceiling Transactions Funding distributed from Fiscal Service to IFCAP Control Points for spending. The Budget Analyst

initiates these transactions using the Funds Distribution options. Classification of Request An identifier a Control Point can assign to track requests that fall into a category, e.g., Memberships,

Replacement Parts, Food Group III. Common Numbering Series

This is a pre-set series of Procurement and Accounting Transaction (PAT) numbers used by Purchasing and Contracting, Personal Property Management, Accounting Technicians and Imprest Funds Clerks to generate new Purchase Orders/Requisitions/Accounting Transactions on IFCAP. The Application Coordinators establish the Common Numbering Series used by each facility.

Control Point Financial element, existing ONLY in IFCAP, that corresponds to the ACCS number in FMS. Also the division of monies to a specified service, activity or purpose from an appropriation.

Control Point Clerk The user within the service who is designated to input requests (2237s) and maintain the Control Point records for a Service.

Control Point Official The individual authorized to expend government funds for ordering of supplies and services for their Control Point(s). This person has all of the options the Control Point Clerk has plus the ability to approve requests by using their electronic signature code.

Control Point Official's Balance

A running record of all the transactions generated and approved for a Control Point. Provides information that shows the total amount of funds committed, obligated and remaining to be spent for a specified fiscal quarter.

Control Point Requestor The lowest level Control Point user, who can only enter temporary requests (2237s, 1358s) to a Control Point. This user can only view or edit their own requests. A Control Point Clerk or Official must make these requests permanent before they can be approved and transmitted to A&MM.

Cost Center "Subsection" of a Fund Control Point. Cost centers allow fiscal staff to create total expense reports for a section or service, and allow requestors to assign requests to that section or service. Cost centers are listed in the left column of MP-4, Part V, Appendix B-1.

Cost Center A subdivision of a Fund Control Point which tells which service/section is being charged for a request/order.

Date Committed The date that you want IFCAP to commit funds to the purchase. Default A suggested response that is provided by the system. Deficiency When a budget has obligated and expended more than it was funded (see MP-4, Part V, Section C). Delinquent Delivery Listing

A listing of all the Purchase Orders that have not had all the items received by the Warehouse on IFCAP. It is used to contact the vendor for updated delivery information.

Direct Delivery Patient A patient who has been designated to have goods delivered directly to him/her from the vendor. Discount Item This is a trade discount on a Purchase Order. The discount can apply to a line item or a quantity. This

discount can be a percentage or a set dollar value. EDI Vendor A vendor with whom the VA has negotiated an arrangement to accept and fill orders electronically. Electronic Data Interchange (EDI)

Electronic Data Interchange is a method of electronically exchanging business documents according to established rules and formats.

Electronic Signature The electronic signature code replaces the written signature on all IFCAP documents used within your facility. Documents going off-station will require a written signature as well.

Expenditure Request A Control Point document that authorizes the expenditure of funds for supplies and/or services (e.g., 2237, 1358, etc.).

FCP Fund Control Point (see Control Point). Federal Tax ID A unique number that identifies your station to the Internal Revenue Service. Fiscal Balance The amount of money on a 1358 and any adjustments to that 1358 that have been obligated by Fiscal

Service. This amount is reduced by any liquidations submitted against the obligation. Fiscal Quarter The fiscal year is broken into four three month quarters. The first fiscal quarter begins on October 1. Fiscal Year Twelve month period from October 1 to September 30. FMS Financial Management System, which has replaced CALM as the primary accounting system for

administrative appropriations. FMS has a comprehensive data base that provides for flexible on-line and/or batch processing, ad-hoc reporting, interactive query capability and extensive security. FMS is concerned with budget execution, general ledger, funds control, accounts receivable, accounts payable and cost accounting.

FOB Freight on Board. An FOB of "Destination" means that the vendor has included shipping costs in the invoice, and no shipping charges are due when the shipper arrives at the warehouse with the item. An FOB of "Origin" means that shipping charges are due to the shipper, and must be paid when the shipper arrives at the warehouse with the item.

FPDS Federal Procurement Data System. FTEE Full Time Employee Equivalent. An FTEE of 1 stands for 1 fiscal year of full-time employment. This

number is used to measure workforces. A part-time employee that worked half days for a year would be assigned an FTEE of 0.5, as would a full-time employee that worked for half of a year.

Fund Control Point CALM accounting element that is not used by FMS. Funds Control A group of Control Point options that allow the Control Point Clerk and/or Official to maintain and

reconcile their funds. Funds Distribution A group of Fiscal options that allows the Budget Analyst to distribute funds to Control Points and

track Budget Distribution Reports information. GBL Government Bill of Lading. A document that authorizes the payment of shipping charges in excess of

$100.00. GL General Ledger. Identification Number A computer-generated number assigned to a code sheet. Imprest Funds Monies used for cash or 3rd party draft purchases at a VA facility. Integrated Supply Management System (ISMS)

ISMS is the system which replaced LOG I for Expendable Inventory.

ISMS Integrated Supply Management System. Item File A listing of items specified by A&MMS as being purchased repetitively. This file maintains a full

description of the item, related stock numbers, vendors, contract numbers and a procurement history. Item History Procurement information stored in the Item File. A history is kept by Fund Control Point and is

available to the Control Point at time of request. Item Master Number A computer generated number used to identify an item in the Item File. Justification A written explanation of why the Control Point requires the items requested. Adequate justification

must be given if the goods are being requested from other than a mandatory source. Justification A written explanation of why the Control Point requires the items requested. Adequate justification

must be given if the goods are being requested from other than a mandatory source. Liquidation The amount of money on the invoice from the vendor for the authorization. They are processed

through payment/invoice tracking. LOG I LOG I is the name of the Logistics A&MM computer located at the Austin Data Processing Center.

This system continues to support the Consolidated Memorandum of Receipt. Mandatory Source A Federal Agency that sells supplies and services to the VA. VA Supply Depot, Defense Logistics

Agency (DLA), General Services Administration (GSA), etc. MSC Confirmation Message

A MailMan message generated by the Austin Message Switching Center that assigns an FMS number to an IFCAP transmission of CALM Code Sheets.

Obligation The commitment of funds. The process Fiscal uses to set aside monies to cover the cost of a Purchase Order.

Obligation (Actual) Amount

The actual dollar figure obligated by Fiscal Service for a Purchase Order. The Control Point's records are updated with actual cost automatically when Fiscal obligates the document on IFCAP.

Obligation Data A Control Point option that allows the Control Point Clerk to enter data not recorded by IFCAP. Obligation Number The C prefix number that Fiscal Service assigns to the 1358. Organization Code Accounting element functionally comparable to Cost Center, but used to organize purchases by the

budget that funded them, not the purposes for spending the funds. Outstanding 2237 A&MM report that lists all the IFCAP generated 2237s pending action in A&MM. PAID Paid Accounting Integrated Data. Partial A Receiving Report (VA document that shows receipt of goods) for only some of the items ordered

on a Purchase Order. Partial Date The date that a warehouse clerk created a receiving report for a shipment. PAT Number Pending Accounting Transaction number - the primary FMS reference number. Personal Property Management

A section of A&MM Service responsible for screening all requests for those items available from a Mandatory Source, VA Excess or Bulk sale. They also process all requisitions for goods from Federal Agencies and equipment requests. In addition, they maintain the inventory of Warehouse stocked items and all equipment (CMRs) at the facilities they support.

PPM Personal Property Management.

Procurement Request Cards VA Form 10-7142. Used to order items repetitively.

Program Code Accounting element that identifies the VA initiative or program that the purchase will support. Prompt PaymentTerms The discount given to the VA for paying the vendor within a set number of days (e.g., 2% 20 days

means the VA will save 2% of the total cost of the order if the vendor is paid within 20 days of receipt of goods).

Purchase History Add (PHA)

Information about purchase orders which is automatically sent to Austin for archiving. This same transaction is also used to send a PO for EDI processing.

Purchase Order A government document authorizing the purchase of the goods or services at the terms indicated. Purchase Order Acknowledgment

Information returned by the vendor describing the status of items ordered (e.g., 10 CRTs shipped, 5 CRTs backordered).

Purchase Order Status The status of completion of a purchase order (e.g., Pending Contracting Officer's Signature, Pending Fiscal Action, Partial Order Received, etc.).

Purchasing Agents A&MM employees legally empowered to create purchase orders to obtain goods and services from commercial vendors.

Quarterly Report A Control Point listing of all transactions (Ceilings, Obligations, Adjustments) made to a Control Point's Funds.

Quotation for Bid Standard Form 18. Used by Purchasing Agents to obtain written bids from vendors. Receiving Report Report that Warehouse Clerk creates to record that the warehouse has received an item. Receiving Report The VA document used to indicate the quantity and dollar value of the goods being received. Reference Number Also known as the Transaction Number. The computer generated number that identifies a request. It is

comprised of the: Station Number-Fiscal Year-Quarter - Control Point - 4 digit Sequence Number. Repetitive (PR Card) Number See Item Master Number.

Repetitive Item List A method the Control Point uses to order items in the Item File. The Control Point enters the Item Master Number, the quantity and vendor and IFCAP can sort and generate requests from the list.

Requestor See "Control Point Requestor." Requisition An order from a Government vendor. Running Balance A running record of all the transactions generated and approved for a Control Point. Provides

information that shows the total amount of funds committed, obligated, and remaining to be spent for a specified fiscal quarter.

Section Request A temporary request for goods and/or services entered by a Control Point Requestor. These requests may or may not be made permanent by the Control Point Clerk/Official.

Service Balance The amount of money on the on the original 1358 and any adjustments to that 1358 when created by that service in their Fund Control Point. This amount is reduced by any authorizations created by the service.

SF-18 Request for Quotation. SF-30 Amendment of Solicitation/Modification of Contract. Short Description A phrase which describes the item in the Item Master file. It is restricted to 3 to 60 characters and

consists of what the item is, the kind of item, and the size of item (e.g., GLOVE-SURGICAL MEDIUM).

Site Parameters Information (such as Station Number, Cashier's address, printer location, etc.) that is unique to your station. All of IFCAP uses a single Site Parameter file.

Sort Group An identifier a Control Point can assign to a project or group of like requests. It is used to generate a report that will tell the cost of requests.

Sort Order The order in which the budget categories will appear on the budget distribution reports. Special Remarks A field on the Control Point Request that allows the CP Clerk to enter information of use to the

Purchasing Agent or vendor. This field can be printed on the Purchase Order. Stacked Documents The POs, RRs & 1358s which are sent electronically to Fiscal and stored in a file rather than being

printed immediately. Status of Funds Fiscal's on-line status report of the monies available to a Control Point. FMS updates this information

automatically. Sub-control Point A specific budget within a Control Point, defined by a Control Point user. Sub-cost Center A subcategory of Cost Center. In IFCAP 5.0, the last two digits of the cost center, if anything other

than "00" will be the 'sub-cost center' that is sent to FMS. IFCAP will not use a 'sub-cost center' field, but will send FMS the last two digits of the cost center as the FMS 'sub-cost center' field, unless the last two digits of the cost center are '00'.

Tasked Job A job, usually a printout, that has been scheduled to run at a predetermined time. Tasked jobs are set up to run without having a person watching over them.

TDA See "Transfer of Disbursing Authority." Total Authorizations The total amount of the authorizations created for the 1358 obligation. Total Liquidations The total amount of the liquidation against the 1358 obligation. Transaction Number The number of the transaction that funded a Control Point (See Budget Analyst User's Guide). It

consists of the Station Number - Fiscal Year - Quarter - Control Point - Sequence Number. Transmission Number A sequential number given to a data string when it is transmitted to the Austin DPC; used for tracking

message traffic. Type Code A set of A&MM codes that provides information concerning the vendor size and type of competition

sought on a purchase order. Vendor file An IFCAP file of vendors solicited by the facility. This file contains ordering and billing addresses,

contract information, FPDS information and telephone numbers. File 440 contains information about the vendors solicited by your station. The debtor's address may be drawn from this file, but is maintained separately. If the desired vendor is not in the file, contact A&MM Service to have it added.

Vendor ID Number The ID number assigned to a vendor by FMS. VRQ FMS Vendor Request document. When users send vendor information to FMS, FMS sends a VRQ

document to IFCAP with the vendor information, ensuring that the information in the IFCAP vendor file matches the information in the FMS vendor table.

IFCAP VISN/Integration Software Requirements Specification ...

Documents

Transcript of IFCAP VISN/Integration Software Requirements Specification ...