Booking Requests through EDI - Process Initiation

The Process

1. MOL receives EDI Booking requests from PCC.NET Customers like GTN and accepts them in the form of ANSI-X12 (300) standard.
2. GEMG (Global EDI Mapping Group) translates these EDI files into application files as per Booking Request (EDI-300) set layout created in the EDI Exchange Setup.
3. The application files are then passed on to the EDI Exchange for processing.
4. During processing of any Booking request, the Booking information is loaded to the respective PCC.NET Booking.
5. After the Booking request is successfully processed and loaded, an e-mail notification is sent to the Booking user. They can then process the Booking request to create the PCC.NET Booking.

Processing Validations

• Booking request process does the following as per status in the element B104:

  • If a Booking request file is received with element “B104 = N” and the alternative Booking number does not exist, the Booking request process will load the Booking information in PCC.NET Booking with Draft status. Also, new Booking e-mail notification will be sent to the users informing that new Booking request got loaded into PCC.NET and user can now edit the Booking and complete the missing information and update the Booking status as Approved.

  • If an incoming file is received with element “B104 = ‘N’” but with the same alternate Booking number which already exists in the PCC.NET Booking with status as Draft, PCC.NET updates the earlier Booking request with the new incoming information. A Booking e-mail is sent to users for the update. If the status is other than “Draft”, PCC.NET only sends a Change Booking request e-mail notification to the users and users need to incorporate the changes manually in the PCC.NET Booking.

  • If an incoming Booking request is received with element “B104 = “U”, that is, Change Booking request, PCC.NET will check the following:

    • If the Booking already exists (in the PCC.NET Create/Update Booking screen) with same alternative Booking number seen from all Booking reference number in the Customer Details panel and Accepted status, PCC.NET only sends a Change Booking request e-mail notification to the users and users need to incorporate the changes manually in the PCC.NET Create/Update Booking screen.

    • But if PCC.NET finds that the earlier Booking request is still in Draft status, PCC.NET updates the earlier Booking request with the new incoming information.

    • If the Alternate Booking number is not found, a new Booking is created in Draft status. An e-mail notification is sent to the users informing that new Booking request has been loaded in PCC.NET, and user can edit the new Booking to complete the missing information and proceed with the Booking creation in Approved status.

If an incoming Booking request is received with element “B104 = ‘D” (that is, a Cancel/Delete Booking request), PCC.NET simply informs the users with e-mail notification that the Booking request needs to be cancelled.

• If the incoming Booking request files comes with VIN Number, it gets loaded into the VIN Tracking (OPBKW08) screen. But before loading the VIN, PCC.NET checks the life cycle of the VIN. If for a particular VIN in a Booking requests violates the life cycle, it does not reject the Booking request, rather PCC.NET loads the valid VINs in PCC.NET VIN Master and during sending the e-mail notification to the user, it mentions details of those invalid VINs which have violated the VIN life cycle.

• PCC.NET tries to get the 7-character location code based on the UN code for LP/DP/PR/PD.

  • For incoming LP/DP, PCC.NET first tries to get the 7-character PCC.NET location code based on the Vessel Schedule and Location master, if the Vessel code is derived from Lloyd’s code and Voyage code is available. If the incoming code is UN code, Location Master (RFLCW10) is checked on the basis of UN code. But if the location code is schedule K code, it is searched based on the Location Master (RFLCW10) schedule K code.

  • If the Vessel code is not derived or the Voyage code is not present in the file, PCC.NET directly checks the Location Master (RFLCW10) screen and if it gets a distinct 5-character location code.

  • GTN sends the Lloyds code in V1 segment.

• Since the entire Booking route information is not retrieved in the EDI file, while creating the Booking, the Booking route must be created as per available Vessel Schedule in PCC.NET.

• Booking request loading e-mail routing logic: Following is the detail routing logic of Booking request e-mail notification:

  • Process checks for the Customer codes (H04 Customer Code) present in the Booking request that matches with the Customer codes registered in the PCC.NET e-mail infrastructure) in the following order of priority (H04 Customer Qualifier):

    • Initiator’s Customer Code (BK)
    • Forwarder’s Customer Code (FW)
    • Shipper’s Customer Code (SH)

  • If matching Initiator Customer Code is found, PCC.NET first considers e-mail address of that Customer, else checks Forwarder, and so on in the order given above.

  • This logic is only applicable if the Customer codes are retrieved in the EDI 300 files.