Model sales.order: Jak działa architektura zamówień sprzedaży w Odoo

Wstęp

W Odoo modele to schematy opisujące, jak dane są przechowywane w bazie. Wszystkie istotne informacje biznesowe — oferty, faktury, kontrahenci — mają swoją reprezentację w modelach.

Zrozumienie modeli jest niezbędne zarówno dla wdrożeniowców funkcjonalnych, jak i programistów. To one określają pola, więzy między rekordami i osadzone reguły biznesowe, czyli szkielet danych w systemie.

Ten tekst koncentruje się na jednym z najważniejszych modeli w Odoo: sales.order. Niezależnie od tego, czy tworzysz moduły, integrujesz systemy zewnętrzne czy konfigurujesz proces sprzedaży — prędzej czy później będziesz pracować z tym modelem.

Czym jest model sales.order

Model sales.order odpowiada za oferty i zamówienia sprzedaży. To centralne miejsce, w którym zapisywane są transakcje sprzedażowe zanim staną się fakturami lub zostaną wydane.

Model jest wykorzystywany głównie przez moduł Sprzedaż (Sales).

Przebieg standardowy wygląda tak: sprzedawca tworzy ofertę (rekord sales.order w stanie roboczym), klient potwierdza — status zmienia się na potwierdzony. Ten sam model przechowuje zarówno wersje robocze ofert, jak i finalne zamówienia; pole statusu (state) odzwierciedla etap.

Inne moduły dobudowują własne elementy do tego modelu poprzez mechanizmy dziedziczenia: CRM powiąże szanse sprzedaży z zamówieniami, Księgowość doda pola fakturowania, Magazyn — terminy dostaw i rezerwacje. Dzięki temu nie dubluje się podstawowej struktury.

Kluczowe pola w modelu

Poniżej opisano najważniejsze pola, które warto znać, pracując z ofertami i zamówieniami — to fundament poprawnej konfiguracji i integracji.

1. name

Typ: Char. Numer referencyjny zamówienia/oferty. Zwykle generowany automatycznie (np. S00042) i wyświetlany w listach oraz na wydrukach — pełni rolę podstawowego identyfikatora.

2. state

Typ: Selection. Określa etap zamówienia. Typowe wartości: draft (oferta), sent (wysłana), sale (potwierdzone zamówienie), done (zrealizowane i zafakturowane), cancel (anulowane). Od stanu zależą dostępne akcje.

3. partner_id

Typ: Many2one (res.partner). Klient (firma lub osoba kontaktowa). Pole obowiązkowe — używane w logice klienta i raportowaniu.

4. partner_invoice_id

Typ: Many2one (res.partner). Adres do fakturowania. Domyślnie bierze wartość z partner_id — ustaw, gdy fakturowanie odbywa się gdzie indziej (np. centralny dział rozliczeń).

5. partner_shipping_id

Typ: Many2one (res.partner). Miejsce dostawy. Jeśli nie uzupełnione, używany jest główny partner. Ważne dla zleceń dostawy i wyliczeń kosztów transportu.

6. user_id

Typ: Many2one (res.users). Opiekun sprzedaży. Wpływa na raporty, prowizje i przypisywanie aktywności — często pochodzi z drużyny sprzedażowej lub powiązanej szansy.

7. team_id

Typ: Many2one (crm.team). Zespół sprzedaży. Grupuje sprzedawców i zasady raportowania — przydatne przy celach i pulpitach menedżerów.

8. date_order

Typ: Datetime. Data zamówienia: dla projektu roboczego — data utworzenia, dla potwierdzonego zamówienia — data potwierdzenia. Używane w raportach i sortowaniu.

9. validity_date

Typ: Date. Termin ważności oferty. Po upływie tej daty oferta może stracić ważność — przydatne przy limitowanych promocjach.

10. commitment_date

Typ: Datetime. Obiecany termin dostawy. Gdy jest ustawiony, harmonogramy wysyłek są planowane względem tej daty, a nie standardowych czasów realizacji — kluczowe dla zobowiązań wobec klienta.

11. order_line

Typ: One2many (sale.order.line). Pozycje zamówienia — każda linia zawiera produkt, ilość, cenę i podatki. To sedno treści zamówienia.

12. amount_untaxed

