_bobs_ustinovПоэтому в моем варианте алгоритма ситуация, когда товар не приехал, вообще никак не обрабатывается . Алгоритм просто "не видит", полностью приехало перемещение или нет - он никак не анализирует те резервы, которые были и уже учтенные перемещения - это сложно и долго. Он просто резервирует товар там, где найдет. И если в перемещении с центрального склада товар не приехал, но на центральном складе этот товар есть - зарезервирует на центральном складе и товар приедет следующим перемещением.

ок, а если товара нет нигде? ни на каком складе
или есть у партнера, но за совсем другие деньги
а алгоритм и знать не знает, что часть товара не приехала
Алгоритм проверит все "места", где товар можно зарезервировать. В том числе в заказах закупки (с точки зрения алгоритма это просто еще один "склад").
Если же товара вообще нигде нет, то создается строка резервирования без привязки к конкретному остатку с типом резерва "Надо закупить".
Не факт, что товар реально будет закуплен, если сформировался такой резерв - это просто означает, что товара нет.

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

Все товары делятся на несколько групп, например:
- Стабильный хороший спрос
- Покупают редко, но на складе держать надо
- Поставляем под заказ
Для каждого товара также можно предусмотреть пометки "Уточнять цену", "Уточнять условия поставки", "Больше не закупаем (распродажа остатков)"

Если товар относится к категории “Стабильный хороший спрос” и запрашиваемое количество не превышает некоторого предела (например, 20% от квартального объема продаж) - просто включаем это количество в очередной заказ поставщику. Теоретически менеджер по закупкам вообще может не видеть этого заказа - система сама сформировала заказ, сама отправила поставщику, получила от него подтверждение и перевела заказ в статус подтвержденный.
Если товар относится к категории “Покупают редко, но на складе держать надо”, то менеджер по закупкам просматривает такие запросы, часть из них утверждает к закупке сразу, часть отправляет на утверждение к менеджеру по продажам. Например, поставить сможем только через два месяца - клиент согласен ждать?
Если товар относится к категории “Поставляем под заказ”, то кроме отдельного подтверждения от менеджера может потребоваться утверждение директором филиала или предоплата от клиента. Если клиент откажется от заказа, то такой товар “зависнет”, и к подобным заказам особый контроль.

Если Заказывается большое количество (например, 100 штук, а всего за год обычно продаем 40 штук), то заказ получает статус “поставка под заказ” и также утверждается отдельно. Такой статус не блокирует продажи товара по обычным (мелким) заказам. Если у нас на всех складах 30 штук товара, а заказали 100 штук - при обычном статусе все они будут зарезервированы. Но при поставке под заказ алгоритм резервирования сформирует резерв “Надо закупить” на все 100 штук, а 30 останутся в свободных остатках. И если завтра придет клиент с заказом на 2 штуки (обычным заказом) - под него зарезервируются товары из 30 штук, которые в наличии.

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

Например, в системе числится 1 штука в наличии. Клиент её заказал. На следующий день оказалось, что товара нет (он бракованный). У товара категория “Поставляем под заказ” и пометка "Больше не закупаем (распродажа остатков)" - менеджер должен или получить сообщение, или увидеть в отчете, что заказ выполнить невозможно. То есть в заказе есть строка, по которой есть резерв с типом "Надо закупить”, а товар имеет пометку "Больше не закупаем (распродажа остатков)". И далее созванивается с клиентом и или отменяет заказ, или меняет товар на аналог, или оказывается, что клиенту очень нужен вот именно этот товар и он готов заплатить нормальную цену, а не цену распродажи - тогда товар закупают под заказ, несмотря на все статусы. И если создали заказ поставщику - алгоритм резервирования тут же создаст в нем резерв под этот заказ продажи, несмотря на все статусы на товаре.
Похожим образом “отлавливаются” все заказы, по которым люди должны принимать дополнительные решения.

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

_bobs_ustinovпропущено...

Сталкивался, но "это все делается вручную, по телефонному звонку"
Я ни разу не сталкивался с ситуацией, что в системе реализуются более сложные правила, чем FIFO. Всегда хватало связки "автоматическое FIFO" + "ручные корректировки".
Я именно про это и спрашивал - когда возникает отклонение, изменение (отмена) резервов - полностью ручной процесс, или автоматом отменяются более поздние резервы (по FIFO)?

вот вам правила, которые мы применям в разных сочетаниях (как правило несколько правил с весовыми коэфф):
1. заказ оплачен/не оплачен
2. ПДЗ клиента/среднемесячный оборот
3. скидочная группа клиента (косвенный признак объемов и нашей лояльности к клиенту)
4. спецпризнак заказа "не снимать резерв"
В том варианте, что я делал, дополнительные "статусы" заказов / клиентов не участвовали.

Но добавить такие правила относительно несложно. Если есть формула (например "несколько правил с весовыми коэфф"), которая переводит все эти признаки в итоговое число "приоритета", так чтобы можно было сказать, что заказы с приритетом "105" надо всегда обрабатывать раньше, чем заказы с "приоритетом" "108" (так как 105 < 108), то можно просто включить в алгоритм сортировку не по одному полю "приоритет FIFO", а по двум - "приоритет заказа", "приоритет FIFO".
Для моего алгоритма важно, чтобы все строки, которые надо зарезервировать, можно было однозначно отсортировать по приоритету. А будет сортировка по одному полю, по двум или по нескольким полям - не важно.

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

