Wprowadzenie
W Odoo każdy rodzaj danych — faktury, zamówienia, kontakty — ma swoje miejsce w modelu. Modele określają strukturę i sposób przechowywania informacji w bazie, dzięki czemu system rozumie, czym są dane i jak je przetwarzać.
Dla wdrożeniowców i programistów znajomość modeli to podstawa. To modele decydują o polach, relacjach między rekordami i o logice biznesowej, którą system może realizować — bez tego trudno skonfigurować czy rozszerzyć Odoo poprawnie.
Skupimy się na jednym z najważniejszych modeli w Odoo — res.partner. Każdy, kto tworzy moduły, integracje z zewnętrznymi systemami czy definiuje procesy sprzedaży i zakupów, prędzej czy później będzie z nim pracować.
Czym jest model res.partner
Model res.partner to centralne repozytorium danych o stronach biznesowych: klientach, dostawcach, firmach i kontaktach. To tutaj gromadzi się większość informacji wymaganych w codziennej pracy operacyjnej i księgowej.
res.partner jest wykorzystywany niemal we wszystkich modułach: Sprzedaż, CRM, Księgowość, Zakupy czy e‑commerce odwołują się do niego po informacje o kontrahentach. Tworząc klienta w module Sprzedaż lub dostawcę w Zakupach, operujesz na rekordzie res.partner.
Definicja modelu znajduje się w module bazowym, a inne moduły go rozszerzają przez dziedziczenie modelowe. CRM może dodać pola dla lejków sprzedaży, księgowość — pola związane z rozliczeniami — każdy dodaje swoje elementy bez powielania rdzenia.
Kluczowe pola modelu
Poniżej wymieniono najważniejsze pola res.partner — warto je znać, by sprawnie zarządzać kontaktami i automatyzacją procesów w Odoo.
1. name
Typ: Char. Nazwa rekordu — dla firmy to nazwa firmy, dla osoby — imię i nazwisko. Pole kluczowe: pojawia się w listach, formularzach i pełni funkcję podstawowego identyfikatora partnera.
2. create_date
Typ: Datetime. Data i godzina utworzenia rekordu. Odoo wypełnia to automatycznie — przydatne w raportach i audytach.
3. write_date
Typ: Datetime. Data ostatniej zmiany rekordu. Również zarządzane automatycznie — pomaga śledzić aktualizacje danych.
4. email
Typ: Char. Główny adres e‑mail partnera. Wykorzystywany do komunikacji, logowania do portalu i fakturowania. Odoo stara się walidować format e‑maili.
5. phone
Typ: Char. Numer telefonu stacjonarnego lub główny numer kontaktowy. Widoczny w formularzach kontaktowych i używany w procesach obsługi klienta.
6. mobile
Typ: Char. Numer telefonu komórkowego. Użyteczny przy powiadomieniach SMS lub gdy trzeba mieć alternatywny kontakt.
7. street
Typ: Char. Pierwsza linia adresu — ulica i numer. Część standardowego bloku adresowego wykorzystywanego na dokumentach.
8. street2
Typ: Char. Druga linia adresu — np. numer mieszkania, nazwa budynku lub dodatkowe informacje adresowe.
9. city
Typ: Char. Miasto lub miejscowość. Formatowanie adresu może zmieniać się w zależności od kraju.
10. zip
Typ: Char. Kod pocztowy. Wykorzystywany do walidacji adresu i przy kalkulacji kosztów wysyłki.
11. state_id
Typ: Many2one (res.country.state). Województwo/stan. Lista stanów jest filtrowana według kraju — nie wszystkie kraje jej używają.
12. country_id
Typ: Many2one (res.country). Kraj. Ma wpływ na format adresu, zasady podatkowe i lokalizację ustawień.
13. is_company
Typ: Boolean. Flaga mówiąca, czy rekord jest firmą czy osobą fizyczną. Firmy mogą mieć kontakty‑dzieci; osoby mogą być powiązane z firmą przez parent_id.
14. parent_id
Typ: Many2one (res.partner). Link do firmy macierzystej dla kontaktów. Umożliwia hierarchię firma→kontakt i dziedziczenie części danych z rodzica.
15. child_ids
Typ: One2many (res.partner). Odwrotność parent_id — lista kontaktów przypisanych do firmy. Przydatne przy nawigacji i zarządzaniu strukturą kontrahentów.
16. company_id
Typ: Many2one (res.company). W środowiskach wielofirmowych wskazuje, do której spółki należy partner. Ma znaczenie dla widoczności rekordu i zasad dostępu.
17. vat
Typ: Char. Numer NIP/UID/VAT. Walidowany zgodnie z formatem kraju. Kluczowy przy wystawianiu faktur i rozliczeniach podatkowych.
18. customer_rank
Typ: Integer. Wskaźnik statusu klienta. Odoo zwiększa go przy transakcjach sprzedażowych — pomocne przy filtrowaniu i priorytetyzacji list klientów.
19. supplier_rank
Typ: Integer. Wskaźnik statusu dostawcy. Zwiększany przy dokumentach zakupowych — użyteczny do identyfikacji aktywnych vendorów.
20. user_id
Typ: Many2one (res.users). Przypisany opiekun lub handlowiec. Wpływa na przydział działań CRM, raportowanie sprzedaży oraz odpowiedzialność za klienta.
21. type
Typ: Selection. Typ adresu dla kontaktów‑dzieci: Kontakt, Faktura, Dostawa lub Inny. Określa, który adres będzie użyty na dokumentach. Ważne dla kontaktów powiązanych z firmą.
22. ref
Typ: Char. Wewnętrzny kod lub referencja. Przydatny do mapowania z systemami zewnętrznymi lub w niestandardowym numerowaniu.
23. website
Typ: Char. Adres strony internetowej partnera. Widoczny w formularzu kontaktu i istotny w kontekście sklepu internetowego.
24. comment
Typ: Html. Notatki wewnętrzne. Widoczne dla użytkowników systemu — często używane do uwag sprzedażowych czy specjalnych instrukcji.
25. active
Typ: Boolean. Flaga „miękkiego usunięcia”. Gdy False, rekord jest archiwizowany i nie wyświetlany domyślnie — nie jest fizycznie usuwany z bazy.
26. lang
Typ: Selection. Preferowany język partnera. Umożliwia wysyłkę wiadomości i dokumentów w odpowiednim języku; pole może dziedziczyć wartość z parent_id.
27. image_1920
Typ: Binary. Zdjęcie partnera lub logo. Odoo przechowuje obrazy w różnych rozmiarach — używane w formularzach, raportach i na stronie WWW.
28. category_id
Typ: Many2many (res.partner.category). Tagi lub kategorie partnerów. Ułatwiają segmentację klientów, filtrowanie i działania marketingowe.
Jak model jest wykorzystywany w procesach biznesowych
1. Sprzedaż i CRM
Gdy handlowiec tworzy ofertę, wybiera klienta z listy partnerów — ten sam rekord używany jest dla leada, szansy i zamówienia. customer_rank i user_id pomagają w raportowaniu i przypisywaniu odpowiedzialności.
2. Fakturowanie
Faktury i rachunki odwołują się do partnera po adres rozliczeniowy. Pole vat wpływa na obliczenia podatkowe, a limity kredytowe czy warunki płatności są często przechowywane na poziomie partnera.
3. Zakupy i dostawcy
Zamówienia zakupowe i rachunki dostawców linkują do res.partner. supplier_rank pomaga wyróżnić aktywnych dostawców, a pole buyer_id (kupujący) przypisuje osobę odpowiedzialną za relację z vendorami.
4. E‑commerce i portal
Użytkownicy sklepu rejestrując konto tworzą rekord partnera — dane te służą potem do zamówień, ofert i dostępu do portalu. Adresy i kontakt są pobierane z rekordu partnera.
5. Wielofirmowość i konsolidacja
W środowiskach z wieloma spółkami ta sama jednostka prawna może mieć różne rekordy partnera przypisane do poszczególnych firm. company_id i zasady międzyfirmowe decydują, jak dane są współdzielone.
Jak programiści rozszerzają ten model
Programiści rozszerzają res.partner za pomocą kilku sprawdzonych wzorców — głównym narzędziem jest dziedziczenie modelowe Odoo.
Dziedziczenie modelu
Użyj _inherit = 'res.partner', by dodać pola, nadpisać metody lub wprowadzić ograniczenia. Dzięki dziedziczeniu zmiany trzyma się w osobnym module, co ułatwia późniejsze aktualizacje systemu.
Dodawanie pól
W dziedziczonym modelu definiuj nowe pola z odpowiednim typem — Char, Many2one, Boolean, Integer, Text, Selection. W środowiskach wielofirmowych rozważ pola zależne od company_id.
Rozszerzenia w Pythonie
Nadpisuj create, write czy unlink, gdy potrzebujesz niestandardowej logiki — zawsze wywołuj super(), aby nie łamać podstawowego zachowania. Uważaj na pola obliczane i ich zależności.
Odoo Studio
Studio pozwala dodać pola bez kodowania — szybkie i wygodne do prostych zmian. Dla zaawansowanych wymagań lub przy zachowaniu możliwości aktualizacji lepszym wyborem są moduły customowe.
Zasady dobrej praktyki
- Twórz hierarchię firma→kontakt poprawnie: zacznij od zdefiniowania firmy, potem dodaj do niej kontakty z parent_id.
- Ustaw country_id, by adresy i podatki były formatowane poprawnie według lokalnych reguł.
- Korzystaj z commercial_partner_id, gdy potrzebujesz odwołać się do podmiotu nadrzędnego (np. przy limitach kredytowych lub raportowaniu zbiorczym).
- Przy integracjach API używaj XML‑RPC lub JSON‑RPC — model res.partner jest dostępny zdalnie, a mapowanie zewnętrznych identyfikatorów wymaga staranności.
- Dla pól niestandardowych stosuj prefiks x_ lub prefiks modułu, aby uniknąć konfliktów przy przyszłych aktualizacjach Odoo.
Częste błędy
- Tworzenie zduplikowanych partnerów zamiast wyszukiwania istniejących. Korzystaj z email_normalized lub ref przy deduplikacji rekordów.
- Mieszanie parent_id z company_id. parent_id służy do relacji kontakt→firma; company_id odnosi się do własności rekordu w środowisku wielofirmowym.
- Zapominanie o ustawieniu typu (type) dla adresów podrzędnych. Adresy rozliczeniowe i dostawy muszą mieć właściwy typ, by trafiać na dokumenty.
- Nadpisywanie metod rdzeniowych bez wywołania super(). To ryzykowne — może zepsuć działanie innych modułów i utrudnić aktualizacje systemu.
- Dodawanie wymaganych pól bez wartości domyślnych. Istniejące rekordy mogą wtedy nie przejść walidacji podczas aktualizacji modułu.
Podsumowanie
Model res.partner jest jednym z filarów Odoo — przechowuje klientów, dostawców i kontakty. Dobra znajomość jego pól i sposobu rozszerzania pozwala bezpiecznie konfigurować i integrować system.
Niezależnie czy jesteś konsultantem biznesowym mapującym procesy, czy deweloperem budującym moduły — opanowanie res.partner oszczędzi czas i zmniejszy ryzyko błędów.
Potrzebujesz wsparcia przy wdrożeniu Odoo?
Dasolo pomaga firmom we wdrożeniach, dostosowaniach i optymalizacji Odoo. Specjalizujemy się w integracjach API i dewelopmencie na platformie Odoo — mamy doświadczenie w pracy z architekturą danych i modelami takimi jak res.partner.
Jeśli potrzebujesz wsparcia przy wdrożeniu Odoo, tworzeniu modułów lub integracjach — chętnie pomożemy. Umów prezentację i omówimy Twój projekt.