DEV Community

Cover image for A Developer's Guide to TSS Declaration Data Structure
Kristi Hampson
Kristi Hampson

Posted on

A Developer's Guide to TSS Declaration Data Structure

Why This Matters for Engineers

If you are building anything that touches TSS submissions, you are modelling five data groups: parties, goods, customs treatment, transport, and safety & security. Get the schema right up front and the rest of the pipeline is straightforward.

The Data Model

Parties: EORI, importer, exporter, declarant, intermediary. Goods: commodity code, description, quantity, gross and net mass, value, currency, origin, packaging. Customs treatment: procedure, customs value, duty position, preference, reliefs, authorisations, scheme status. Transport: mode, carrier, vehicle, route, port, arrival/departure. Safety & security: consignor, consignee, description, routing.

Consignment vs Item Level

Consignment-level fields describe the shipment. Item-level fields repeat per goods line. A 15-product shipment carries 15 item objects. Model this as a one-to-many, not a flattened row.

Validation Rules Worth Encoding

Gross mass > net mass. Sum of item values equals invoice total. Currency matches invoice. Commodity code exists and is current. Digit count matches goods category. Origin is a country, not "country of despatch".

The prepare customs data for TSS walkthrough sets out each rule in the same shape you would encode it.

Ship the Schema First

Constraints belong in the model, not in the UI. Enforce them at ingestion and you push rejections back to source.

See how validated customs data is produced upstream of the portal. Watch a demo.

Top comments (0)