ODOO: пример адаптации системы для компаний, которые занимаются оптовой торговлей пиломатериалами

В этой статье я хочу дать обзор примера построения системы обработки заказа (и всех связанных процессов) в ERP ODOO на примере компании которая заниматеся оптовой торговлей пиломатериалами. Сразу хочу отметить, что это не стандартная сборка, а уже модифицированная под специфику рассматриваемой отрасли ( в частности конкретной компании).

Некоторые моменты я буду подавать упрощенно особо не вдаваясь в детали.

Давайте рассмотрим основной бизнес процесс нашей компании. Она заниматеся оптовой торговлей пиломатериалам  — обрезной доской, которая может иметь разные физические параметры (такие как ширина, длина и толщина). В зависимости от физических параметров высчитывается номинальный объем 1 штуки, который служит вторичной единицой измерения (в данном случае это используется как справочная информация и не «протягивается» через склад).

Клиент размещает заказ на доски определенного размера (по длине, ширине и толщине) при этом компания имеет право поставить ему доски других размеров в пределах определенных допусков по длине, толщине и ширине. Заказ может выглядеть так (цифры условные):

Сорт	Толщина,мм	Ширина,мм	Длина, мм	Объем	Цена, USD	Допуски
А	35	90	2400	200	200	(-0+2 х-0+2 х+-0)

То есть клиент заказывает доски размера 35*90*2400, но мы можем ему поставить доски 37*92*2400 и все будет ок.

После размещения заказа клиента мы начинаем искать у какого поставщика мы можем закупить эти доски. Заказ может быть размещен как у одного поставщика, так и у нескольких. После выполнения заказом поставщиком к нему едет машина и забирает эти доски. В момент приемки проверяется качество досок и их соответствие заданным параметрам. Если все хорошо — доски пакуются в пачки, каждая из которых стикеруется, а затем эти пачки помещаются в контейнер (машину). Потом эти доски везутся в порт, погружаются на корабль и отправляются иностранному заказчику. В один заказ могут помещаться несколько контейнеров. В один корабль могут помещаться несколько заказов и соответственно много контейнеров.

Настройки карточки продукта

Как я уже говорил настройки карточки продукта много что определяют в системе. Давайте создадим карточку продукта и на ее уровне пропишем физические параметры нашей доски. Основной единицей измерения у нас будет м.куб, вторичной — штуки.

Задаем физические параметры нашей доски. Система сама нам расчитает необходимы параметры (такие как площадь и объем)

И указываем вторичную единицу измерения

Включаем для продукта учет по партиям

Закупки мы можем делать двумя способами: на наш склад, а затем отгрузка покупателю или через дропшиппинг. На уровне системы мы можем включить и тот и тот вариант. Но пока давайте исходить из предположений, что закупка делается на наш склад.

Оформление заказа на продажу

Итак покупатель у нас заказал 200 м.куб доски 35*90 A2400. Позиция заказа продаж в системе будет выглядеть следующим образом:

После выбора вторичной единицы измерения и указания количества в основной система пересчитывает по коэффициенту количество во вторичной единице. То есть 200 м.куб — это ориентировочно 26455 досок.

Для отслеживания рентабельности данного заказа под него можно создать аналитический счет и указать в этом заказе

Также под этот заказ продаж мы создадим «Глобальный заказ» на уровне которого будем отслеживать состояние этого заказа (об этом чуть ниже).

Оформление запросы цен (RFQ)

Итак у нас есть оформленный заказа от покупателя — теперь нам осталось найти поставщика. После того как поставщик найден мы можем создать «Запрос цен у поставщику» прямо из нашего заказа продаж (так как закупка у поставщика делается под конкретный заказ клиента). Для упрощения давайте предположим, что вес объем мы закажем у одного поставщика.

Информация о таком заказе отобразится в заказе на продажу

В позиции созданного запроса цен у нас передалась вся информация о заказанной продукции (физические параметры) и аналитический счет нашего заказа.

После подтверждения запроса цен — поставщик начинает работу над заказом и после того как он выполнен мы едем к нему забирать заказ.

Приемка товара у поставщика