_bobда много чего не учтено
и самая главная тема с резервами даже не затронута! а ведь это бич всех дистрибьюторов!
давайте сыграем в угадайку, а я завтра в 10 часов напишу что имел в виду
_bob, как будет свободное время - напишите про "главную тему". А то заинтриговали, и молчите. Интересно же! :)

_bob на мой взгляд, в резервировании товара на складе самый важный момент - это контроль и ограничение резервов, т.к. в резервах замораживаются огромные деньги

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

пытались решать проблему технически установкой правил, лимитов, но пока не прислушались ко мне и не поняли, что проблема решается организационными мерами - не искоренили
скорость оборота... как много в этих звуках...
Да, если не контролировать резервы с точки зрения их обоснованности - это ЛЕГКО превращается в большую проблему.

Согласен, в первую очередь проблема должна решаться на административном уровне.

Проблему "неоправданных" резервов можно разделить на две части.
1. Запасы на филиалах. Часто директора филиалов имеют полномочия принимать решения по своим складским остаткам. И практически всегда это завершается плохо. Причин несколько:
Во первых, у них нет ни времени, ни знаний, чтобы правильно спланировать и управлять запасами.
Во вторых, редко контролируется скорость оборота именно локального склада. Просто поделить продажи филиала за период на средние остатки за период нельзя, но это часто не понимают даже "менеджеры" по управлению запасами. Да и функции локального склада не только в обеспечении продаж, но и быть своеобразной витриной - "Вот, смотрите как выглядит железяка. Вам 10 штук? Ну, столько мы на локальном складе не держим, завтра привезем с центрального склада."
Часто директора других филиалов, чтобы что-то взять из товара себе, должны согласовать с директором филиала, где лежит товар. А ему очень легко сказать - нет, это я держу для любимого клиента - "и начинает процветать коррупция: дай мне то, а я тебе дам вот это и т.д." В результате довольно большие запасы на филиалах лежат мертвым грузом. Технически в системе этот товар может и не числиться как "резерв", а по факту является резервом - ведь другие продавцы не могут получить к нему доступ.
2. Резервы "на всякий случай" на уровне менеджеров. Когда "весь ходовой товар на резервах. причем менеджеры из резервов устраивают персональные склады и начинает процветать коррупция: дай мне то, а я тебе дам вот это и т.д."


По большому счету, решение есть только одно - резерв может быть только под продажу . Нельзя просто "зарезервировать" товар, потому что тебе захотелось иметь его в резерве. И надо достаточно жестко следить за резервами (иначе будет много левых заказов с резервами).
Во первых, легко строится отчет - сколько по менеджеру товара в резерве и какие у него продажи. Это позволяет быстро выявить любителей резервировать без оснований.
А во вторых, надо четко контролировать сроки по каждому заказу - сколько дней лежит товар в резерве. Легко сделать отчет, показывающий, когда и что резервировалось.
И технические ограничения - просто резерв держится максимум 2-3 дня. После чего должен автоматически сниматься с резерва. Если дольше - это уже исполнение заказа. Товар не просто лежит, а перемещается с других складов. И опять же - если товар переместили и заказ готов к отгрузке больше чем 2-3 дня - надо спрашивать у менеджера, в чем дело? Если клиент отказался от заказа - надо закрыть заказ (и резерв). Если надо чуть больше, чем 2-3 дня - пусть клиент как минимум заплатит предоплату.

С филиалами во многом аналогично.
Первое - если у них нет заказа продажи - их товар может продать любой филиал без всякого согласования. То есть резервировать и забирать товар могут все филиалы без ограничений, и директор филиала обязан собрать и отгрузить перемещение на все запрошенные позиции (по крайней мере спрашивать будут с него, а не кладовщика))). Но если такое правило еще не внедрено - крику будет... Потом, конечно, привыкают, но только потом...
Второе - установить лимит на хотелки. Например - у тебя на складе будут лежать вот эти УУУ тысяч наименований в вот таких количествах, можешь набрать еще товара на склад по своему усмотрению на ХХХ тысяч денег. И всё. Есть дополнительные пожелания по товару сверх этой суммы - обоснуй необходимость. У некоторых действительно такая необходимость есть, и им надо дополнительно увеличить склад, но обычно это максимум пара десятков наименований.

Правда, к самому алгоритму все эти контроли резервов не относятся. Задача алгоритма - просто создать резервы под те заказы, под которые надо зарезервировать товар. А контроль того, чтобы менеджеры не резервировали лишнее - это отдельная задача. Для такого контроля система должна выполнить несколько правил:
- Автоматически отменять "бланковые" резервы через некоторое время (2-3 дня) - ставить на заказ признак "не резервировать" или закрывать заказ. У менеджера должен быть отчет, какие резервы будут сняты - чтобы можно было уточнить у клиента статус заказа.
- Автоматически резервировать на всех складах (чтобы не хранились на филиалах залежи товара, которые вроде есть, но продать их нельзя).
- Позволять формировать несколько отчетов по резервам, в частности по срокам резервов (например, показать только те заказы, по которым товар зарезервирован 10 и более дней).