Введение
В Odoo вся информация организована в моделях — это как чертежи таблиц базы данных. Любая запись бизнеса: заказ, счет, проводка — хранится в своей модели и управляется её полями и логикой.
Понимание моделей важно и для разработчиков, и для консультантов: модели задают структуру данных, связи между объектами и встраивают бизнес-правила, на которых строится вся система.
В этой статье мы разберём одну из центральных моделей бухгалтерии Odoo — account.move. Если вы настраиваете счета, строите отчёты или пишете интеграции, рано или поздно вы столкнётесь с ней.
Что такое модель account.move
Модель account.move служит для представления бухгалтерских проводок. Начиная с Odoo 13 в ней объединены ранее разрозненные сущности — счета клиентов, счета поставщиков, кредит-ноты и ручные проводки — теперь всё хранится в одном месте.
account.move работает вместе с модулем бухгалтерии и является родительской для account.move.line, где лежат отдельные дебетовые и кредитовые строки. Каждый счёт или проводка — это одна запись account.move с набором строк.
Определение модели находится в модуле account; остальные модули расширяют её через наследование. Модуль продаж добавляет генерацию счетов из заказов, закупки — создание счетов от поставщиков, при этом базовая структура остаётся общей.
Ключевые поля модели
Ниже перечислены основные поля account.move — с ними полезно познакомиться, чтобы корректно работать со счёта‑ми, счетами поставщиков и проводками.
1. name
Тип: Char. Хранит номер или название проводки, обычно генерируется последовательностью журнала. Показывается в списках и печатных бланках.
2. move_type
Тип: Selection. Указывает вид проводки: entry (ручная проводка), out_invoice (счёт покупателю), out_refund (кредит‑нота покупателю), in_invoice (счёт от поставщика), in_refund (кредит‑нота поставщика). От этого поля зависят представления и бизнес‑процессы.
3. state
Тип: Selection. Состояние: draft, posted или cancel. Черновики можно редактировать, проведённые записи фиксируют главный бухгалтерский регистр, отменённые — аннулируют эффект.
4. date
Тип: Date. Дата документа — важна для отчётности, расчёта сроков оплаты и закрытия периодов. Для счетов обычно это дата выставления.
5. journal_id
Тип: Many2one (account.journal). Журнал, к которому относится проводка — продажи, покупки, банк и т.д. Журнал определяет последовательность нумерации и стандартные счета.
6. company_id
Тип: Many2one (res.company). Для компаний в нескольких юрисдикциях указывает, к какой компании относится проводка. Влияет на доступ и консолидацию.
7. partner_id
Тип: Many2one (res.partner). Контрагент — клиент или поставщик. Необходимо для счётов и используется в отчётах по оплатам и сверке.
8. currency_id
Тип: Many2one (res.currency). Валюта проводки. Суммы хранятся в этой валюте; расчёт в учётной валюте компании делается отдельно для отчётности.
9. amount_total
Тип: Monetary. Общая сумма документа. Для счетов — итог к оплате. Вычисляется по строкам.
10. amount_residual
Тип: Monetary. Оставшаяся к оплате сумма. Для полностью оплаченных документов — ноль. Важна для ageing и сверки.
11. payment_state
Тип: Selection. Статус оплаты: not_paid, in_payment, paid, partial, reversed или invoicing_legacy. Используется для напоминаний и аналитики.
12. line_ids
Тип: One2many (account.move.line). Строки проводки — каждая с указанием счёта, дебета и кредита. Дебеты и кредиты должны уравновешиваться.
13. invoice_line_ids
Тип: One2many (account.move.line). Для счетов — строки товаров и услуг; при проведении они порождают бухгалтерские строки.
14. invoice_date
Тип: Date. Дата выставления счёта — учитывается при налогообложении и формировании отчётов; может отличаться от даты проводки.
15. invoice_date_due
Тип: Date. Срок оплаты, вычисляемый по условиям оплаты или задаваемый вручную. Важен для расчёта задолженности.
16. ref
Тип: Char. Внешняя ссылка или номер счёта поставщика — удобно для сопоставления документов и сверки.
17. invoice_origin
Тип: Char. Источник документа — например номер заказа продажи. Обеспечивает трассировку от заказа до счёта.
18. create_date
Тип: Datetime. Дата и время создания записи — заполняется автоматически.
19. write_date
Тип: Datetime. Дата и время последнего изменения — тоже автоматическое поле.
20. narration
Тип: Text. Внутренние примечания или пояснения, которые печатаются в журналах, но обычно не видны клиентам на счётах.
21. fiscal_position_id
Тип: Many2one (account.fiscal.position). Фискальная позиция для налоговых правил — определяет применяемые налоги в зависимости от партнёра и страны.
22. invoice_payment_term_id
Тип: Many2one (account.payment.term). Условия оплаты (например, Net 30) — используются для вычисления срока оплаты и разбивки платежей.
23. invoice_user_id
Тип: Many2one (res.users). Ответственный пользователь или менеджер по счёту — полезно для отчётов и расчёта комиссий.
24. reversed_entry_id
Тип: Many2one (account.move). Для сторнирующих проводок — ссылка на исходную запись, что облегчает аудит.
25. to_check
Тип: Boolean. Флаг на проверку — применяется при исключениях, в банковской выписке и сверке.
26. active
Тип: Boolean. «Мягкое» удаление: при False запись архивируется. Часто отменённые проводки переводят в неактивные.
27. sequence_number
Тип: Integer. Номер по порядку из журнала — влияет на сортировку и отображение; управляется миксином последовательности.
28. amount_untaxed
Тип: Monetary. Сумма до налога — для счётов это сумма строк без налогов.
29. amount_tax
Тип: Monetary. Общая сумма налогов — считается по настройкам налогов и строкам счёта.
30. invoice_source_email
Тип: Char. При автоматическом создании счетов из почты хранит исходный адрес отправителя — удобно для импорта счетов по e‑mail.
Как модель применяется в бизнес-процессах
1. Выставление счетов клиентам
Когда товар доставлен по заказу продажи, система создаёт account.move с move_type out_invoice: строки счёта берутся из заказа, при проведении генерируются бухгалтерские проводки и обновляются дебиторская задолженность.
2. Счета от поставщиков
Заказы закупок могут превращаться в счета, либо их вводят вручную. Такие документы имеют move_type in_invoice и, после проведения, увеличивают кредиторскую задолженность по контрагенту.
3. Сверка платежей
Платежи сопоставляются со счетами через amount_residual и payment_state. Процесс сверки связывает проводки платежей со счетами и обнуляет остатки.
4. Ручные бухгалтерские проводки
Бухгалтеры создают проводки с move_type entry для корректировок, начислений и прочих операций, вручную добавляя строки с нужными счетами; перед проведением проводка должна быть сбалансирована.
5. Кредит‑ноты и возвраты
Кредит‑ноты представлены как out_refund или in_refund и служат для отмены эффекта исходного счета; поле reversed_entry_id хранит связь с первичным документом для аудита.
Как разработчики расширяют модель
Разработчики расширяют account.move несколькими способами, основным из которых является наследование моделей Odoo.
Наследование модели
Пропишите _inherit = 'account.move' в своём модуле, чтобы добавить поля, переопределить методы или добавить ограничения. Так изменения остаются в отдельном модуле и проще обновлять систему.
Добавление полей
В наследуемой модели можно объявлять новые поля нужного типа: Char, Many2one, Boolean, Integer, Text, Selection. Для мультикомпаний учитывайте company_dependent, а для полей, относящихся только к счетам, используйте домен по move_type.
Расширения на Python
Переопределяйте методы create, write, _post или button_draft, добавляя логику через super(). Обращайте внимание на вычисляемые поля и их зависимости; декораторы API (@api.model, @api.depends) управляют порядком выполнения.
Odoo Studio
Odoo Studio позволяет быстро добавить поля без кода — удобно для простых доработок. Для сложной валидации и автоматизации всё же лучше создавать собственные модули.
Важно: account.move — обычная постоянная модель, а не абстрактная или транзиентная. Абстрактные модели не создают таблицы, транзиентные служат для мастеров. account.move хранит постоянные бухгалтерские данные.
Рекомендации по использованию
- При составлении отчётов и интеграций всегда фильтруйте по move_type — у разных типов документы имеют разные обязательные поля и поведение.
- Используйте соответствующий журнал для каждого типа операции — смешение журналов ломает нумерацию и искажает отчёты.
- При создании проводок через API убедитесь, что суммы по line_ids сбалансированы (дебеты = кредиты) до проводки — иначе валидация не позволит провести запись.
- При импорте счетов из внешних систем правильно отображайте тип документа: out_invoice для продаж и in_invoice для закупок, чтобы бизнес‑логика сработала корректно.
- Для пользовательских полей используйте префикс x_ — это снижает риск конфликтов с будущими версиями Odoo.
Типичные ошибки
- Проведение несбалансированных проводок. Odoo отклонит такую операцию — всегда проверяйте равенство дебетов и кредитов.
- Прямые изменения проведённых проводок. Проведённые записи заблокированы — для исправления делайте сторнирование и создавайте новую проводку.
- Отсутствие partner_id на документах контрагентов. Многие отчёты и процессы зависят от наличия контрагента — не забывайте его указывать.
- Неправильный выбор move_type. Кредит‑нота — это отдельный тип (out_refund/in_refund), а не просто отрицательный out_invoice; используйте корректные типы.
- Переопределение ключевых методов без вызова super(). Это может сломать интеграции и усложнить обновления.
Итоги
Модель account.move — сердце учётной части Odoo: в ней сосредоточены счета, счета поставщиков и проводки. Знание полей и способов расширения поможет правильно настраивать и интегрировать систему.
И консультанту, и разработчику — хорошее понимание account.move сэкономит время и убережёт от типичных ошибок при кастомизации и внедрениях.
Нужна помощь с Odoo?
Dasolo помогает компаниям внедрять, настраивать и оптимизировать Odoo. Мы специализируемся на интеграциях через API и разработке модулей, глубоко знакомы с архитектурой данных Odoo и моделью account.move.
Если вам требуется помощь с внедрением Odoo, разработкой модулей или интеграциями — мы готовы помочь. Записаться на демо чтобы обсудить ваш проект.