1__USC-9_PWS_Att_1_EDI_DRAFT.pdf

DRAFT

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 spotted Container pick up in lieu of actual spot 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

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

Contractor Prior to Delivery (X1) 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 used only in Exigency Areas. 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 used only in Exigency Areas. 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 in Exigency Areas. 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 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 10 business days of the event causing the delay. The SDDC OO has 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 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. For a shipment RDD to be extended, the 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, 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.