STOS logo WeBOC EDI integration for terminals, off dock facilities and CFS operators

WeBOC Integration: Terminal EDI with Pakistan Customs

WeBOC is Pakistan Customs Web Based One Customs, the national clearance platform. WeBOC integration software lets a terminal report gate, yard and cargo events to Customs automatically as they happen, instead of a documentation clerk re-keying every movement. This page sets out exactly which events are reportable, the EDI messages behind them, and what an integration project involves.

Request a Demo Explore STOS
Customs EDI ● Connected
Gate In reported
Acknowledged
Grounding position
Acknowledged
De-stuffing tally
Queued
Gate Out reported
Acknowledged
The short answer

What WeBOC integration actually means

A terminal is a reporting party. Customs needs to know where a consignment physically is, and the terminal is the only party that knows. WeBOC EDI integration is the mechanism for telling it.

Outbound: what the terminal tells Customs

Every physical milestone in the terminal produces a customs event. In STOS these are generated by the operational screen the clerk is already using, so reporting is a by-product of the work rather than a second job.

  • Gate in of the container or the cargo
  • Grounding and the yard position it was placed in
  • De-stuffing, with tally sheet and per index detail
  • Stuffing and service completion on the export side
  • Gate out against the gate pass
  • Transhipment detail: bonded carrier, seal, port of exit

Inbound: what Customs tells the terminal

Integration is two directional. A large part of the value is that the terminal stops creating records by hand, because Customs has already declared them.

  • Vessel arrival and the IGM or VIR for the call
  • Index level detail: BL, packages, weight, seal, line
  • Handling codes, for example examination
  • Release and examination completion status
  • Export cargo arrival notified against a Goods Declaration
Message timing

Which message flows when

The sequence below is the STOS operational flow. Every step marked as reported produces an automatic EDI message to Customs at the moment the operational screen is completed.

Import: CFS and CY

  1. Inbound

    Vessel arrival and indexes

    The vessel arrival comes from Customs. Containers and indexes are created from it with BL, packages, weight, seal and line already populated, and any handling code such as examination is attached.

  2. Reported

    Gate In

    The container physically enters the terminal and the gate in is reported to Customs. This is the point at which the consignment becomes the responsibility of the facility.

  3. Reported

    Grounding

    The container is placed in a yard slot and the yard position is reported. Customs can then locate the box for examination without asking the terminal.

  4. Reported

    De-stuffing (CFS only)

    Cargo is stripped out of the container and the tally sheet plus per index detail is reported. CY containers skip this step entirely and move as a single box.

  5. Local

    Empty gate out and weighment

    The emptied container returns to the shipping line and weights and CBM are captured for the cargo. The empty movement is what a shipping line expects to see as a CODECO message.

  6. Inbound

    Release or examination complete

    Customs releases the consignment. The Delivery Order arrives from the shipping line and the terminal raises the invoice for storage, handling, port and any special handling.

  7. Reported

    Gate Pass and Gate Out

    The gate pass is issued and the gate out is reported to Customs, closing the consignment as far as the terminal is concerned.

Export

  1. Local

    Loading Program created

    The export plan is built first: vessel, voyage, port, commodity and expected packages. Everything downstream is worked against it.

  2. Inbound

    Cargo arrival against a GD

    Customs notifies cargo arrival against a Goods Declaration and the Loading Program updates itself. This is the clearest example of integration removing data entry rather than adding it.

  3. Reported

    Entering Cargo

    Cargo physically enters the terminal and the gate in is reported. Cargo received is then measured and weighed, and grounded cargo records the alongside position.

  4. Local

    Container creation and GD association

    The export container is created and the GD association records which Goods Declaration goes into which box. Getting this association right is what makes the stuffing report meaningful.

  5. Reported

    Stuffing and service completion

    Stuffing and service completion are reported to Customs. The export invoice covering tariff and storage follows.

  6. Reported

    Delivery Order, Gate Pass, Gate Out

    The container leaves the gate, the terminal receipt is printed and the movement is closed out.

EDI messages

The message types STOS exchanges

STOS exchanges EDI messages with Customs, shipping lines and other partners so that terminal events are reported automatically instead of being re-keyed.

OPIA

A terminal EDI message exchanged as part of the export flow.

OGDE

A Goods Declaration related EDI exchange. The GD is the key the whole export side is organised around.

OEHC

A terminal EDI message exchanged as part of the export flow.

Further message codes appear in STOS terminal EDI configuration. Which of them are enabled depends on the facility, the cargo types it handles and the profile agreed with Customs, so treat this as an index of what STOS is built to carry rather than a specification of any one terminal.

OGTE OGIE OGDE SVMO PGOO SIMO CCMO SCMO TTSO GTTO

Alongside Customs, the same messaging layer connects the terminal to shipping lines and other partners, including Maersk, Hapag Lloyd, CODECO gate movements, weighbridge systems and PCS PSW. Your onboarding specialist confirms the exact connection details for your terminal.

Operational reality

What the terminal is responsible for

Integration does not move responsibility. It moves effort. These are the things that stay with the terminal, and the things a good WeBOC integrated TOS should take off the desk.

Timeliness

