The numeric PrestaShop primary key of the order ( orders.id_order ). This is the internal reference staff use when opening an order from the list, linking to invoices, or matching API payloads.

The public order reference string (often alphanumeric) shown to customers on confirmations and used for quick visual matching in CRMs—distinct from the numeric ID.

The core “new customer” indicator column (whether the buyer is flagged as new for this shop according to PrestaShop’s rules). Hide it when every row looks the same for your workflow or the badge duplicates information you track elsewhere.

The customer display name (and associated link behaviour from the core grid) for the account that placed the order—typically first name, last name, or configured shop format.

The company / organisation field from the order’s address context when B2B data exists—useful for wholesale; hide on purely B2C storefronts where the column is always empty noise.

The order total paid including tax, as surfaced by the core grid formatter—what the customer was charged for the basket plus shipping/taxes in the shop’s presentation rules.

The human-readable payment method label selected at checkout (e.g. bank wire, card module display name)—mirrors what you see in order detail for the chosen carrier of the payment option.

The current order status name from your configured order states (awaiting payment, shipped, etc.)—the label staff recognise in the workflow, independent of colour badges the theme may add.

The order creation timestamp ( orders.date_add )—when the basket was converted into an order record in the database, used for sorting and SLA-style reading.

The delivery country name resolved through the address / country join used by the core grid—helps with export compliance and carrier zones at a glance.

The multistore shop name for the order’s originating shop context—critical in multistore setups; safe to hide on single-store installs where the column adds no information.

The selected shipping carrier / method label for the order—the same concept you validate in shipping rules and packing station filters.

Projects the email address stored on the customer entity—the same join PrestaShop already uses for the grid query. Suited to B2B teams pasting the address into CRM or helpdesk tickets without opening the customer sheet.

The city field from the delivery address alias. Pair with postcode when the country column alone is not granular enough for dispatch or courier routing.

Postal or ZIP code from the delivery address—what label tools and courier APIs usually need beside the customer name.

Counts how many order_detail rows belong to the order = number of distinct SKU lines, not the sum of quantities—useful to spot multi-line baskets vs single-line checkouts.

Localised product name for the earliest order_detail row (sorted by line ID). Helps when the reference column is cryptic but you still need to know which hero SKU triggered the sale.

Approximates shipped mass by summing each line’s quantity × parent product.weight. Combination weights are not expanded—treat the figure as indicative, not legal-for-carrier billing. The UI formats kilograms to three decimals when the raw sum is greater than zero.

Up to 140 characters from the newest customer_message linked to a customer_thread that references the order. HTML is stripped and entities escaped so pasted markup from the contact form cannot break the grid.

The technical orders.module value—the same machine identifier you see under Modules > Payment. Ideal for reconciling captures or comparing gateway adoption.

Full 24-hour periods between orders.date_add and database “now” via TIMESTAMPDIFF—handy for SLA views or chasing unpaid bank transfers.

Human-readable label derived from customer.is_guest after hydration—separates registered accounts from guest checkouts for segmentation without opening the customer card.

Surfaces invoice_number already present in the core order dataset—finance can read the fiscal sequence next to the reference without exporting spreadsheets (field empty until an invoice exists).

Mirrors delivery_number from the order row—correlate packing slips or paperless dispatch IDs with list rows without drilling into each order.

Currency iso_code from the existing currency join (e.g. EUR, USD, PLN). In multicurrency shops you can mentally flag which rows need FX reconciliation when the symbol is not part of the default grid template.

Aggregates localised names of every cart rule persisted on the order (catalog rules, vouchers, free-shipping promos, etc.). Values are DISTINCT and sorted alphabetically for predictable reading in one cell.