Теперь у нас возникает необходимость создать в системе контейнер, в который мы будем упаковывать наш заказ. Это мы можем сделать либо в момент приемки товара у поставщика либо заранее. Давайте присвоим контейнеру номер нашего заказа продаж — /2021/0087 и будем его указывать в момент приемки товара.

Итак мы создаем пачки с определенным количеством досок (номер пачки содержит в себе номер контейнера и порядковый номер пачки), а потом эти пачки упаковываем в наш контейнер. Для некоторого упрощения я создал пачки по 5000 штук, и последнюю на 6455 шт, чтобы закрыть весь объем.

После подтверждения складского перемещения у нас в системе появляется контейнер, в котором накопилась информация из какого заказа на закупку он был создан и под какой заказ продаж он был закуплен, а также содержимое данного контейнера.

По контейнеру нам необходимо отслеживать целый ряд параметров, заполнить которые мы можем прямо в нем (приношу извинения за то, что некоторые поля непереведены)

А также нам необходимо отслеживать какие именно затраты мы несем по этому контейнеру (все эти затраты мы можем привязывать к аналитическому счету нашего заказа)

Реализация товара покупателю

Теперь возвращаемся в наш Заказ продаж. Позиция нашего заказа уже несколько видоизменилась и в нее подтянулся контейнер и  номера пачек, которые были закуплены у поставщика под этот заказ.

После подтверждения заказа продаж вся эта информация переносится в позиции исходящего складского перемещения, которое при подтверждении спишет указанные пачки со склада.

Но давайте не будем спешить списывать со склада, а вернемся к нашему контейнеру и к тому, что с ним происходит дальше.

Контейнер может иметь свой жизненный цикл и есть необходимость отслеживать в каком он сейчас находится состоянии (на каком этапе)

После того как он был забран у поставщика он может приехать на наш склад, а уже оттуда отправиться на погрузку в порт либо минуя наш склад отправится в порт на корабль. На один корабль может грузиться несколько заказов покупателя и соответственно много контейнеров. И нам еще необходимо остлеживать на каком корабле какие заказы находятся.

Затем в зависимости от условий поставки мы можем массово подтвердить/перевести на следующий статус все складские перемещения которые указаны в данном пакете (находяться на данном корабле).

Глобальный заказ

В то время когда мы проводили все эти операции наш созданный глобальный заказ накапливал на себе всю информацию связанную с данным заказом. В частности информацию о связанных закупках с данным заказом, движениях по складу и движения денежных средств. По сути это такой себе пульт по управлению данным заказом, который также имеет свой жизненный цикл.

А что в учете?

Ну и как же обойтись без учета. Себестоимость реализации мы можем отразить на аналитическом счете заказа либо после проведения реализации либо в момент проведения инвойса поставщика. Доходная часть отразиться после проведения инвойса покупателя. Если в связи с этим заказом были какие-то сопутствующие расходы мы можем их отобразить на аналитическом счете нашего заказа в момент фиксации таких расходов в учете.

В результате этого на аналитическом счете заказа накопиться информация о доходах и расходах по данному заказу. Все доходы и расходы будут отражаться в валюте компании и в нашем случае это будет гривна. Хотя некоторые операции мы проводили в USD (на дату проведения таких операций был установлен курс — 25 грн за 1 долл).

В самой аналитической записи будет содержаться информация об эквиваленте в другой валюте

Эту информацию можно использовать для построения управленческого отчета о прибылях и убытках, а также для анализа по целому ряду параметров. Например отслеживать рентабельность в разрезе стран, клиентов, групп товаров либо отдельных продуктов.

Подытожим

Это наверное первая статья где я начал расматривать адаптацию ODOO под специфику конкретного бизнеса. Я упростил некоторые моменты и рассказал не всю специфику бизнеса.  Как вы могли убедиться ODOO очень гибкая под запросы и может быть адаптирована практически под любой процесс. Но при такой адаптации не забывайте про то, что адаптировать нужно постепенно и не давать фантазии сильно разгуляться. Когда заказчику IT системы давать волю, а в голове у него либо Excel либо 1С, то жди беды. Какая бы система автоматизации не была классной, хаос в процессах заказчика и его неуемная фантазия может привести к неуспешному внедрению либо к тому, что системой просто станет невозможно пользоваться.

Если вам понравилась статья — ставьте лайк и ждите продолжения 🙂