A gate in reported hours after the truck came through is a data quality problem, not a record. Events should be generated by the operational screen at the moment of the movement, which is why reporting belongs inside the TOS rather than in a separate customs client.

Accuracy of the index

IGM plus index number uniquely identifies a consignment on the import side, and the GD number keys the export side. If those references drift, every downstream message drifts with them, so they are the fields worth validating hardest.

Failure handling

Failed messages queue for retry rather than disappearing, and each partner has an integration status panel. The rule that matters operationally: read the EDI log before resending anything by hand, or you create a duplicate at Customs.

Credentials

Most integration failures are not format problems. They are connectivity or expired credentials. Whoever owns the customs connection needs a diary entry for renewal, not a surprise at the gate on a Friday afternoon.

Specification drift

Partners occasionally update their EDI specification. If messages start failing after a long period of working correctly, confirm the partner has not changed the expected format before assuming the terminal is at fault.

A named owner

Terminals that run integration well have a documentation and EDI officer who owns the message log, re-processing and the customs IGM detail as a defined role, with permissions to match. Terminals that run it badly have nobody.

Delivery

What a WeBOC integration project involves

The technical connection is rarely the hard part. Agreeing what a terminal event means, and making the operational screens produce it reliably, is the work.

1

Scope the facility

CY, CFS, transhipment, break bulk or a mix. Cargo type decides which events exist at all, and CFS carries the heaviest reporting because cargo is tracked at index level after de-stuffing.

2

Map events to messages

Each operational screen is mapped to the message it should raise and the fields that message needs. This is where gaps in current practice surface, usually around examination handling and transhipment.

3

Establish the connection

Connection details and credentials are agreed with Customs and configured for the facility. Partner connections for shipping lines and the weighbridge are set up alongside.

4

Test both directions

Outbound reporting is verified against acknowledgements, and inbound vessel, index and release notifications are checked to confirm records are created correctly without manual entry.

5

Train the EDI officer

The message log, re-processing and file download screens are the day to day tools. The duplicate risk on manual resend is the single most important thing to teach.

6

Run and monitor

The integration status panel becomes part of the daily start of shift check, in the same way the yard and gate dashboards are.

Where this is heading

WeBOC, PSW and PortVerse

Pakistan Single Window is taking over WeBOC functions in phases, and PortVerse is the Port Community System developed by Pakistan Single Window. For a terminal this means running against more than one channel for a period, while the underlying operational events stay exactly the same.

Pakistan Single Window

How PSW integration works for a terminal, what changes relative to WeBOC, and why the operational event model is the part worth protecting.

PSW integration

PortVerse and the PCS

What a Port Community System changes for terminals, shipping lines and clearing agents, and where the terminal operating system sits in that picture.

PortVerse integration

STOS

The Smart Terminal Operating System behind all of this: cargo, gate, shed and examinations, financial and analytics modules for Pakistani and international terminals.

Explore STOS
FAQ

WeBOC integration questions

WeBOC is Pakistan Customs Web Based One Customs, the national customs clearance platform. WeBOC integration for a terminal means the terminal operating system reports operational events to Customs electronically as they happen, instead of staff re-keying them into a customs portal. Gate in, grounding, de-stuffing detail, stuffing and service completion, and gate out are all reported by EDI message, and inbound notifications from Customs update terminal records in return.

On the import side the reportable events are gate in, grounding or yard position, de-stuffing detail including the tally sheet and per index breakdown for CFS cargo, and gate out. On the export side the terminal reports cargo entering the gate, stuffing and service completion, and the final gate out against the Goods Declaration. Transhipment movements additionally report the bonded carrier, seal number and port of exit.

STOS exchanges terminal EDI messages with Customs across the import and export flows. OPIA and OEHC are terminal EDI messages exchanged as part of the export flow, and OGDE is a Goods Declaration related exchange. Further message codes including OGTE, OGIE, SVMO, PGOO, SIMO, CCMO, SCMO, TTSO and GTTO appear in STOS terminal EDI configuration. The exact set enabled depends on the terminal and is confirmed during onboarding.

Yes. Off dock terminals, container freight stations and container yards all carry the same reporting obligation as a quay side facility, and in the CFS case the reporting is more detailed because cargo is de-stuffed and delivered piecemeal, so the tally sheet and per index detail are reported rather than a single container movement. STOS handles CY, CFS, transhipment and break bulk in the same system.

Failed messages are queued for retry rather than lost, and each partner connection has an integration status panel. Most failures are connectivity problems or expired credentials. The EDI log should be checked before anything is resent by hand, because resending a message that actually reached Customs creates a duplicate. If messages start failing after working correctly for a long time, the usual cause is a change to the partner EDI specification.

Pakistan Single Window is the national trade single window and is taking over WeBOC functions in phases, so terminals should expect to operate against both for a period rather than switching overnight. The practical implication for a terminal operating system is that the underlying operational events do not change, only the channel they are reported through, so an integration layer that separates terminal events from partner transport is what makes the transition manageable. See our PSW integration page for the detail.

Talk to us about your customs integration

STOS is a terminal operating system built in Karachi for Pakistani port and terminal operations, with customs EDI integration as a core part of the platform rather than an add on.

Request a Demo Explore STOS