Wprowadzenie
W Odoo struktury danych są zorganizowane wokół modeli — to one określają, jakie informacje przechowujemy w bazie i w jakiej formie. Każdy dokument biznesowy, od zamówień sprzedaży przez faktury po zapisy księgowe, ma swoje odzwierciedlenie w odpowiednim modelu.
Dla specjalistów funkcjonalnych i programistów zrozumienie modeli Odoo to podstawa. Modele definiują pola, relacje między tabelami i logikę biznesową — to one nadają sens danym i decydują o tym, jak system zachowuje się w codziennych procesach.
W artykule przyjrzymy się jednemu z kluczowych modeli księgowych w Odoo — account.move. Niezależnie od tego, czy tworzysz raporty, łączysz Odoo z zewnętrznymi systemami, czy konfigurujesz obieg faktur, ten model pojawi się niemal zawsze.
Czym jest model account.move
Model account.move odpowiada za zapisy w dzienniku księgowym. Od Odoo 13 scentralizowano obsługę: faktury sprzedaży, rachunki zakupu, noty korygujące i ręczne zapisy księgowe działają teraz w ramach jednego modelu — account.move.
Ten model jest podstawą modułu Księgowość i współpracuje z account.move.line, który zawiera poszczególne linie księgowań (debet/kredyt). Każda faktura czy zapis to rekord account.move z jedną lub wieloma liniami.
Definicja modelu znajduje się w module account, a inne moduły rozszerzają go przez dziedziczenie modeli. Moduł Sprzedaż dodaje tworzenie faktur z zamówień, Zakupy — generowanie rachunków. Dzięki dziedziczeniu rozszerzenia nie duplikują rdzenia modelu.
Kluczowe pola w modelu
Poniżej znajdują się najistotniejsze pola w modelu account.move. Znajomość ich znaczeń ułatwia pracę z fakturami, rachunkami i zapisami księgowymi.
1. name
Typ: Char. Numer lub nazwa zapisu księgowego. Najczęściej generowany automatycznie przez sekwencję powiązaną z danym dziennikiem. Widoczny w listach i na wydrukach dokumentów.
2. move_type
Typ: Selection. Określa rodzaj zapisu: entry (ręczny zapis), out_invoice (faktura sprzedaży), out_refund (nota korygująca dla klienta), in_invoice (rachunek zakupowy), in_refund (nota dla dostawcy). To pole decyduje o widokach i procesach, które zostaną zastosowane.
3. state
Typ: Selection. Status obiegu: draft, posted, cancel. W wersji roboczej rekordy można edytować; po zaksięgowaniu są zablokowane i wpływają na księgę główną. Anulowanie cofa skutki operacji.
4. date
Typ: Date. Data dokumentu — istotna przy raportowaniu, naliczaniu terminów i zamykaniu okresów. Dla faktury to zazwyczaj data wystawienia.
5. journal_id
Typ: Many2one (account.journal). Dziennik, do którego należy zapis — np. sprzedaż, zakup, bank. Dziennik wybiera sekwencję i konta domyślne.
6. company_id
Typ: Many2one (res.company). W konfiguracji wielofirmowej określa, której spółki dotyczy zapis. Ma wpływ na widoczność i raportowanie skonsolidowane.
7. partner_id
Typ: Many2one (res.partner). Kontrahent — klient lub dostawca. Pole wymagane przy fakturach i rachunkach; używane do rozliczeń, raportów terminowych i nagłówków dokumentów.
8. currency_id
Typ: Many2one (res.currency). Waluta dokumentu. Kwoty są przechowywane w tej walucie; raporty wielowalutowe wykorzystują także walutę firmy do przeliczeń.
9. amount_total
Typ: Monetary. Całkowita kwota dokumentu. W przypadku faktury oznacza kwotę do zapłaty; pole jest wyliczane z linii dokumentu.
10. amount_residual
Typ: Monetary. Kwota pozostała do zapłaty. Dla opłaconych faktur powinna wynosić zero; pole służy do naliczania zaległości i procesów płatności.
11. payment_state
Typ: Selection. Status płatności: not_paid, in_payment, paid, partial, reversed, invoicing_legacy. Służy do przypomnień płatniczych i analiz sald.
12. line_ids
Typ: One2many (account.move.line). Linie księgowe zapisu. Każda linia zawiera konto, debet i kredyt — suma debetów powinna równać się sumie kredytów.
13. invoice_line_ids
Typ: One2many (account.move.line). Dla faktur to linie produktów/usług. Po zaksięgowaniu każda taka linia generuje odpowiednie pozycje księgowe.
14. invoice_date
Typ: Date. Data faktury, ważna dla okresów podatkowych i rozliczeń; w niektórych konfiguracjach może różnić się od daty zapisu.
15. invoice_date_due
Typ: Date. Termin płatności — wyliczany na podstawie warunków płatności lub ustawiany ręcznie; wykorzystywany w analizach przeterminowań.
16. ref
Typ: Char. Referencja zewnętrzna, np. numer faktury dostawcy. Przydatna przy dopasowywaniu płatności i weryfikacji dokumentów.
17. invoice_origin
Typ: Char. Źródłowy dokument, np. numer zamówienia sprzedaży, co ułatwia śledzenie powiązań między zamówieniem a fakturą.
18. create_date
Typ: Datetime. Data i godzina utworzenia rekordu — wypełniana automatycznie przez system.
19. write_date
Typ: Datetime. Data i godzina ostatniej modyfikacji rekordu — również zarządzana przez Odoo.
20. narration
Typ: Text. Notatka wewnętrzna lub opis operacji — pojawia się na wydrukach zapisu, ale zwykle nie jest widoczna dla klienta na fakturze.
21. fiscal_position_id
Typ: Many2one (account.fiscal.position). Pozycja fiskalna określająca reguły podatkowe w zależności od kraju i kontrahenta — decyduje, jakie podatki mają zostać zastosowane.
22. invoice_payment_term_id
Typ: Many2one (account.payment.term). Warunki płatności, np. Net 30 — obliczają termin płatności i ewentualne podziały płatności.
23. invoice_user_id
Typ: Many2one (res.users). Osoba odpowiedzialna za fakturę (handlowiec, księgowy) — wykorzystywana w raportach i rozliczeniach prowizji.
24. reversed_entry_id
Typ: Many2one (account.move). Link do zapisu korygującego — pozwala śledzić powiązania między oryginałem a korektą w audycie.
25. to_check
Typ: Boolean. Flaga oznaczająca zapisy wymagające weryfikacji — przydatna w uzgadnianiu bankowym i obsłudze wyjątków.
26. active
Typ: Boolean. Flaga „miękkiego usunięcia”. Gdy False, rekord jest archiwizowany. Zazwyczaj anulowane zapisy ustawiane są jako nieaktywne.
27. sequence_number
Typ: Integer. Numer porządkowy z sekwencji dziennika — służy do sortowania i prezentacji; zarządzany przez mechanizm sekwencji.
28. amount_untaxed
Typ: Monetary. Suma netto przed podatkami — dla faktury to suma pozycji bez VAT.
29. amount_tax
Typ: Monetary. Łączna kwota podatku — wyliczana na podstawie linii faktury i konfiguracji podatkowej.
30. invoice_source_email
Typ: Char. Adres e-mail, z którego pochodzi rachunek przy importach mailowych — wykorzystywany w automatycznym przetwarzaniu dokumentów zakupowych.
Jak model wykorzystuje się w procesach biznesowych
1. Faktury sprzedażowe
Po wysyłce towaru system tworzy fakturę typu out_invoice bazując na zamówieniu sprzedaży — linie faktury pochodzą z pozycji zamówienia. Po zaksięgowaniu tworzone są odpowiednie pozycje w dzienniku i aktualizowane są należności.
2. Rachunki zakupu
Zamówienia zakupowe mogą generować rachunki, można też wprowadzać je ręcznie. Każdy rachunek to account.move typu in_invoice, z partner_id ustawionym na dostawcę — po zaksięgowaniu aktualizowane są zobowiązania.
3. Uzgadnianie płatności
Płatności dopasowuje się do faktur, korzystając z pola amount_residual i statusu payment_state. Proces uzgodnień łączy ruchy płatnicze z dokumentami i zamyka pozostałe salda.
4. Ręczne zapisy księgowe
Księgowi tworzą zapisy typu entry, żeby zaksięgować korekty, naliczenia czy rozliczenia. Dodają linie z odpowiednimi kontami oraz debetem i kredytem — zapis musi być zbilansowany przed zaksięgowaniem.
5. Noty korygujące i zwroty
Noty korygujące to zapisy typu out_refund lub in_refund — odwracają skutki pierwotnej faktury/rachunku. Pole reversed_entry_id wskazuje powiązanie z oryginałem, co ułatwia audyt.
Jak deweloperzy rozszerzają ten model
Deweloperzy rozszerzają account.move, korzystając z kilku wzorców — głównym narzędziem jest dziedziczenie modelu w Odoo.
Dziedziczenie modelu
W praktyce używa się _inherit = 'account.move', by dodać pola, nadpisać metody lub dodać ograniczenia. Dzięki osobnym modułom zmiany są modularne i łatwiejsze do utrzymania przy aktualizacjach.
Dodawanie pól
W dziedziczonym modelu definiuj nowe pola — Char, Many2one, Boolean, Integer, Text, Selection. W środowiskach wielofirmowych przemyśl pola zależne od firmy. Dla pól specyficznych dla faktur stosuj odpowiednie domainy na move_type.
Rozszerzenia w Pythonie
Nadpisuj metody takie jak create, write, _post czy button_draft, aby dodać logikę biznesową, pamiętając o wywołaniu super(). Uważaj na pola obliczane i zależności — dekoratory API (@api.model, @api.depends) kontrolują, kiedy metody są wywoływane.
Odoo Studio
Odoo Studio pozwala szybko dodać pola bez kodu — dobre rozwiązanie na proste potrzeby, np. dodatkowe pole referencyjne. Przy bardziej zaawansowanej logice czy automatyzacjach lepsze będą moduły napisane na miarę.
Ważna uwaga: account.move to zwykły model trwały — nie jest modelem abstrakcyjnym ani przejściowym. Modele abstrakcyjne służą jako szablony i nie tworzą tabel w bazie; modele przejściowe (transient) używa się do okienek i tymczasowych danych. account.move przechowuje trwałe dane księgowe.
Dobre praktyki
- Przy raportowaniu i integracjach zawsze filtruj po move_type — różne typy dokumentów mają odmienne wymagania i zachowania.
- Używaj właściwego dziennika dla danego typu zapisu. Mieszanie dzienników może zaburzyć numerację i raporty.
- Tworząc zapisy przez API, upewnij się, że line_ids są zbilansowane (suma debetów = suma kredytów) przed zaksięgowaniem; niezbilansowane zapisy zostaną odrzucone.
- Przy imporcie faktur z zewnętrznych systemów prawidłowo mapuj typy dokumentów na move_type — out_invoice dla sprzedaży, in_invoice dla zakupów.
- Dla własnych pól używaj prefiksu
x_, aby uniknąć konfliktów z przyszłymi wersjami Odoo.
Najczęstsze błędy
- Próba zaksięgowania niezbilansowanego zapisu. Odoo odrzuci taki wpis — zawsze sprawdź, czy debety i kredyty się zgadzają.
- Modyfikowanie zaksięgowanych zapisów bez korekty. Zaksięgowane dokumenty powinny być korygowane przez odwrócenie i utworzenie nowego zapisu, nie przez bezpośrednią edycję.
- Brak partner_id na dokumentach z kontrahentami. Wiele raportów i procesów zależy od tego pola, więc jego pominięcie powoduje problemy.
- Używanie niewłaściwego move_type. Nota korygująca nie jest tym samym co ujemna faktura — stosuj odpowiednie typy dokumentów.
- Nadpisywanie metod rdzenia bez wywołania super(). Taka praktyka może zepsuć funkcjonalność innych modułów i utrudnić aktualizacje.
Podsumowanie
Model account.move jest trzonem księgowości w Odoo — łączy faktury, rachunki i zapisy księgowe w jednym spójnym modelu. Znajomość jego pól i sposobu rozszerzania pozwala lepiej konfigurować system oraz bezpiecznie integrować i rozszerzać funkcjonalność.
Zarówno konsultant funkcjonalny mapujący procesy, jak i programista tworzący moduły zyskają na czasie i unikną błędów, jeżeli dobrze opanują model account.move.
Potrzebujesz pomocy z Odoo?
Dasolo wspiera firmy we wdrożeniach, dostosowaniach i optymalizacji Odoo. Specjalizujemy się w integracjach API i rozwoju modułów. Nasz zespół ma bogate doświadczenie w architekturze danych Odoo i pracy z modelami takimi jak account.move.
Jeżeli potrzebujesz wsparcia przy wdrożeniu Odoo, tworzeniu modułów lub integracji — chętnie pomożemy. Umów demonstrację aby omówić Twój projekt.