Wstęp
W Odoo wszystkie dane biznesowe — od zamówień sprzedaży, przez faktury, aż po karty produktów — są przechowywane w strukturach zwanych modelami. To one określają, jakie pola trzyma rekord, jakie relacje łączy i jak dane trafiają do bazy.
Dla konsultantów funkcjonalnych i programistów zrozumienie modeli Odoo to podstawa. Modele narzucają porządek w danych: pola, typy relacji i logikę biznesową. Wzorce są powtarzalne — opanowanie jednego modelu ułatwia pracę z innymi.
W tym tekście przyjrzymy się jednemu z ważniejszych modeli: product.template. Niezależnie czy konfigurujesz katalog produktów, integrujesz magazyn z ERP, czy tworzysz moduł — prędzej czy później trafisz na ten obiekt.
Czym jest model product.template
Model product.template opisuje „szablon” produktu — zbiór cech wspólnych dla rodziny wyrobów, które różnią się jedynie wariantami (np. rozmiar, kolor). Dzięki temu nie trzeba tworzyć osobnego rekordu dla każdej odmiany produktu.
Model ten jest wykorzystywany w modułach Sprzedaży, Zakupów, Magazynu, e‑commerce i Produkcji. Tworząc produkt w katalogu, dodajesz rekord product.template; natomiast w dokumentach operacyjnych zazwyczaj wybierasz konkretny wariant powiązany z szablonem.
Definicja modelu znajduje się w module product, a inne moduły rozszerzają go przez dziedziczenie modeli Odoo. Moduł sale dodaje elementy związane z cenami i fakturowaniem, purchase — obsługę dostawców, a stock — śledzenie stanów. Dzięki temu rdzeń pozostaje spójny, a każda funkcjonalność dopina swoje elementy.
Rozróżnienie product.template i product.product jest kluczowe. Szablon przechowuje dane wspólne dla rodziny produktów, natomiast produkt (wariant) zawiera dane unikalne — takie jak kod SKU czy kod kreskowy.
Kluczowe pola w modelu
Poniżej znajdują się najważniejsze pola modelu product.template. Znajomość ich znaczeń ułatwi poprawne konfigurowanie produktów i integracji.
1. name
Typ: Char. Nazwa produktu — podstawowy identyfikator wyświetlany w listach, ofertach i formularzach.
2. create_date
Typ: Datetime. Czas utworzenia rekordu. Pola zarządzane automatycznie, przydają się w raportach i audycie.
3. write_date
Typ: Datetime. Czas ostatniej modyfikacji. Automatycznie aktualizowany, pomaga śledzić zmiany.
4. active
Typ: Boolean. Flaga archiwizacji. Gdy False, rekord jest niewidoczny w widokach domyślnych — to miękkie usuwanie bez fizycznego kasowania.
5. sequence
Typ: Integer. Kolejność wyświetlania w listach i rozwijanych menu — mniejsze wartości pojawiają się wcześniej.
6. type
Typ: Selection. Rodzaj produktu: Consumable (zużywalny), Service (usługa) lub Storable (produkt magazynowany). Określa czy i jak produkt jest śledzony w magazynie.
7. categ_id
Typ: Many2one (product.category). Kategoria produktu — wpływa na raportowanie, domyślne trasy i porządek w katalogu. Kategorie mogą mieć strukturę hierarchiczną.
8. list_price
Typ: Float. Cena sprzedaży sugerowana — używana jako domyślna przy tworzeniu ofert; może być nadpisana przez cenniki lub ceny wariantów.
9. standard_price
Typ: Float. Cena zakupu/koszt własny — istotna przy wyliczaniu marż i wycenie zapasów.
10. currency_id
Typ: Many2one (res.currency). Waluta powiązana z list_price i standard_price — najczęściej dziedziczona z ustawień firmy.
11. uom_id
Typ: Many2one (uom.uom). Jednostka miary sprzedaży — jak liczone są ilości (szt., kg, l itp.).
12. uom_po_id
Typ: Many2one (uom.uom). Jednostka miary przy zakupie — może różnić się od uom_id i wymaga konwersji.
13. default_code
Typ: Char. Wewnętrzny numer referencyjny (SKU). Przydatny przy mapowaniu do systemów zewnętrznych.
14. barcode
Typ: Char. Kod kreskowy do skanowania — używany w POS, magazynie i inwentaryzacjach. Warianty zwykle mają swoje kody.
15. description
Typ: Char. Opis wewnętrzny widoczny dla użytkowników wewnętrznych — notatki operacyjne o produkcie.
16. description_sale
Typ: Text. Opis sprzedażowy — pojawia się w ofertach i fakturach; może zawierać formatowanie HTML.
17. description_purchase
Typ: Text. Opis zakupowy — widoczny na zamówieniach zakupu i rachunkach dostawców.
18. sale_ok
Typ: Boolean. Flaga mówiąca czy produkt może być sprzedawany — gdy False, nie pojawia się w formularzach sprzedaży.
19. purchase_ok
Typ: Boolean. Flaga mówiąca czy produkt może być kupowany — gdy False, ukryty przy zamówieniach zakupu.
20. weight
Typ: Float. Waga produktu — używana do obliczeń wysyłki i logistyki; jednostka zależna od ustawień firmy.
21. volume
Typ: Float. Objętość produktu — przydatna przy planowaniu przestrzeni magazynowej i logistyce.
22. product_variant_ids
Typ: One2many (product.product). Lista wariantów powiązanych z szablonem — każdy wariant dziedziczy cechy wspólne.
23. product_variant_count
Typ: Integer. Liczba wariantów — pole obliczane na podstawie product_variant_ids, używane do filtrowania i wyświetlania.
24. image_1920
Typ: Binary. Obraz produktu — Odoo przechowuje różne rozmiary; wykorzystywany na formularzach, w sklepie i w raportach.
25. responsible_id
Typ: Many2one (res.users). Osoba odpowiedzialna za produkt — przydatne do przypisywania zadań i zarządzania.
26. company_id
Typ: Many2one (res.company). Firma w konfiguracji multi‑company — określa przynależność rekordu.
27. tax_ids
Typ: Many2many (account.tax). Podatki naliczane klientowi przy sprzedaży — stosowane na ofertach i fakturach.
28. supplier_tax_id
Typ: Many2many (account.tax). Podatki przy zakupie — używane na rachunkach dostawców.
29. attribute_line_ids
Typ: One2many. Linie atrybutów definiujące warianty (np. rozmiar, kolor) — to one generują poszczególne product.product.
30. route_ids
Typ: Many2many (stock.route). Trasy magazynowe — określają ścieżkę produktu w łańcuchu dostaw (np. Buy, Make to Order).
31. property_stock_production
Typ: Many2one (stock.location). Lokalizacja produkcyjna dla wyrobów wytwarzanych — używana przy produkcji.
32. property_stock_inventory
Typ: Many2one (stock.location). Lokalizacja używana przy korektach i inwentaryzacjach.
33. property_valuation
Typ: Selection. Metoda wyceny zapasów: Automated lub Manual — wpływa na księgowanie kosztów zapasów.
34. property_cost_method
Typ: Selection. Metoda kosztowa: Standard lub FIFO — decyduje o sposobie wyceny zapasów.
35. property_account_income_id
Typ: Many2one (account.account). Konto przychodów przypisane do produktu — wykorzystywane przy fakturowaniu.
36. property_account_expense_id
Typ: Many2one (account.account). Konto kosztów przy zakupie produktu.
37. invoice_policy
Typ: Selection. Polityka fakturowania: na zamówione lub na dostarczone ilości — wpływa na moment rozpoznania przychodu.
38. expense_policy
Typ: Selection. Polityka księgowania kosztów: zamówione lub dostarczone — wpływa na rozpoznanie kosztów.
39. service_type
Typ: Selection. Dla usług: Manual, Timesheet lub Milestones — określa sposób rozliczania i śledzenia usług.
40. optional_product_ids
Typ: Many2many (product.template). Produkty opcjonalne do upsellu — proponowane podczas dodawania produktu do oferty.
Zastosowania modelu w procesach biznesowych
1. Sprzedaż i oferty
Sprzedawca wybiera produkty z katalogu przy tworzeniu oferty; szablon dostarcza opis i obrazy, a w razie potrzeby użytkownik wybiera konkretny wariant (np. kolor, rozmiar).
2. Sklep internetowy
W sklepie online klienci przeglądają szablony produktów; po wejściu na kartę produktu wybierają warianty. Szablon zawiera wspólne treści i multimedia.
3. Zakupy i dostawcy
Zamówienia zakupu i rachunki wiążą się z produktem — pola purchase_ok, uom_po_id i supplier_tax_id wpływają na zachowanie przy zakupie i relacje z dostawcami.
4. Magazyn i produkcja
Ruchy magazynowe i zlecenia produkcyjne odnoszą się do wariantów. Szablon definiuje trasy, sposób wyceny i metodę kosztowania, natomiast zapasy liczone są na poziomie wariantu.
5. Fakturowanie
Pozycje na fakturach i rachunkach bazują na liniach produktowych — szablon dostarcza reguły podatkowe i konta księgowe; invoice_policy wpływa na moment fakturowania.
Jak programiści rozszerzają ten model
Programiści rozszerzają product.template kilkoma sprawdzonymi sposobami — podstawą jest mechanizm dziedziczenia modeli Odoo.
Dziedziczenie modelu
W praktyce używasz _inherit = 'product.template', by dodać pola, nadpisać metody lub dodać ograniczenia. Dzięki temu zmiany trzyma się w modułach rozszerzających, co ułatwia aktualizacje i unika modyfikacji rdzenia.
Dodawanie pól
W swojej klasie możesz deklarować nowe pola: Char, Many2one, Boolean, Integer, Text, Selection. Pamiętaj o polach zależnych od firmy w środowiskach multi‑company.
Rozszerzenia w Pythonie
W razie potrzeby nadpisz metody takie jak create, write czy unlink, zawsze wywołując super(). Zwróć uwagę na pola obliczane i ich zależności, by nie łamać spójności danych.
Odoo Studio
Odoo Studio umożliwia szybkie dodawanie pól bez kodu — dobre rozwiązanie na szybkie potrzeby biznesowe. Jednak dla złożonej logiki i bezpieczeństwa przy upgrade'ach lepsze są dedykowane moduły.
Zalecane praktyki
- Trzymaj dane wspólne na szablonie, a cechy specyficzne — na wariantach product.product. To prosty klucz do poprawnego modelowania produktów.
- Ustaw kategorie (categ_id) poprawnie — to wpływa na domyślne trasy, zasady księgowe i raporty.
- Korzystaj z default_code do mapowania zewnętrznych katalogów — najlepiej utrzymywać unikalność SKU tam, gdzie to możliwe.
- Przy integracjach używaj XML‑RPC lub JSON‑RPC. Model product.template jest dostępny przez API Odoo — zwracaj uwagę na zgodność identyfikatorów i mapowanie pól.
- Dla własnych pól przestrzegaj konwencji nazewnictwa: używaj prefiksu modułu lub
x_, by zminimalizować ryzyko konfliktów w przyszłych wersjach Odoo.
Najczęściej popełniane błędy
- Tworzenie duplikatów szablonów zamiast użycia wariantów. Jeśli produkty różnią się tylko np. rozmiarem lub kolorem, zastosuj attribute_line_ids zamiast oddzielnych template'ów.
- Mylące użycie product.template i product.product. Dane przypisane do konkretnego wariantu (kod kreskowy, SKU) powinny leżeć na product.product.
- Zapominanie o ustawieniach sale_ok lub purchase_ok. Gdy są ustawione na False, produkt nie będzie widoczny na odpowiednich formularzach.
- Nadpisywanie metod rdzeniowych bez wywołania super(). To najczęstszy powód konfliktów z innymi modułami i problemów przy aktualizacjach.
- Dodawanie wymagalnych pól bez wartości domyślnych. Istniejące rekordy mogą wtedy nie przejść walidacji po aktualizacji modułu.
Podsumowanie
Model product.template to serce katalogu produktów w Odoo — przechowuje definicje i cechy wspólne. Znajomość jego pól i sposobu rozszerzania ułatwia konfigurację, dopasowywanie procesów i integracje.
Zarówno konsultant, który modeluje katalogi, jak i programista tworzący moduły zyska na opanowaniu product.template — to oszczędność czasu i mniej błędów.
Zacznij z Dasolo
Dasolo wspiera wdrożenia, rozwój i optymalizacje Odoo. Specjalizujemy się w integracjach API i rozwoju modułów, a nasze doświadczenie obejmuje pracę z architekturą danych Odoo i modelami takimi jak product.template.
Jeśli potrzebujesz wsparcia przy wdrożeniu Odoo, pisaniu modułów lub integracji — chętnie pomożemy. Umów demo i porozmawiajmy o Twoim projekcie.