Logistic Unit
Available only when the Logistic Units feature is enabled.
What is this data
A logistic unit represents a physical packaging unit — a pallet, carton, or case — tracked by a unique identifier. It can be linked to a product and/or production order, and carries a lifecycle status (for example packed, shipped, or blocked). The default pattern used when creating a logistic unit from scanned or printed ZPL data ((?<=\(00\))\d{18}) extracts a GS1 SSCC — an 18-digit Serial Shipping Container Code following the GS1 application identifier (00) — confirming that a logistic unit is the serialized, trackable packaging level in the labeling process.
Where it is used
See Production Data for the coding scenario steps that create, select, and update logistic units.
Fields
| Field | Label | Marked mandatory in UI | Actually enforced on import | Notes |
|---|---|---|---|---|
uniqueId | Unique ID | No | No | Max 255 characters, unique when present. The match key, if supplied (see below). |
noRead | No Read | No | No | |
zplCode | Zebra | No | No | Stored as raw ZPL/label data. |
productionOrder | Production order | No | No | Used to resolve or create the linked production order. |
productCode | Product code | No | No | Used with productVariant to resolve or create the linked product. |
productVariant | Product variant | No | Conditional | Rejected if supplied without productCode. |
createdOnLine | Created on line | No | No | Not editable after creation. |
createdOnLineAt | Created on line at | No | No | Not editable after creation. |
modified | Changed at | No | No | Set automatically. |
If the Statuses feature is enabled, a Status field is also available.
Unlike Product, Production Order, and Print Job, nothing on this table is marked mandatory — a logistic unit can be created from very little data. The only rule actually enforced is that productVariant cannot be supplied without productCode.
Matching & updates
If the row supplies a Unique ID, it is used to look up an existing logistic unit; if a match is found, only the columns present in the row are overwritten, other fields keep their current value. If the row has no Unique ID, a new logistic unit is always inserted — no matching is attempted, so it’s possible to accumulate many logistic units with no Unique ID set.
Auto-created related records
If the referenced product or production order doesn’t exist yet, both can be created automatically — this is the deepest cascade of any table: a single Logistic Unit row can silently create a new Product and a new Production Order.
Custom / additional columns
Beyond the fixed fields above, a logistic unit can carry custom columns to describe whatever else your company needs to track about it. Up to 150 custom columns are supported, but note the per-value size is smaller here than on most other tables: up to 255 characters each (versus 3200 on Product, Production Order, and Print Job). Logistic Unit has no relation of its own to Various Data — only Product does (see Various Data).
Exporting this data
Logistic Units are one of only two data types that can be exported. Export uses the same generic mechanism as any database-sourced export: up to 1000 records per export run, with each record exported at most once by a given task. Filtering uses the generic field-filter rules for this table — the “from date” incremental filter and printer filter available for Printer Logs don’t apply here. See Exporting Data for how to set up the export task itself.