Uniform Procurement Instrument Identification (PIID) Implementation Advisory Guideline

Problem Statement:

The Wide Area Workflow (WAWF) eBusiness Suite Applications include the DoD enterprise web-based system that allows secure electronic submission, acceptance and processing of invoices and receiving reports in a real-time paperless environment. The DFARS Clause 252.232-7003 mandates vendors to submit payment requests and receiving reports and supporting documentation electronically via WAWF.

In WAWF to date, a Contract Order, Procurement Instrument Identification Number (PIIN) is required and Delivery Order, Supplementary Procurement Instrument Identification Number (SPIIN), if applicable, is used to uniquely identify a specific delivery under a contract.

The Federal Acquisition Regulation (FAR 4.16) has been amended to implement a Uniform Procurement Instrument Identification (PIID) numbering system to ensure uniformity and consistency of data across Federal agencies. As a result of this FAR change, a new contract number type “Uniform PIID (FAR 4.16)” has been added to all WAWF eBusiness Suite Applications to provide a unique identifier for a specific delivery.

Starting in FY 2016 with WAWF 5.7 it is possible to use a PIID to point to the procurement instrument. For contracts dated 2017 or later, all DoD Procurement instruments will contain a Base Contract Number in the Contract Order field and a PIID in the Delivery Order field. For contracts with all other federal agencies the deadline for implementing this rule is October, 2017.

What this means to Industry…

You may start receiving contracts with a PIID in the Delivery Order field that is 13 to 17 characters long. If your back-end systems do not accommodate this change, you may have to modify your systems.

If your contract contains a number in the delivery order field that is 13-17 characters and position 9 is an “F”, you have received a PIID. You will be required to provide this PIID on all electronic transactions through the WAWF eBusiness Suite. Ideally, DoD wishes to receive the PIID back on all related transactions in the contract number field. However, it is recognized there are benefits to industry to retain the original contract number and it is therefore permitted to retain that value in the contract number field and return the PIID in the delivery order field. DoD will extract the PIID based on the length and presence of “F” in position 9.

If you have a traditional contract and 4-character delivery order number then there is no change to the current process.

References:

Federal Acquisition Regulations System (FAR), Subpart 4.16—UNIQUE PROCUREMENT INSTRUMENT IDENTIFIERS

Defense Federal Acquisition Regulation Supplement, DFARS subpart 204.16—UNIFORM PROCUREMENT INSTRUMENT IDENTIFIERS

Here is what we have been telling vendors.

A) we have an issue on how its stored in EDA so that is causing us some bumps.

B) Uniform PIID is ONLY for Federal Contract like NASA and what not, if you have no federal contracts drop it from your mind.

C) If you want to keep the old contact number in play to keep things "related" if you will then leave the old contract number in the contract number field and put the one with F in the 9th position in the delivery order. If they do not, then use the F-PIDD in the contract number field.

Also user do not know we have PIN SPIN Flip maps depending on what they input.

When the Reference Procurement Instrument field was added to EDA, logic was added to the load script to shift incoming index information when the 9th position of a delivery order was an F. This use to only happen with orders on GSA schedules and other ordering instruments external to the DOD. In those cases, the value that was sent in the Contract field of the index file was shifted to the new Ref_Proc_Inst field and the value in the Delivery_Order field of the index file was shifted to the Contract field.

When the new PIID rules were implemented, the above logic was no longer sufficient as orders against DOD instruments can now have an F in the delivery order as well. It was our (DPAP's) understanding that the EDA program office (all eBusiness systems for that matter) evaluated the new PIID rules to determine their impact upon their respective systems. It looks like the above code was either overlooked or the implementation of the new PIID rules was not fully understood. Please see the attached slides for a more detailed description. You can also look at the following contracts in EDA to see the errant behavior:

Contract FA301017F0005

Contract FA002117F0003

This issue not only effects the scorecards but it also effects any downstream system that consumes EDA index data. As such, it needs to be addressed as expediently as is possible. If additional details are needed or you would like us to explain the issue to the program office team, please let us know.