Продолжая начатую тему по созданию и развитию самописной ERP системы, опишу контур логистики.
Бизнес
Бизнес компании построен на ремонте компьютерного оборудования и в упрощенном виде выглядит достаточно просто:
- Клиент приносит свой ноутбук в сервисный центр;
- Ноутбук осматривают (есть ряд требований вендора для начала ремонта), оформляют документы и направляют на ремонтную площадку сервисного центра;
- По оформленным заявкам отдел менеджеров определяет возможность выполнения ремонта, использовать складские запасы или необходимость заказа комплектующих;
- После того как необходимые детали для выполнения ремонта появляются на складе менеджер переводит заявку в статус «на выполнение»;
- На ремонтную площадку поступает ноутбук и необходимые запчасти для ремонта;
- Инженер выполняет ремонт, заменяя сломанные детали на рабочие;
- Ноутбук возвращается в сервисный центр, клиент оповещается о завершении ремонта;
- Оборудование возвращается клиенту;
Мы рассмотрим часть работы связанную со складскими запасами.
Склад
Есть центральный склад, на который поступают все детали, для всех сервисных центров, после чего распределяются согласно запросам для выполнения ремонтов.
Некоторые сервисные центры являются филиалами компании, другие авторизованы и являются независимыми организациями.
Гарантийный и платный ремонты
С платными все достаточно просто, мы «продаем» клиенту зап.часть и стоимость работ или это делает наш партнер.
В случае гарантийного ремонта, мы «выкупаем» деталь у вендора, выполняем ремонт, возвращаем сломанную деталь вендору после чего получаем оплату за ремонт и стоимость ранее выкупленной детали. Но… вендор устанавливает тот промежуток времени между выкупом детали и выполнением ремонта, а так же возвратом неисправной детали. Не уложились – штраф. Так, что требования к логистике достаточно жесткие, вплоть до нескольких дней между заказом детали и выполнением ремонта.
Конечно все еще запутаннее, поскольку не все детали требуется возвращать. Не всегда нужна именно деталь, в ряде случае существует «компонентный ремонт». Имеются требования к обязательному наличие «ходовых» деталей на сладе.
В первую очередь
Поскольку изначально было ни чего не понятно, наша группа встала со стульев и пошла ножками по всем отделам компании.
Итог небольшая схема А3 всех, почти, внутренних и внешних процессов.
Ядро логистики
В основе системы управления складом находиться небольшой набор логики:
- нужно хранить список деталей, список всех сервисных центров, список перемещений деталей;
- реализовать выполнение повторяющихся действий по перемещению;
Достаточно четырех операций:
- «приход» (+Qty);
- «расход» (-Qty);
- «создание долга» (Qty-);
- «возврат» (Qty+).
Первые две операции достаточно логичны мы «приходуем» на склад и размещаем на полках. Когда же деталь направляется в сервисный центр, мы оформляем «расход».
Оставшиеся две операции нужны, поскольку после отправки в сервисный центр детали мы ожидаем от них возврата изъятой из оборудования сломанной. Вполне логично, что мы погасим долг сервисного центра, как только сломанная деталь придёт к нам.
Магия цифр
Рассмотрим самую интересную часть ядра работы логистики – перемещение деталей.
Любая деталь в системе имеет уникальный идентификатор SPI(Spare Part Information)
Приход и расход простые операция. Все что поступает на склад увеличивает количество деталей, все что уходит уменьшает.
Для этого достаточно поля QtyRest
Неплохо знать, сколько вообще приходило деталей на слад, для отчетов. К тому же, для формирования складских остатков за период нужно знать время выполненных операций.
Появляются поля Qty, EventDate
Данной схеме недостает «скорости», поскольку в большинстве случаев нас интересуют актуальные данные. Да и с операциями, у которых QtyRest = 0 тоже нет смысла работать.
Заменяем поле EventDate на IsOpen, OpenDate, CloseDate(IS NULL)
Логика работы двух операций можно записать как:
Приход добавляет новую запись, в которой указывается, сколько деталей пришло (Qty) и сколько осталось (QtyRest=Qty). Операция является «отрытой», т.к. имеет не нулевой остаток (IsOpen=true)
Расход также добавляет новую запись, в которой указывается, какое количество деталей уходит (-Qty). Остатков для отрицательной операции не может быть (QtyRest=0). Расходная операция уменьшает количество (QtyRest) в приходе.
Если у операции QtyRest=0, то она «закрывается» IsOpen=false, CloseDate=GETDATE().
Так же нельзя уйти в отрицательный остаток (QtyRest<0), это не логично и используется в системе для других целей.
На что стоит обратить особое внимание:
- любая операция это новая запись (INSERT). Это важно, поскольку позволяет строить достаточно сложные отчеты, опираясь на даты;
- мы работаем только с операциями IsOpen=true (их относительно не много, по сравнению с общей историей), что позволяет использовать секционирование;
- расходная операция может быть выполнена только в случае достаточного количества деталей в открытых приходных операциях;
Продолжение следует.
Мы рассмотрим две других операции «создание долга» и «возврат», понятие «типы складов» и действия «перемещение между складами»
Автор: Emiya