Typ: Float. Kwota netto przed podatkami. Obliczana z linii zamówienia — wykorzystywana w raportach i podsumowaniach.

13. amount_tax

Typ: Float. Łączna wartość podatków. Obliczana z konfiguracji podatkowej na liniach — pokazywana na zamówieniu i fakturze.

14. amount_total

Typ: Float. Suma brutto z podatkami. Główna wartość do fakturowania i raportowania.

15. currency_id

Typ: Many2one (res.currency). Waluta zamówienia. Zwykle dziedziczona z firmy lub cennika — wszystkie pola monetarne są w tej walucie.

16. pricelist_id

Typ: Many2one (product.pricelist). Cennik zastosowany do zamówienia. Określa ceny jednostkowe na liniach — można go nadpisać ręcznie lub pobrać z klienta.

17. payment_term_id

Typ: Many2one (account.payment.term). Warunki płatności (np. 30 dni, zaliczka 50%). Używane przy tworzeniu faktur.

18. fiscal_position_id

Typ: Many2one (account.fiscal.position). Pozycja fiskalna służąca do mapowania podatków — przydatna przy transakcjach międzynarodowych lub specjalnych reżimach podatkowych.

19. client_order_ref

Typ: Char. Numer referencyjny klienta lub zamówienie PO. Przydatne, gdy klient podaje własne odniesienie — pokazuje się na dokumentach i raportach.

20. origin

Typ: Char. Źródłowy dokument — np. nazwa szansy sprzedaży, z której powstało zamówienie. Pomaga w śledzeniu pochodzenia.

21. create_date

Typ: Datetime. Data utworzenia rekordu — zarządzana automatycznie przez Odoo, ważna do audytu i raportów.

22. write_date

Typ: Datetime. Data ostatniej modyfikacji — również automatycznie zapisywana, użyteczna do kontroli zmian.

23. note

Typ: Text. Dodatkowe uwagi lub warunki umowy. Może się pojawić na ofercie i fakturze — miejsce na zapisy prawne czy instrukcje.

24. require_signature

Typ: Boolean. Jeśli zaznaczone — klient musi podpisać elektronicznie przed potwierdzeniem. Stosowane w e‑commerce i w portalu klienta.

25. require_payment

Typ: Boolean. Jeżeli prawda — wymagana płatność przed potwierdzeniem. Wykorzystywane przy zamówieniach przedpłaconych lub z zaliczką.

26. invoice_status

Typ: Selection. Status fakturowania: no (nie fakturowane), to invoice (do fakturowania), invoiced (zafakturowane), upsell (dodatkowe pozycje do fakturowania).

27. locked

Typ: Boolean. Gdy prawda — zamówienie jest zablokowane do edycji. Ustawiane automatycznie po potwierdzeniu lub zaksięgowaniu powiązanych dokumentów.

28. company_id

Typ: Many2one (res.company). W konfiguracjach wielofirmowych określa, do której firmy należy zamówienie — wpływa na widoczność i prawa dostępu.

29. tag_ids

Typ: Many2many (crm.tag). Etykiety do kategoryzacji — pomocne przy filtrowaniu, segmentacji i raportach ad‑hoc.

30. signed_by

Typ: Char. Imię i nazwisko osoby, która podpisała zamówienie — zapis przy włączonej funkcji podpisu.

31. signed_on

Typ: Datetime. Data i czas złożenia podpisu — wykorzystywane do celów audytowych.

32. prepayment_percent

Typ: Float. Procent wartości wymagany jako przedpłata. Używane razem z require_payment przy zamówieniach na zaliczkę.

Jak model używany jest w procesach biznesowych

1. Z oferty do zamówienia

Sprzedawca przygotowuje ofertę, dodaje pozycje i ceny, wysyła do klienta. Po akceptacji oferta przechodzi w zamówienie (state = sale) i można wygenerować faktury oraz zlecenia dostawy.

2. Sklep internetowy i portal klienta

Zamówienia ze sklepu trafiają bezpośrednio jako rekordy sales.order. Pole require_payment lub require_signature może wymusić płatność online lub podpis przed finalizacją.

3. CRM → Sprzedaż

Po wygraniu szansy sprzedażowej tworzy się oferta powiązana z tą szansą — informacja źródłowa zapisywana jest w origin. user_id i team_id wpływają na raporty i prowizje.

