04_USC-9_PWS_Att_1_EDI.pdf
PDF 53 KB Posted
- Attached to
- Universal Service Contract (USC)-9 Federal contract opportunity
- Solicitation number
- HTC71119RW001
About this file
This document includes a draft Performance Work Statement (PWS) for the Universal Service Contract 9 (USC-9) opportunity. The PWS requires transportation and logistics services including shipment tracking and reporting through Electronic Data Interchange (EDI) using specific transaction codes to document events like container pickup, loading onto vessels, arrival and departure at ports, delivery, and empty container returns. Required reports include load acceptance, in-gate, loaded on vessel, vessel departure, arrival, discharge, out-gate, delivery, and container return transaction sets submitted within 24 hours of each event. Additional transaction codes are specified for tracking cargo moving through staging areas, delays, and exceptions. The Department of Defense United States Transportation Command is seeking feedback on the draft PWS by August 3, 2018 to finalize requirements for the USC-9 contract award.
Draft USC-9 Attachment 1 with track changes
View the file
Other files for this federal contract opportunity
Show all 50
Universal Service Contract (USC)-9 has more files on GovTribe.
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Universal Service Contract - 9 Exhibit 3, Performance Work Statement, Attachment 1
Electronic / EDI Reporting
Shipment Status Reporting: The Contractor shall provide accurate shipment status reports using the Electronic Data Interchange (EDI) 315 transaction sets. Transaction sets shall be submitted in accordance with the Department of Defense (DoD) Transportation Electronic Business (DTEB) Implementation Convention (IC) ANSI X-12 EDI standard or via IBS Ocean Carrier Interface to SDDC. Table 1 identifies specific events that require reporting. The Contractor shall submit all reports within 24 hours of accomplishment.
Table 1 of Reportable Shipment Status Events
CODE DEFINITION NOTES
EE Empty spottedSpotted The transaction is required for all carrier owned containers spotted at locations other than container pool locations. Container pPick up of Loaded Container in lieu of actual Empty spot Spotted is acceptable for shippers having container pools. Required for other than pool locations.
(NOT REQUIRED FOR BREAKBULK)
W Pickup of Loaded Container/Breakbulk
This transaction is required at the time customer turns over possession to Contractor. This transaction is only applicable upon Contractor pick-
up. There shall be exactly one W transaction per shipment. If erroneous W transactions are submitted, contractor shall invalidate them via the Pipeline Asset Tool (PAT) EDI invalidator tool to ensure only one valid transaction is reflected per shipment.
I In-gate at Port of Embarkation (POE)
This transaction is required at the POE. This transaction is only applicable at the POE. There shall be exactly one (1) transaction per shipment. If erroneous I transactions are submitted, contractor shall invalidate them via the Pipeline Asset Tool (PAT) EDI invalidator tool to ensure only one valid transaction is reflected per shipment.
AE Loaded on Vessel This transaction is required at the POE and required at all transshipment ports.
VD Vessel Departure This transaction is required at POE and required at all transshipment ports.
VA Vessel Arrival This transaction is required at the Port of Debarkation (POD) and required at all transshipment ports.
UV Vessel Discharge This transaction is required at the POD and required at all transshipment ports.
OA Out-gate from POD This transaction is required at the final POD for all cargo, regardless of whether booked to port or to door. This transaction is only applicable at the POD. Only one OA transaction is permitted per shipment. If erroneous OA transactions are submitted, contractor shall invalidate them via the Pipeline Asset Tool (PAT) EDI invalidator tool to ensure only one valid transaction is reflected per shipment.
X6 Waypoint This transaction is required when the Daily ITV accessorial is ordered and cargo is transiting the Northern Distribution Network and Pakistan Ground Line of communications (PAKGLOC). This transaction will be auto-generated based on Contractor date input to the Carrier In Transit Visibility Entry Tool (CIET) to document a shipment passing specified waypoints along the route.
AV Cargo Booked to- Door Available for Delivery (Applicable to Exigency areas only; Optional Transaction)
For Exigency Areas only, and only for bookings to-door; the Contractor may submit an AV request upon entering in line outside the final destination gate to document accrual of driver wait time, if applicable.
AV, for these locations only, is valid only if submitted prior to RDD for metric purposes.
EC Return of Empty Container to Contractor Prior to Delivery (X1)
This transaction is required for container shipments when the Contractor has regained possession of its asset prior to delivery (X1). An example of the proper use of an EC Code would be when cargo is deconsolidated at a transship point, the container is returned to the Contractor prior to X1, and the cargo is moved as pallet loads to the final consignee. Each container shipment container return event shall be documented with either an RD or an EC but never both.
(NOT REQUIRED FOR BREAKBULK)
X1 Delivery to Consignee
For door bookings, this transaction is required when the shipment is delivered to the customer. For port bookings, the X1 is required when the Contractor releases the cargo to the Government. There shall be exactly one X1 transaction per shipment. If erroneous X1 transactions are submitted, contractor shall invalidate them via the Pipeline Asset Tool (PAT) EDI invalidator tool to ensure only one valid transaction is reflected per shipment.
RA Carrier Notified Empty Container Available for Pick-up
This transaction will be auto-generated via PAT to document U.S.
Government notification to the Contractor that an empty container is available for pick-up. This transaction will be auto-generated based on the date of notification, if the Contractor does not dispute availability within seven (7) days of notification.
(NOT REQUIRED FOR BREAKBULK)
RD
Return of Empty Container to Contractor After Delivery (X1)
This transaction is required for every container shipment when the contractor regains possession of its asset after delivery (X1). Each container shipment container return event shall be documented with either an RD or an EC but never both.
(NOT REQUIRED FOR BREAKBULK)
HG Entry into U.S.
Government-directed Staging
This transaction will be auto-generated based on the date input to the PAT Delay Request and Authorization Portal (D-RAP) after receiving and executing U.S. Government direction to stage a shipment, to include staging at ports or holding yards. The transaction will be auto-generated based on the date the shipment entered into staging for Holding Yard staging, or date approved by OO for Port Staging.
HR Release from U.S.
Government-directed Staging
This transaction will be auto-generated based on Contractor date input to the D-RAP after receiving U.S. Government direction to end staging of a shipment, to include staging at ports or holding yards. The transaction will be auto-generated based on the date the shipment exited staging. Staging ends on the date indicated in the End Staging order (or as approved by OO for port staging), or when cargo physically departs the Staging location, whichever is earlier.
SD Authorized Shipment Delay (Not Government-caused)
This transaction will be auto-generated upon approval of a Contractor requested delay submitted via the D-RAP. This transaction will be triggered for delays which are not caused by either the U.S. Government or Host Government.
BD End of Authorized Shipment Delay (Not Government-caused)
This transaction will be auto-generated upon U.S. Government approval of a Contractor request to end a shipment delay submitted via the D- RAP. This transaction will be triggered for delays which are not caused by the U.S. Government or Host Government.
A1 Authorized Shipment Delay (Government –Caused)
This transaction will be auto-generated upon U.S. Government approval of a Contractor requested delay submitted via the D-RAP. This transaction will be triggered for delays which are caused by either the U.S. Government or Host Government.
A2 End of Authorized Shipment Delay
This transaction will be auto-generated upon U.S. Government approval of a Contractor request to end a shipment delay submitted via the D-
(Government-caused)
RAP. This transaction will be triggered for delays which are caused by the either the U.S. Government or Host Government.
Additional Rules for AV Transactions for cargo booked to door
AV transactions for cargo booked to door are permitted for Exigency Areas only.
AV is a required transaction to document accrual of driver wait time. AV may only be requested upon entering in line outside the gate at final destination. There are no other acceptable uses of AV for cargo booked to door. In the event that an AV transaction is not requested, the Government will assess that driver wait time was not incurred at final destination for the associated shipment. AV transactions submitted for these locations will be considered in measuring RDD compliance.
Once AV has been submitted, the contractor may not request a delay for that cargo. Staging direction may occur after AV has been submitted, which must be initiated by the Government.
Additional Rules for HG/HR Transactions
HG and HR transactions: The HG and HR transactions will be auto-generated by the D-RAP to indicate entry into and release from Government-directed staging. Authority for staging is the cognizant SDDC Ordering Officer
(OO).
HG: Following receipt of a written Government staging request to move cargo to a non-port staging location via the D-RAP, the Contractor will execute movement of the shipment to the staging location. Up to 14 days after entry into the staging location, the Contractor will input the date of entry to the staging location into the D-RAP. As a result of the date input into the D-RAP, the HG transaction will be auto-generated and distributed. The HG event date for non-port staging entry will be the date inputted by the Contractor into D-RAP. For port staging, the Contractor will request port staging entry via the D-RAP including a requested start date. The Ordering Officer (OO) will review the request and either approve, approve with a modified date or reject it. If approved, the date approved will be the event date of the HG transaction.
HR: Following receipt of a written Government staging release order via the D-RAP to move cargo from a non-port staging location, the Contractor will execute movement of the shipment from the staging location. Up to 14 days of departure from the non-port staging location, the Contractor will input the date of departure from the staging location into the D-RAP. The HR event date, auto generated by the D-RAP, will be the earlier of the cognizant SDDC OO’s staging release date identified in the staging release order and the date of departure inputted into the D- RAP indicating actual departure from the staging location. Cargo must commence dispatch from staging within required timelines outlined in Section 3 paragraph 9.J of the Performance Work Statement (or, if applicable, in the Exigency Annex) upon receipt of written Government request. For large volumes of cargo, contractor will be responsible for managing dispatch in the most expeditious manner. Contractor will provide dispatch timelines to cognizant Battalions and COR until cargo has dispatched from staging area. For port staging, the Contractor will, based on input from the Government (typically OO or consignee) originate the port staging end request via the D- RAP including a requested end date. The cognizant SDDC OO will review the request and either approve, approve with a modified date or reject it. If approved, the date approved will be the event date of the HR transaction.
The HG/HR transaction pair, generated via the D-RAP, will recommit the Contractor to a new delivery date defined as: RDD + (# days elapsed between HG and HR). For a shipment RDD to be extended, both an HG and HR transaction must be generated.
For non-port staging (e.g. holding yards), if an onward movement EDI is submitted by the Contractor for staged shipments prior to the cognizant SDDC OO directing staging release in the D-RAP, the shipments will queue for auto-closing in the D-RAP. If staging release is not directed by the cognizant SDDC OO within 96 hours of the queuing of the shipment record for auto-closing, an HR transaction ending the non-port staging will be auto-triggered by the D-RAP. The HR event date will equal the event date of the onward movement EDI and the RDD will be extended accordingly.
For port staging, if an onward movement EDI is submitted by the Contractor for staged shipments prior to requesting staging release in the D-RAP, the shipments will queue for auto-closing in the D-RAP. If a staging release request is not submitted by the Contractor within 96 hours of the queuing of the shipment record for auto-closing, an HR transaction ending the port staging will be auto-triggered by the D-RAP. The HR event date will equal the event date of the HG transaction and the RDD will not be extended.
Additional Rules for SD/BD/A1/A2 Transactions
SD, BD, A1 and A2 transactions: The SD, BD, A1 and A2 transactions will be auto-generated by the D-RAP based on Government approval to indicate start or end of an authorized delay. These transactions will be auto-generated only upon authorization from the cognizant SDDC OO.
SD and A1: The Contractor shall submit a request for an authorized delay to the cognizant SDDC OO via the D- RAP within 2 10 business days of the event causing the delay. The SDDC OO has 4 10 business days to respond to the request from the Contractor via the D-RAP.
Following Government authorization of a Contractor’s request for delay via the D-RAP, the SD or A1 transaction will be auto-generated and distributed. If an authorization is not processed by the cognizant SDDC OO in the D- RAP within 4 10 business days, the SD or A1 transaction will be auto-generated and distributed. The Contractor must submit supporting documentation with the delay request submitted via the D-RAP. The OO may deny the delay authorization if supporting documentation with adequate justification is not provided.
BD and A2: The Contractor shall submit a request to end the authorized delay via the D-RAP with supporting documentation. Following Government authorization of a Contractor’s delay end via the D-RAP, the BD or A2 transaction, as applicable, will be auto-generated and distributed. If the SDDC OO determines that the Contractor’s reporting of the delay duration is inflated, the delay authorization may be voided.
The SD/BD and A1/A2 transaction pairs generated via the D-RAP will not recommit the Contractor to a new delivery date defined as: RDD + (# days elapsed from SD/A1 to BD/A2). For a shipment RDD to be extended, both an SD and BD or A1 and A2 transactions must be authorized and generated via the D-RAPthe Contractor must submit required documentation via CPP.
For all delays, if an onward movement EDI is submitted by the Contractor, prior to the Contractor requesting an end to the delay in D-RAP, the delayed shipments will queue for auto-closing. If an end delay request is not received via D-RAP by the cognizant SDDC OO within 96 hours of the queuing of the shipment record for auto-closing, a BD/A2 transaction ending the delay will be auto-triggered by the D-RAP. The BD/A2 event date will equal the event date of the SD/A1 transaction and the RDD will not be extended.
Government and non-Government delays will be approved, approved with date modification, or denied by the Government OO based on their review of the D-RAP request. The Government OO will not approve a request for a Government caused delay request as a non-Government caused delay. If the Contractor decides to submit a previously denied Government caused delay request as a non-Government caused delay, a new request must be submitted.
File details come from the government source that posted it. Updated .