Введение
В Odoo «модели» — это схема хранения бизнес‑данных в базе: каждое понятие — заказ, перемещение, операция склада — представлено как модель с набором полей и правилами. Именно модели определяют, какие данные сохраняются и как они связаны между собой.
Разбираться в моделях важно и разработчикам, и функциональным консультантам: архитектура данных Odoo строится вокруг них. Модель описывает поля, связи и встроенную логику — это база для всех кастомизаций, отчетов и интеграций.
В этой заметке мы сосредоточимся на одной из ключевых моделей приложения «Склад» — stock.picking. Если вы настраиваете процессы склада, пишете модули или интегрируете внешние системы, взаимодействие с этой моделью неизбежно.
Что такое модель stock.picking
Модель stock.picking в Odoo служит для учёта перемещений товаров. Это «карточка» каждой отгрузки, приёмки или внутреннего перемещения: каждая запись описывает конкретный перенос товаров из одной локации в другую.
В модуле «Склад» stock.picking используется повсеместно: приходные накладные, отгрузки клиентам и внутренние перемещения создают такие записи. Подтверждение продажи, приём закупки или межскладской трансфер — всё это отражается через stock.picking.
Описание модели находится в модуле stock, а функциональность дополняют другие модули через наследование моделей. Модуль продаж добавляет поля доставки, закупки — логику приёма, производство — свои перемещения — при этом базовая структура остаётся общей и не дублируется.
stock.picking наследует функциональность трекинга от mail.thread и mail.activity.mixin, поэтому по перемещениям можно вести переписку в чате, отслеживать изменения и назначать действия напрямую из карточки переноса.
Ключевые поля модели
Ниже перечислены ключевые поля stock.picking, понимание которых поможет быстро работать с перемещениями и настраивать складские сценарии.
1. name
Тип: Char. Номер и ссылка на перемещение, обычно генерируется последовательностью (например, WH/OUT/00001). Отображается в шапке документа и служит основным идентификатором для пользователя.
2. origin
Тип: Char. Ссылка на исходный документ — например, номер заказа продажи или закупки. Помогает проследить источник перемещения при анализе и отчётности.
3. state
Тип: Selection. Статус перемещения (черновик, ожидание, готово, выполнено, отменено и т. п.). От состояния зависят доступные действия и переходы; значение вычисляется на основе связанных stock.move.
4. picking_type_id
Тип: Many2one (stock.picking.type). Тип операции — приёмка, отгрузка или внутренний перенос. Обязательное поле: в типе заданы дефолтные исходная и целевая локации и поведение по умолчанию.
5. move_ids
Тип: One2many (stock.move). Строки перемещений: каждый элемент описывает продукт и количество для перемещения. На эти строки опирается логика резервирования и доступности.
6. move_line_ids
Тип: One2many (stock.move.line). Детализированные операции: лоты, серийные номера, конкретные места хранения и упаковки. Используется при подборе, упаковке и подтверждении перемещений.
7. location_id
Тип: Many2one (stock.location). Локация-источник — откуда забирают товар. Обязательное поле: для отгрузок это обычно складская локация, для приёмок — локация поставщика.
8. location_dest_id
Тип: Many2one (stock.location). Локация‑назначение — куда перемещают товар. Обязательное поле: для отгрузок — локация клиента, для приёмок — склад.
9. partner_id
Тип: Many2one (res.partner). Контрагент, связанный с перемещением: для доставок — покупатель, для приёмок — поставщик. Влияет на печатные документы и работу с перевозчиками.
10. scheduled_date
Тип: Datetime. Запланированная дата выполнения перемещения. Используется для планирования и приоритизации работ; её изменение задаёт ожидаемую дату для всех связанных перемещений.
11. date_deadline
Тип: Datetime. Крайний срок по доставке — часто наследуется из заказа продажи или закупки. Помогает помечать просрочки и рассчитывать обещанные даты клиентам.
12. date_done
Тип: Datetime. Фактическая дата подтверждения или отмены перемещения. Это поле только для чтения и заполняется автоматически при завершении.
13. priority
Тип: Selection. Уровень приоритета перемещения. При резервировании товары распределяются сначала по более приоритетным операциям; полезно для срочных заказов.
14. move_type
Тип: Selection. Политика отгрузки: «по мере готовности» (частичные отгрузки разрешены) или «только когда всё готово» (всё или ничего). Это влияет на момент обработки перемещения.
15. user_id
Тип: Many2one (res.users). Ответственный пользователь. Нужен для назначения задач и учёта загрузки сотрудников; по умолчанию ставится текущий пользователь при создании.
16. company_id
Тип: Many2one (res.company). Компания-владелец перемещения. В multi‑company конфигурациях определяет, к какой компании относится операция; обычно берётся из типа перемещения.
17. group_id
Тип: Many2one (procurement.group). Группа закупок/прокьюмента. Объединяет связанные перемещения, когда несколько отгрузок или приёмок исходят из одного заказа.
18. backorder_id
Тип: Many2one (stock.picking). При частичном подтверждении создаётся backorder для оставшегося товара; это поле ссылается на исходный документ.
19. backorder_ids
Тип: One2many (stock.picking). Список бэко́рдеров, образованных из данной записи при частичных подтверждениях — удобно для отслеживания оставшихся задач.
20. return_id
Тип: Many2one (stock.picking). Если текущее перемещение — возврат, это поле указывает на оригинальную отгрузку и используется в процессах возврата.
21. note
Тип: Html. Внутренние примечания для складской команды: инструкции по обработке, особенности упаковки или требования по хранению, видимые сотрудникам склада.
22. signature
Тип: Image. Подпись, зафиксированная при подтверждении доставки. Хранится как вложение и служит доказательством доставки клиенту.
23. is_signed
Тип: Boolean. Вычисляемое поле от подписи — показывает, была ли доставка подписана.
24. owner_id
Тип: Many2one (res.partner). Владение товаром при валидации — важно для консигнации или когда товары принадлежат третьей стороне и должны оставаться в учёте за другим контрагентом.
25. package_level_ids
Тип: One2many (stock.package_level). Уровни упаковок при использовании функции «поместить в упаковку»: помогает группировать строки перемещений в пакеты для отправки.
26. create_date
Тип: Datetime. Дата создания записи. Автоматически поддерживается Odoo — поле базовой модели.
27. write_date
Тип: Datetime. Дата последнего изменения. Также автоматически управляется системой.
28. active
Тип: Boolean. Флаг мягкого удаления: когда False — запись архивируется и не показывается в активных списках.
Как модель используется в бизнес‑процессах
1. Продажи и отгрузки
При подтверждении заказа продажи система формирует delivery order (stock.picking). Карточка перемещения связывается с заказом через origin, склад подбирает и пакует товар, затем перемещение подтверждается — статус проходит этапы от черновика до выполнения.
2. Закупки и приёмки
Подтверждение заказа закупки создаёт входящую приёмку. Поставщик передаёт товар со своей локации на склад, в карточке указан partner_id как поставщик, а валидация обновляет остатки на складе.
3. Внутренние перемещения
Трансферы между складами или зонами оформляются как внутренние pickings. Для них picking_type_id имеет код 'internal', а источником и назначением выступают внутренние складские локации.
4. Возвраты и бэко́рдеры
При возврате продажи формируется возвратная карточка, связанная с оригиналом через return_id. При частичной обработке создаются бэко́рдеры: оставшиеся позиции попадают в backorder_ids для дальнейшей обработки.
5. Производство
Заказы на производство порождают перемещения для расхода сырья и прихода готовой продукции. Модуль mrp расширяет stock.picking, добавляя логику для производственных потоков.
Как разработчики расширяют модель
Разработчики расширяют stock.picking несколькими способами, причём основным инструментом остаётся наследование моделей Odoo.
Наследование модели
В декларируемой модели укажите _inherit = 'stock.picking' — так вы добавите поля, переопределите методы или ввяжете новые ограничения. Изменения оформляются в отдельном модуле, что упрощает обновления и сопровождение.
Добавление полей
В своём наследнике объявляйте новые поля нужных типов: Char, Many2one, Boolean, Integer, Text, Selection. Для мультикомпани‑сценарием учитывайте company_dependent поля и ограничения доступа.
Расширения на Python
Переопределяйте методы вроде button_validate, action_assign или _create_backorder, добавляйте свою логику и не забывайте вызывать super(), чтобы не нарушить стандартные переходы состояний и взаимодействие с другими модулями.
Odoo Studio
Studio позволяет быстро добавлять поля и простые формы без кода — удобно для мелких изменений. Но для серьёзной интеграции с перевозчиками или сложной логики лучше писать полноценные модули.
Рекомендации по использованию
- При ручном создании перемещений всегда указывайте picking_type_id: от этого зависят дефолтные локации и поведение при обработке.
- Используйте поле origin, чтобы сохранить ссылку на исходный документ — это облегчит отчёты, аудит и отладку.
- Для API‑интеграций модель stock.picking полностью доступна: создавайте перемещения через связь move_ids. Не создавайте оформленные pickings без move_ids — это неконсистентно и нарушит логику резервирования.
- Поле scheduled_date удобно для планирования задач сотрудников и влияет на логику резервирования и приоритезации операций.
- Для пользовательских полей применяйте префиксы x_ или префикс модуля, чтобы избежать конфликтов при обновлениях Odoo.
Типичные ошибки
- Создание перемещений без указания picking_type_id — частая причина неверных дефолтных локаций и некорректного поведения системы.
- Изменение move_ids после подтверждения без учёта машины состояний может привести к несогласованности статусов и проблемам при валидации.
- Отсутствие partner_id в доставках осложняет печать документов и интеграцию с перевозчиками — не забывайте заполнять контакт.
- Переопределение button_validate без вызова super() ломает создание бэко́рдеров и взаимодействие с другими расширениями — всегда учитывайте цепочку вызовов.
- Не стоит полагать, что move_ids и move_line_ids всегда синхронизированы: строки перемещений подробняются в move_line_ids при резервировании или при использовании детализированных операций.
Вывод
Модель stock.picking — центр учёта перемещений в Odoo: здесь хранятся приёмки, отгрузки и внутренние трансферы. Знание её полей и механизмов расширения поможет корректно настраивать процессы, писать интеграции и избегать эксплуатационных проблем.
Для функционального консультанта, который сопоставляет процессы склада с системой, или для разработчика, создающего кастомную логику — понимание stock.picking экономит время и снижает риск ошибок при внедрении.
Готовы оптимизировать склад в Odoo?
Наша команда в Dasolo помогает компаниям внедрять и настраивать Odoo: мы делаем интеграции по API, разрабатываем кастомные модули и оптимизируем архитектуру данных, в том числе работу с моделями вроде stock.picking.
Если вам нужна помощь с внедрением Odoo, разработкой складских модулей или интеграциями — мы готовы подключиться и довести проект до результата. Запланируйте демонстрацию чтобы обсудить ваш проект.