Введение
В Odoo модели определяют структуру данных и способ их хранения в базе. Любая деловая сущность — от заказа на продажу до счёта или карточки контакта — хранится в определённой модели.
Понимание моделей важно как разработчикам, так и функциональным консультантам. Именно модели формируют каркас данных в Odoo: они задают поля, связи и бизнес-логику, на которых строятся модули и отчёты.
В этой статье мы разбираем одну из ключевых моделей Odoo — res.partner. Если вы настраиваете системы, пишете интеграции или создаёте кастомные модули, вы неизбежно столкнётесь с ней.
Что такое модель res.partner
Модель res.partner предназначена для хранения информации о контрагентах: клиентах, поставщиках, физических лицах и компаниях. Это главная карточка «сторонних» лиц в системе.
res.partner используется практически во всех стандартных приложениях: продажи, CRM, учёт, закупки и интернет-магазин обращаются к ней при создании заказов, лидов или счётов. Часто одна и та же запись партнёра повторно используется в разных документах.
Определение модели находится в модуле base; остальные модули расширяют её через механизм наследования моделей. CRM добавляет поля для лидов, бухгалтерия — параметры платежей и кредитов, и так далее — каждый модуль дополняет базовую структуру без её дублирования.
Ключевые поля модели
Ниже перечислены важнейшие поля модели res.partner. Знание их назначения помогает корректно работать с контактами и настраивать процессы в Odoo.
1. name
Тип: Char. Отображаемое имя партнёра — для компании это название организации, для человека — полное имя. Это основной идентификатор, который виден во многих представлениях Odoo.
2. create_date
Тип: Datetime. Дата и время создания записи. Заполняется автоматически и полезна для отчётов и аудита.
3. write_date
Тип: Datetime. Дата и время последнего изменения записи. Автоматически поддерживается системой и помогает отслеживать актуальность данных.
4. email
Тип: Char. Основной адрес электронной почты. Используется для рассылок, счётов и доступа в портал; Odoo старается проверять корректность формата.
5. phone
Тип: Char. Основной телефонный номер для контакта. Отображается в карточке и участвует в коммуникационных сценариях.
6. mobile
Тип: Char. Мобильный номер. Часто используется для SMS-уведомлений или срочных сообщений при отличии от основного номера.
7. street
Тип: Char. Первая строка адреса — улица и дом. Включается в печатные формы и шаблоны документов.
8. street2
Тип: Char. Вторая строка адреса — корпус, квартира, дополнительная информация об адресе.
9. city
Тип: Char. Город или населённый пункт. Формат адреса может меняться в зависимости от страны.
10. zip
Тип: Char. Почтовый индекс. Используется при валидации адреса и расчёте доставки.
11. state_id
Тип: Many2one (res.country.state). Область или штат. Значения фильтруются по выбранной стране; не все страны используют этот уровень деления.
12. country_id
Тип: Many2one (res.country). Страна. Влияет на формат адреса, налоговые правила и локализацию.
13. is_company
Тип: Boolean. Флаг «это компания?». Если True — запись считается организацией и может иметь дочерние контакты; если False — обычный контакт, который можно связать с компанией через parent_id.
14. parent_id
Тип: Many2one (res.partner). Ссылка на родительскую компанию для контакта. Позволяет строить иерархию «компания — контакт» и наследовать некоторые поля от родителя.
15. child_ids
Тип: One2many (res.partner). Обратная связь от parent_id — список контактов, принадлежащих компании. Удобно для навигации и управления контактами организации.
16. company_id
Тип: Many2one (res.company). В конфигурациях с несколькими компаниями указывает, к какой конкретно компании относится запись партнёра — влияет на видимость и права доступа.
17. vat
Тип: Char. Налоговый идентификатор или ИНН/НДС-номер. Валидируется по формату страны; важен для расчёта налогов и соответствия требованиям отчётности.
18. customer_rank
Тип: Integer. Показывает статус клиента: число увеличивается при наличии продаж. Используется для фильтрации и приоритезации клиентов в списках и отчётах.
19. supplier_rank
Тип: Integer. Отражает статус поставщика: увеличивается при наличии закупок или счетов. Помогает быстро находить поставщиков.
20. user_id
Тип: Many2one (res.users). Ответственный менеджер или продавец. Применяется в CRM, распределении задач и отчётности по персоналу.
21. type
Тип: Selection. Тип адреса у дочерних контактов — Contact, Invoice, Delivery или Other. Определяет, какой адрес будет подставляться в документах; релевантно для контактов, привязанных к компании.
22. ref
Тип: Char. Внутренний код или ссылка. Удобно для интеграций с внешними системами и сопоставления записей.
23. website
Тип: Char. URL сайта партнёра. Используется в карточке и в интернет-магазине.
24. comment
Тип: Html. Внутренние заметки. Видимы пользователям системы, часто содержат инструкции для продаж или примечания по работе с клиентом.
25. active
Тип: Boolean. Флаг «активна запись». Если False — запись архивируется и скрывается в стандартных представлениях, но не удаляется из базы.
26. lang
Тип: Selection. Предпочитаемый язык партнёра. На его основе формируются переводы писем и документов; значение может наследоваться от родителя.
27. image_1920
Тип: Binary. Изображение партнёра или логотип. Odoo хранит несколько размеров и использует их в формах, отчётах и на сайте.
28. category_id
Тип: Many2many (res.partner.category). Метки или категории партнёра. Полезно для сегментации, маркетинга и фильтрации; гибкий инструмент для классификации.
Где и как модель применяется в бизнес-процессах
1. Продажи и CRM
При создании коммерческого предложения менеджер выбирает клиента из res.partner — та же запись используется для лида, возможности и заказа. customer_rank и user_id влияют на отчётность и автоматическое распределение задач.
2. Выставление счетов
Счета и платежные документы ссылаются на партнёра для данных выставления и доставки. Поле vat участвует в налоговых расчётах, а условия оплаты и кредитные лимиты часто хранятся на карточке партнёра.
3. Закупки и работа с поставщиками
Заказы на закупку и счета поставщиков привязаны к res.partner. supplier_rank помогает быстро определить активных поставщиков, а buyer_id назначает ответственного за работу с ними.
4. Электронная коммерция и портал
При регистрации на сайте создаётся запись партнёра, которая затем используется для оформления заказов и доступа в клиентский портал. Данные адреса и контактов берутся из этой карточки.
5. Мультикомпании и консолидация
В сценариях с несколькими компаниями одно юридическое лицо может существовать в базе как несколько записей для разных компаний. Поле company_id и правила межкомпаний управляют распространением данных.
Как разработчики расширяют модель
Разработчики расширяют res.partner несколькими способами. Основной инструмент — наследование моделей Odoo.
Наследование модели
Для расширения используйте _inherit = 'res.partner'. Так можно добавлять поля, переопределять методы и накладывать ограничения — и хранить изменения в отдельном модуле, что облегчает обновления.
Добавление полей
В наследуемой модели объявляйте новые поля нужного типа: Char, Many2one, Boolean, Integer, Text, Selection и т.п. Для сценариев с несколькими компаниями учитывайте company-dependent поля.
Расширения на Python
Переопределяйте методы create, write или unlink для внедрения логики, но не забывайте вызывать super() и корректно работать с вычисляемыми полями и их зависимостями.
Odoo Studio
Odoo Studio позволяет добавлять поля и простые формы без кода — удобно для быстрой настройки. Для сложной логики и поддерживаемых обновлений лучше использовать полноценные модули.
Рекомендации и лучшие практики
- Создавайте сначала запись компании, затем добавляйте контакты через parent_id — это корректная модель организации данных.
- Указывайте country_id для корректного форматирования адресов и расчёта налогов.
- Используйте commercial_partner_id, когда вам нужен верхнеуровневый субъект для агрегации (например, для кредитного лимита или отчётности).
- При интеграции через API используйте XML-RPC или JSON-RPC — модель res.partner полностью доступна. Тщательно сопоставляйте внешние идентификаторы.
- Для собственных полей применяйте префикс x_ или префикс модуля, чтобы избежать конфликтов при будущем обновлении Odoo.
Типичные ошибки
- Создание дублей вместо поиска существующих партнёров. Для дедупликации используйте email_normalized или ref.
- Путаница между parent_id и company_id. parent_id связывает контакт с компанией; company_id относится к настройкам мультикомпаний в Odoo.
- Забывание установить type у дочерних контактов. Неправильный тип мешает корректной подстановке адреса в счётах и доставке.
- Переопределение критичных методов без вызова super(). Это может нарушить работу других модулей и усложнить обновления.
- Добавление обязательных полей без значений по умолчанию. Это вызовет ошибки в существующих записях при установке или обновлении модуля.
Заключение
Модель res.partner — сердце учёта контрагентов в Odoo. Она аккумулирует данные клиентов и поставщиков; понимание её полей и того, как она расширяется, позволит быстрее настраивать, кастомизировать и интегрировать систему.
Независимо от того, занимаетесь ли вы функциональным аудитом бизнес-процессов или пишете кастомные модули, хорошее знание res.partner сэкономит время и снизит количество ошибок.
Нужна помощь с внедрением Odoo?
Dasolo помогает компаниям внедрять, дорабатывать и оптимизировать Odoo. Мы специализируемся на интеграциях через API и разработке модулей. Наша команда глубоко понимает архитектуру данных Odoo и модели вроде res.partner.
Если вам нужна помощь с внедрением Odoo, разработкой модулей или интеграциями — мы готовы помочь. Записаться на демонстрацию чтобы обсудить ваш проект.