Numeryczny klucz główny zamówienia w PrestaShop ( orders.id_order ) — to, po czym ludzie zwykle otwierają zamówienie z listy, łączą faktury albo kleją do integracji API.

Publiczny „kod” zamówienia (często literki i cyfry), który klient widzi na potwierdzeniach — w CRM-ach łatwiej go skleić wzrokiem niż sam numer ID.

Rdzeniowa kolumna „czy to nowy klient” według reguł PrestaShop. Jak u Ciebie i tak nic z tego nie wynika albo macie to gdzie indziej — spokojnie można ją schować.

Wyświetlana nazwa konta, które złożyło zamówienie (zachowanie linku jak w rdzeniowej siatce) — zwykle imię i nazwisko albo format, który ustawiłeś w sklepie.

Nazwa firmy z kontekstu adresu, jak masz B2B. Na czystym B2C często wisi pusto — wtedy kolumna tylko zajmuje miejsce.

Kwota zapłacona z podatkiem, tak jak formatuje ją rdzeniowa siatka — czyli to, co klient faktycznie zapłacił za koszyk, wysyłkę i podatki według reguł sklepu.

Czytelna nazwa metody płatności z checkoutu (przelew, karta, „jak się modułowi wyświetli”) — to samo, co zwykle widzisz w szczegółach zamówienia przy wybranej opcji płatności.

Aktualna nazwa statusu z Twoich stanów zamówienia (oczekuje na płatność, wysłane itd.) — chodzi o etykietę, po której ludzie się poruszają, niezależnie od kolorowych badge’y z motywu.

Moment utworzenia zamówienia ( orders.date_add ) — kiedy koszyk zamienił się w rekord w bazie; pod sortowanie i szybkie oko pod SLA.

Nazwa kraju dostawy z tego samego joinu adres / kraj, co w rdzeniu — przydatne przy eksporcie, strefach przewoźnika albo szybkim rzucie okiem na „dokąd jedzie paczka”.

Nazwa sklepu w kontekście multisklepu — przy wielu frontach to must have; przy jednym sklepie często tylko szum w nagłówku tabeli.

Wybrany sposób / przewoźnik wysyłki — to samo, co później filtrujesz przy regułach wysyłki albo na linii pakowania.

Adres z encji klienta — ten sam join, którego Presta i tak używa przy siatce. B2B wkleja go od razu do CRM albo ticketu, zamiast otwierać kartę klienta.

Pole city z aliasu adresu dostawy. Dorzuć obok kod pocztowy, jak sam kraj to za mało do magazynu albo kuriera.

Kod z adresu dostawy — zwykle obok nazwiska musi być na etykiecie albo w API przewoźnika.

Ile wierszy w order_detail należy do zamówienia = ile osobnych linii SKU, a nie suma sztuk — od razu widać, czy ktoś kupił „paczkę” pozycji, czy pojedynczy strzał.

Zlokalizowana nazwa dla najwcześniejszej linii order_detail (po ID linii). Jak referencja nic nie mówi, tu przynajmniej widać, „co poszło pierwsze”.

Masa z grubsza: suma ilości × waga rodzica z product.weight. Wag kombinacji się nie rozwija — traktuj to jako orientację, nie dokument rozliczeniowy u przewoźnika. Interfejs pokazuje kg z trzema miejscami po przecinku, jak suma > 0.

Do 140 znaków z najnowszego customer_message powiązanego z customer_thread od tego zamówienia. HTML leci w kosz, encje są escapowane — jak ktoś wkleił śmieci z formularza kontaktu, siatka dalej stoi.

Techniczna wartość orders.module — ten sam „maszynowy” identyfikator co pod Moduły → Płatność. Przydaje się przy rozliczaniu autoryzacji albo gdy porównujesz, która bramka realnie zbiera zamówienia.

Pełne doby między orders.date_add a „teraz” z bazy przez TIMESTAMPDIFF — pod SLA albo podganianie nieopłaconych przelewów.

Czytelna etykieta z customer.is_guest po zassaniu danych — od razu widać gościa vs konto, bez wchodzenia w profil klienta.

invoice_number z zestawu danych, który i tak idzie z rdzenia — księgowość ma numer obok referencji bez eksportu do arkusza (pusto, dopóki faktury nie ma).

To samo co delivery_number w wierszu zamówienia — łatwiej skleić papierowy WZ albo ID wysyłki z wierszem na liście, bez otwierania każdej karty.

iso_code z joinu waluty (EUR, USD, PLN…). Przy wielu walutach od razu widać, które wiersze wymagają dogryzki kursowej, jak w domyślnym widoku nie ma symbolu obok kwoty.

Zlepione, zlokalizowane nazwy reguł zapisanych na zamówieniu (katalog, vouchery, darmowa wysyłka itd.). Wartości są DISTINCT i posortowane alfabetycznie — w jednej komórce da się to przeczytać bez zgadywanek.