В этой статье я хочу дать обзор примера построения системы обработки заказа (и всех связанных процессов) в 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С, то жди беды. Какая бы система автоматизации не была классной, хаос в процессах заказчика и его неуемная фантазия может привести к неуспешному внедрению либо к тому, что системой просто станет невозможно пользоваться.
Если вам понравилась статья – ставьте лайк и ждите продолжения 🙂
