PROCUREMENT ISSUES REVISED 28 JULY 1987

• Document Type: CREST
• Collection: General CIA Records
• Document Number (FOIA) /ESDN (CREST): CIA-RDP90-00191R000100060024-1
• Release Decision: RIPPUB
• Original Classification: K
• Document Page Count: 9
• Document Creation Date: December 23, 2016
• Document Release Date: October 24, 2013
• Sequence Number: 24
• Publication Date: July 28, 1987
• Content Type: MISC

Declassified in Part - Sanitized Copy Approved for Release 2013/10/24: CIA-RDP90-00191R000100060024-1
STAT
PROCUREMENT ISSUES
Revised
28 July 1987
1. Identifying Buyer's Address to be printed on document. The
capability is there to store additional business addresses, but there is no
identified field on the purchase order to indicate the ADDRESS ID like there
is for the ship-to and bill-to ADDRESS IDs to be document specific. There is
a field on the purchase order header extended to indicate the vendor's mailing
ADDRESS ID and the remit-to ADDRESS ID for document specific.
3. Buyer concerns:
a. On the REQ level, the inability to change the BUYER at line
level by changing BUYER at the HEADER level, instead of a line by line change
even though the entire REQ is being assigned to another buyer. It would seem
that whenever a change was made at a higher level that it would effect the
change to the lower levels, there by giving the ability to change an entire
REQ by one change. The change of a buyer at the line level provides the means
to assign different buyers to specific line items
b. If there is a different BUYER at the HEADER and LINE ITEM
levels, the REQ will appear only in the LINE ITEM'S buyer queue until the PO
is opened.
c. On INQRQRQS screen under BUYER field:
1). If BUYER was input, initials will appear; this is at REQ
HEADER LEVEL.
2). If BUYER field is blank, then nothing was input at the
HEADER LEVEL (this occurs even when a default buyer is defined
at the system level) or a PO has been written.
d. BUYER's ID disappears from REQ screens after PO is created
whenever you rely on the default buyer to populate the buyer field. If the
buyer is input manually on the REQ Header, it does not disappear from the
screen after the PO is opened. So it seems that a default buyer should not be
used because of the disappearance of the Buyer's. With this occurance how
will we be able to tell how many REQs were received by a specific procurement
element during a specific time period (at this point we are not interested in
the number of line items received only the number of REQs by Directorate, by
Office.)
e. Appears that there is no capability for making a global Change
of buyer for several POs. This capability is required because our buyers are
on rotational assignments with the different procurement elements and must be
able to transfer the responsibility for the POs.
- 1 -
Declassified in Part - Sanitized Copy Approved for Release 2013/10/24: CIA-RDP90-00191R000100060024-1
Declassified in Part- Sanitized Copy Approved forRelease2013/10/24 : CIA-RDP90-00191R000100060024-1
f. If there are several Buyers at the line level on a REQ, the REQ
will successfully split into correct Buyer's queue. However, when BLDBYREQ is
done, all line items will appear on that screen whether they belong to the
buyer creating the PO or not. In addition, one Buyer can select an item that
supposedly belongs to another and place it as an order and it will disappear
from the queue. On the BLDBYREQ, if there are multiple buyerss and a buyer
put in at the Header level, the system will assign the Header buyer to the
buyer field. When the default buyer is deleted and no buyer is assigned at
the header level, the system will ask for a buyer code, even though a
selection for a line item was done from a particular buyer's queue. The buyer
that is added at the req header level is the buyer which populates the
BLDBYREQ buyer field, even when a Selection again was made from a particular
buyer's queue. If there is a default buyer assigned and there is no buyer
assigned at the REQ header level, the default buyer will populate the BLDBYREQ
buyer field.
g. When using the BLDBYVEN screen, if more than one REQ is being
used and each REQ has different or no buyers assigned at the header, the
system will use the default buyer, if one is assigned (manual input), or
require the inputter to enter a buyer code. The system brings up all the REQs
that are assigned to the particular vendor. Any buyer can place any or all
the REQs.
QUESTION: If different buyers have REQs with the same vendor
and one buyer is using BLDBYVEN, all the open REQs will appear
on the screen for placement, how can buyer know by looking at
the screen which REQs belong to him? Also all of the REQ will
not be unclassified and there will be different levels of
classifications the for classifed items.
h. Even if all the REQS have the same buyer on the REQ header, no
buyer shows up in the buyer field.
NOTE ON BLDBYVEN SCREEN: This screen does not allow the input
of the unit price. If unit prices are different than that found
on the REQ, the prices must be changed through MODPOITM. If
item is not priced, order may not be opened. There is no
apparent way to tell which item is missing a unit price if the
order has more than one item without going back and looking at
each item individually.
2
Declassified in Part - Sanitized Copy Approved for Release 2013/10/24: CIA-RDP90-00191R000100060024-1
Declassified in Part- Sanitized Copy Approved for Release 2013/10/24: CIA-RDP90-00191R000100060024-1
4. Validation of funds availability, commitments, decommitments, and
obligations functions are in 1.3 Funds Control Federal.
5. Contract financing (1.3 Funds Control Federal")
a. Incremental funding of contract
b. Set-Asides (Funds Limitation)
c. Retaining funds made available at commitment time, the contract
is negotiated for a specific amount, used in A&E contracts
mostly.
6. Funding/financing status at contract level (1.3 Funds Control
Federa177777)
a. Orignial Cost and Fee, orignial total
b. Current Cost and Fee, current total
c. Original Obligation by Project, ORN (Account Key)
d. Current Obligation by Project, ORN (Account Key)
e. Total original Obligation amount
f. Total current obligation amount
g. At base contract level a thru f for the task orders or work
orders issued for the base
h. EXpenses by ORN and total expensed amount.
7. Savings
8. Method of Payment. Each contract needs the flexibility to identify
method of payment as cashier Check, treasury check, or EFT. If EFT is in
effect treasury requires identification of the account, a checking account or
a saving account. Cullinet's EFT has the NCHA number as the transit number -
treasury requires the ABA number.
9. Progress Payments FAR 32.501-3
10. Advance Payments FAR 32.403
11. Withholding Provisions - need a way to convey the contract's
withholding amounts, %, mins, and maxs.
3
Declassified in Part - Sanitized Copy Approved for Release 2013/10/24: CIA-RDP90-00191R000100060024-1
Declassified in Part - Sanitized Copy Approved for Release 2013/10/24: CIA-RDP90-00191R000100060024-1
13. Types of contract
a. Cost type
b. Letter contracts
c. Definitized contracts
13. Payment terms
14. Frieght
15. Overruns
16. Justifications - possible CICA Form Screen.
17. Documentation of the contract - Real word processing.
After extensive testing of the systems text capabilities, the following
results have been found:
1. Text can be copied from one place to another. Standard Clauses can
be set up in UPDPRTXT and can then be copied onto the PO; however,
this can be done only one time for each PO Header, Footer, or Line
and the 4 character field KEY and the ID of the text has to be known
in order to effect the copy. Line item descriptions can also be
copied in order to save retyping.
2. Standard Clauses can be set up in UPDPRTXT and then can be recalled
to the PO Header, Footer, or Line. This is done by entering a "$"
and then the text Key name, i.e. $PP1. Again, however, this process
can be done only one time for each PO Header, Footer, or Line. In
other words you can only add one standard clause per PO.
3. Free form text can be entered in the PO Header, Footer, or Line. The
system allows 12 lines per screen; if more text is required, it can
be added onto the continuing screens. This is done by adding the
NEXT LINE number in the appropriate field.
4. If a standard clause is being recalled using the "$" method, and free
form text is being used, the standard clause will not print out on
the PO.
-4
Declassified in Part - Sanitized Copy Approved for Release 2013/10/24: CIA-RDP90-00191R000100060024-1
Declassified in Part - Sanitized Copy Approved for Release 2013/10/24: CIA-RDP90-00191R000100060024-1
CONCLUSIONS: At this point, the system does not offer appropriate text
functionality for Procurement Division. Procurement uses
too many standard clauses and free form text on thier POs
and Contracts to make this process on Cullinet's system
efficient. Procurement may have to return to the use of
"boiler-plate" clauses and attached them to each PO as
appropriate.
The Team does know that Cullinet is enhancing their
"Workbench" software package which includes wordprocessing
processes that can be used in conjunction with the Cullinet
Purchasing Package. This package will be looked at and
reviewed by the Purchasing Team when it becomes availabele.
18. Amendments - The printed copy of the CHANGE ORDER did not printed the
19. CSAD Audit Function.
CSAD is primarily concerned with the financial status and audit of
costs incurred by commercial and educational entities who are
receipients of contracts under the Agency's procurement program.
CSAD supports all of the Agency's procurement elements.
AUDIT FUNCTIONS:
1. Preaward Audits
a. Survey and evaluations of accounting system
b. Financial capabilities studies
c. Review administrative policies
d. Reveiw property controls
e. Survey of estimating systems
2. Detailed analysis of Cost Proposals
a. Direct Labor (hours and rates)
b. Direct material
c. Direct travel
d. Sub-contracts
e. Indirect expenses
f. Other direct costs
g. Profit
5
Declassified in Part - Sanitized Copy Approved for Release 2013/10/24: CIA-RDP90-00191R000100060024-1
Declassified in Part - Sanitized Copy Approved for Release 2013/10/24: CIA-RDP90-00191R000100060024-1
3. Participate as advisor in contract negotitations
4. Provide financial and account advice to contracting
personnel
5. Obtain forward pricing information from Defense Contract
Audit Agency (DCPA).
B. Post Award Audit (intirm and final)
1. There are basically nine different types (with
variations and combinations) of contracts that are
subject to audit by CSAD: FFP/LOE, FPR, FPI, CR, CS,
CPFF, CPOF, CPAF, and T&M.
2. The audit of the above types of contracts consists of
audit of direct costs charges (billed) to the contract.
3. For those contractors that are primarily doing
business with the Agency, CSAD performs the audit of
the Indirect Expense Allocation Rates.
4. Performs a review of DCAA audit determined Indirect
Expense Allocations Rates to insure compatability with
terms of Agency contracts.
5. Performs the audit of non-competitive FFP contracts
under Public Law 87-653 (Truth in Negotiations).
6. Also during the course of audit, CSAD reviews the
contractor's government property control systems and
the list of property furnished or acquired in the
performance of the contract.
c. Data requirement:
Proposal data-Proposal Case Number, Auditor-in-charge,
Contractor, Hours to perform cost analysis, Contract type,
Proposed Amount, and Questioned Amount.
Post Award data-Date contract or amendment received in CSAD,
Date of latest approved Indirect Rates, Tentative Audit Date,
Audit remarks, Audit Case Number (relate to Proposal Case
Number), Audited through date, Amount approved, amount
suspended, amount disapproved, date of audit report, date final
claim and reconciliation statement received from contractor,
date final audit report written, audit address (rot always the
same as the facility address. Show audit deletions even though
contractor concures and refunds or the contracting officer
amends the contract to cover questioned amount.
-6
Declassified in Part - Sanitized Copy Approved for Release 2013/10/24: CIA-RDP90-00191R000100060024-1
Declassified in Part- Sanitized Copy Approved forRelease2013/10/24 : CIA-RDP90-00191R000100060024-1
20. Settlement process for other than FFP contracts
21. Equipment Schedules
22. Government Furnished Equipment
23. Contractor's Plan and Reporting
24. COTR's Inspection Plan and Reporting
25. Type of Product or Service
26. Methods of Procurement.
7
Declassified in Part - Sanitized Copy Approved for Release 2013/10/24: CIA-RDP90-00191R000100060024-1
Declassified in Part - Sanitized Copy Approved for Release 2013/10/24: CIA-RDP90-00191R000100060024-1
Contractor/vendor
20 June 1987
A contractor/vendor is an external contractor (including other government
agencies) with whom the Agency has a current agreement or who has had an
Agency contract in the past. Also, contractors on the bidders list are
included, as well as those vendors that OL/SS has opened for future classifed
association based on a COTR's request. The agreements are for work to be
-performed, products to be delivered, and/or services to be rendered.
The purpose of this file is to record descriptive data about individual
contractors at the "PLANT" level. The corporate headquarters and each plant
are a separate enities, but the affiliation is there to produce reports in
summary or on individual basis. Additionally, there are codes to indicate
corporation megers of more than one company into another one or the formation
of a new company by one or more existing companies. Some of the data for a
vendor is the date of secrecy agreement, date of 441, FOCI eligibility, PN85
data, date and authorization of property procedures, Contractor's FY ending
date, tentative date contractor is scheduled to be audited, if the contractor
has complied with Cost Accounting Standards, the many mailing addresses of the
vendor, audit address, and remit-to address, etc.
Requires a program capability to retrieve, via remote terminal or in
printed reports, the total history of an agreement, a contract, and/or a
contractor. Total history would include basic data (selected in total, or in
a combination of selected data elements appropriate to a particular
information requirement) concerning an agreement or contract and all of the
actions supplemental thereto. The flexibility of this capability should be
such that a complete history of business with a given contractor also can be
retrieved when desired. Printed reports would be requested on an "as
required" basis.
-2
Declassified in Part - Sanitized Copy Approved for Release 2013/10/24: CIA-RDP90-00191R000100060024-1
Declassified in Part - Sanitized Copy Approved for Release 2013/10/24: CIA-RDP90-00191R000100060024-1
The matching function in 1.2 is at the vendor level, therefore each vendor
can only have one type of matching. This would mean the number of vendors
would be multipled by 4. Another concerns is that of convey additional
information with the type of matching.
Progress Payments - 2-way matching, but the signature of the
contractor officer is required.
Service Contracts - 2-way matching, approval of first and last
invoices by component B&F Office required.
Cost Type Contracts - 2-way matching, approval of all invoices - or
as determined by the contracting officer.
Certificate of Conformance - 2-way matching, with a certificate of
conformance
Fast Pay - 2-way matching, need P.O. and Invoice
Purchase Orders - 3-way matching, need P.O., Invoice, and
Verification of receiving.
Inspection - 4-way matching, need P.O., Invoice Verfication of
receiving, and T&I.
Payment process is at the vendor level not contract level.
-3
Declassified in Part - Sanitized Copy Approved for Release 2013/10/24: CIA-RDP90-00191R000100060024-1