4. Fakturowanie

Z potwierdzonego zamówienia generuje się faktury — pozycje faktury są pobierane z linii zamówienia. Warunki płatności i pozycja fiskalna przechodzą z zamówienia; invoice_status odzwierciedla postęp.

5. Dostawa i terminy realizacji

Pole commitment_date wpływa na planowanie wysyłek — magazyn układa zlecenia dostawy biorąc pod uwagę zadeklarowany termin. partner_shipping_id definiuje adres dostawy.

Jak deweloperzy rozszerzają ten model

Deweloperzy rozszerzają sales.order kilkoma sposobami — główną techniką jest dziedziczenie modeli w Odoo.

Dziedziczenie modelu

W module użyj _inherit = 'sale.order', aby dodać pola, nadpisać metody lub dodać ograniczenia. Rozszerzenia umieszczamy w odrębnym module, co ułatwia utrzymanie i aktualizacje.

Dodawanie pól

Definiuj nowe pola zgodnie z potrzebą: Char, Many2one, Boolean, Integer, Text, Selection. W środowiskach wielofirmowych rozważ pola zależne od firmy.

Rozszerzenia w Pythonie

Nadpisuj metody takie jak action_confirm, create czy write dodając własną logikę — pamiętaj o wywołaniu super(). Uważaj na pola obliczane i ich zależności.

Odoo Studio

Odoo Studio pozwala na szybkie dodanie pól bez kodu — dobre do prostych zmian. Przy złożonej logice lub konieczności aktualizacji systemu warto jednak tworzyć dedykowane moduły.

Dobre praktyki

• Używaj właściwych stanów na każdym etapie — nie pomijaj kroków i nie obchodź logiki potwierdzania.
• Ustalaj commitment_date, gdy klient oczekuje konkretnego terminu dostawy — poprawia to planowanie operacji magazynowych.
• Gdy potrzebujesz głównej jednostki do rozliczeń lub raportów, korzystaj z commercial_partner_id — to top‑level podmiot grupujący kontakty.
• Do integracji API używaj XML‑RPC lub JSON‑RPC — model sales.order jest dostępny z poziomu API. Starannie mapuj zewnętrzne identyfikatory.
• Dla własnych pól stosuj prefiks x_ lub prefiks modułu, by uniknąć kolizji przy przyszłych aktualizacjach Odoo.

Częste błędy

• Nie modyfikuj potwierdzonych zamówień bez sprawdzenia pola locked — zablokowane rekordy wymagają albo nowej rewizji, albo oficjalnego przepływu pracy.
• Nie mieszaj partner_id, partner_invoice_id i partner_shipping_id — każde pole ma inne przeznaczenie. Uzupełnij wszystkie, gdy adresy się różnią.
• Nie nadpisuj action_confirm bez wywołania super() — to może zepsuć integracje innych modułów lub przyszłe aktualizacje.
• Nie dodawaj wymaganych pól bez domyślnych wartości — w przeciwnym razie istniejące rekordy mogą przestać się zapisywać podczas aktualizacji.
• Pamiętaj, by ustawić pricelist_id, gdy waluta lub sposób wyceny różni się od domyślnych — brak prawidłowego cennika może skutkować błędnymi cenami i fakturami.

Podsumowanie

Model sales.order to serce modułu sprzedaży w Odoo — przechowuje oferty i zamówienia. Zrozumienie jego pól i sposobu, w jaki inne moduły go rozszerzają, ułatwia konfigurację, rozwój i integracje.

Niezależnie od tego, czy projektujesz procesy sprzedażowe, czy piszesz moduły, dobra znajomość sales.order oszczędzi czas i zredukuje ryzyko błędów.

Potrzebujesz pomocy przy wdrożeniu Odoo?

Dasolo pomaga firmom wdrażać, dostosowywać i optymalizować Odoo. Specjalizujemy się w integracjach API i rozwoju modułów — dobrze znamy architekturę danych Odoo i modele takie jak sales.order.

Jeśli potrzebujesz wsparcia przy wdrożeniu Odoo, tworzeniu modułów lub integracji — chętnie pomożemy. Umów demo i porozmawiajmy o Twoim projekcie.