Definition
Single Window (Customs Single Window, Single Window) refers to enterprises submitting customs declarations, inspection declarations, certificates of origin, licenses, and other data once through a unified platform. Customs, inspection and quarantine, taxation, foreign exchange, and other departments share this data to achieve "one declaration, one inspection, one release," simplifying cross-border trade processes, improving clearance efficiency, and reducing corporate compliance costs. China's international trade "Single Window" already covers the entire process including cargo declaration, transport, manifests, and tax payment.
The Single Window interfaces with WMS, TOS, customs declaration systems, and logistics systems to achieve data interconnection. Logistics trajectory, temperature and humidity, manifest, and other data collected by IoT devices can support customs documents and trade compliance.
Technical Features
The Single Window uses standardized data formats and interfaces, supporting EDI, API, and other connection methods. Bonded warehouses, ports, and cross-border logistics enterprises' WMS and TOS need to interface with the Single Window in real time to enable inbound declaration, outbound verification, manifest transmission, status inquiry, etc. High requirements are placed on network stability, data integrity, and timeliness.
Use Cases
The single window is widely used in scenarios such as cross-border e-commerce, bonded warehouses, ports, TOS, and cross-border logistics. WMS, TOS, and customs systems interface with the single window; logistics data collected by IoT devices can support customs documentation. SimtoLink provides stable networking and dedicated APNs for systems related to cross-border trade, ensuring single window data declaration and trade compliance.
Where an IoT status enters the filing message
In a single-window setting, the IoT SIM does not "file on behalf of the enterprise." It only carries a status that has already happened at a warehouse, a vehicle, or a yard into the enterprise's own system, which then cites it under the filing rules. A track, a weighbridge ticket, a gate movement, and temperature and humidity are supporting evidence. The declaration, the manifest, and the permit are the messages the window accepts. The document number, container number, or waybill number on the evidence must match the shipment about to be filed, and the time must fall inside that shipment's logical range. A temperature curve that does not match the number must not be stuffed into an attachment to fill space. SIM coverage only solves capture at a yard that has no wired network. It does not change the window's requirements for fields, codes, and the moment of filing.
A status returned must keep its source. A container number read at the gate and a container number typed by the driver do not have the same credibility. Mixed into one "already left," they fail to match at write-off. Compared with transport visibility, the window cares whether the document status has closed, not how dense the dots are on the map. However dense the dots, if the manifest is not confirmed, the goods must not be written as already released lawfully. An outage backfill must not rewrite the gate time, or the event falls into the wrong filing batch.
Outbound before the manifest is confirmed
A common mistake is to push an IoT event to the filing side as soon as the warehouse ships. The manifest has not been confirmed yet, and the system forms "goods gone, document not opened." A later supplementary document then shows cargo and documents in the wrong order. The outbound event may stay on the enterprise side first, and be cited only when the corresponding manifest status allows it. Another mistake is to merge several short-haul tracks into one cross-border transport, with no node where the vehicle changed. The window cannot match the means of transport. Each transfer should be its own status, not an early write of the destination coordinate.
A duplicate filing is just as dangerous. If the backfill program sends the same gate event again, and the enterprise system generates another filing from it, that is a repeated business action, not a link retry. The event ID must run through capture and the filing draft. When permit quantity, weight, and the weight accumulated on the IoT side disagree, stop at the difference. Do not change a sensor reading in order to submit once successfully. For acceptance, use one container: generate an outbound while the manifest is unconfirmed, and confirm the enterprise side has not sent a filing outward. After the manifest is confirmed, cite the original outbound time. Replay the same gate event once. The filing draft is still one.
No filing before the manifest is confirmed
An outbound event may stay on the enterprise side first. While the manifest is not confirmed, do not generate an outward filing from it, or the result is goods gone and the document not opened. After confirmation, what is cited is still the original outbound time, not the confirmation time. Replay the same gate event once and the filing draft is still one. The event ID runs through capture and the draft. A transfer or a short haul is its own status. Do not write the destination coordinate onto the first departure in advance.
Do not merge a container number read at the gate and a hand-entered container number into one "already left" with no source. When weight, piece count, and permit quantity disagree, stop at the difference. Do not change a sensor reading to force one successful submit. However dense the track points, they do not replace manifest status. No filing on the first outbound, the original time kept after confirmation, and a replay that does not create a second draft: that is when IoT evidence on the single-window side does not write the sequence backwards.