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
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.
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:
The requested product will allow:
| 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 |
A Glossary of IFCAP terms is provided in Section 6.
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.
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.
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.
This product will make use of MailMan and TCP/IP.
There are no memory constraints.
There are no special operations.
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
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.
Other issues affecting this functionality:
Jerry Napoli (FMS) will look into transferring medical care funds with a request.
Limitations on the developer's options include:
The enhanced printing capabilities will
be developed concurrently and separately from the other features
in this product.
Careful attention should be given to organizing the requirements to maximize readability.
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:
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
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:
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.
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
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.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.
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
Changed to: Multiple Fund Control Points of the Same Appropriation on a Single Purchase Order
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.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.
| 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^AF^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^AC^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' FOR 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^AE^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> D.S-Purch@Long-Beach.VA.GOV 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.
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:
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.
All money and inventory tracking must
adjust correctly. All new functionality must provide an audit
trail for money and non-expendable equipment.
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.
All code will conform to VA SAC and Financial Integrity and portability standards.
There are no further requirements.
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.
This optional section should detail the
revisions made after the SRS has been signed off.
| 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. |