Конечно, было бы идеально, если бы у нас всегда была возможность заказывать и доставлять от одной штуки (либо любой другой единицы использования), но в жизни этот идеал, к сожалению, не всегда достижим. Поэтому при расчете заказа мы должны учитывать влияние минимальной партии заказа для конкретного SKU и минимальной транспортной партии, установленной поставщиком или правилами компании.
В статье, посвященной расчету Целевого уровня буфера, я уже говорил о том, что нецелесообразно устанавливать ЦУБ на уровне менее чем полторы минимальной партии, установленной для конкретного SKU, и постарался дать этому объяснение.
Таким образом, работа при расчете заказа строится так:
- Мы ежедневно получаем информацию о потреблении конкретного SKU в звене ниже по цепи поставок.
- На основе этой информации мы рассчитываем потребность в пополнении. Если эта потребность меньше, чем установленная для SKU минимальная партия поставки, то мы не включаем ее в поставку, если эта потребность больше минимальной партии поставки, то мы округляем ее в соответствии с установленной кратностью поставки и включаем в поставку.
- По всем SKU, включенным в поставку, проверяется, достаточна ли сформированная поставка по сравнению с установленной минимальной транспортной партией. Если суммарная поставка меньше минимальной транспортной партии, то мы не выполняем заказ/поставку, если она больше или равна ей, то мы округляем ее до установленной кратности поставки и формируем заказ/поставку.
При длинных сроках пополнения иногда оказывается целесообразным формировать заказ поставщику, не дожидаясь, пока потребность превысит минимальную партию поставки или минимальную транспортную партию, можно установить некоторый понижающий коэффициент, при превышении которого заказ формируется и округляется вверх до минимальной партии поставки или минимальной транспортной партии. В практике наших проектов при контейнерных поставках этот коэффициент вполне работоспособен на уровне 80–85% от минимальной партии.
Желательно, чтобы контроль за выполнением этих условий выполняла автоматизированная система, так как количество SKU может быть значительным, а транспортная партия может меняться от поставщика к поставщику. Разработанный и реализованный нами программно-методический комплекс NET Stock[1] поддерживает все методические нюансы, о которых я здесь рассказывал.