Какие методики резервирования товаров используются в вашей компании (или вашими клиентами)?

[kashperuk]

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

Disclaimer
Это все, ессно, только в плане обсуждения, то есть описанное здесь не обязательно попадет в АХ след. версии.



Вопрос 1
Когда, кем, и для чего вообще у вас резервируются товары?
В каких случаях резервации меняются? (К примеру, если появляется более ранний заказ, или заказ от более приоритетного клиента, т.д.) Как это делается? (Вручную? Кем?)
Есть ли у кого-то какой-то автоматический механизм приоритизации одной резервации над другой?

Вопрос 2
Какие товары разрешено резервировать? (К примеру, только физически доступное, или также и ожидаемые приходы) Разделяете ли Вы приходы в результате внутренних перемещений и внешних процессов (производство, закупки)? (К примеру, можно резервировать то, что есть на складе + то, что должно приехать в течении 1 дня с других складов.)
Бывает ли необходимость жесткой резервации строк заказа против какого-то конкретного заказа на покупку (зарезервированного в заказанных)? Если да, то зачем?

Вопрос 3
Как и кто уведомляется в случае конфликтов? К примеру, если я хочу забрать на свой заказ какие-то товары, которые уже были зарезервированы, смогу ли я это сделать? Кто в таком случае будет уведомлен и как?

Вопрос 4
Какие модификации функциональности резервирования у вас установлены? С какой целью?

[EVGL]

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

Наверное, это - не то, что вы хотели услышать.

[Ivanhoe]

Из наболевшего - развести резервирование "логическое" (с точки зрения продавца) и "физическое" (с учетом всех складских аналитик). Как пример - продавец резервирует 100 штук на складе, а то и на сайте (логическое резервирование), а склад отгружает из нужных ячеек после активации отгрузки (физическое резервирование).

По остальным пунктам постараюсь ответить в рабочий день, у нас тут праздники

[Serg]

Цитата:

Сообщение от Ivanhoe

Из наболевшего - развести резервирование "логическое" (с точки зрения продавца) и "физическое" (с учетом всех складских аналитик). Как пример - продавец резервирует 100 штук на складе, а то и на сайте (логическое резервирование), а склад отгружает из нужных ячеек после активации отгрузки (физическое резервирование).

По остальным пунктам постараюсь ответить в рабочий день, у нас тут праздники

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

[FFelix]

Пожалуйста, поясните что вы имеете в виду под "логическим" и "физическим" резервированием? Хочу точно понять предмет такой важной дискуссии.

Цитата:

Сообщение от Ivanhoe

Из наболевшего - развести резервирование "логическое" (с точки зрения продавца) и "физическое" (с учетом всех складских аналитик). Как пример - продавец резервирует 100 штук на складе, а то и на сайте (логическое резервирование), а склад отгружает из нужных ячеек после активации отгрузки (физическое резервирование).

[Raven Melancholic]

Цитата:

Вопрос 1
Когда, кем, и для чего вообще у вас резервируются товары?
В каких случаях резервации меняются? (К примеру, если появляется более ранний заказ, или заказ от более приоритетного клиента, т.д.) Как это делается? (Вручную? Кем?)
Есть ли у кого-то какой-то автоматический механизм приоритизации одной резервации над другой?

Фирма работает как на выпуск уникальных индивидуальный товаров, так и для продажи оборудования, произведенного на склад. То оборудование, которое производится на склад, резервируется (на определенное количество дней - по истечении периода, если не было оплаты, резервы автоматически снимаются). Резервируют оборудование сотрудники отдела продаж. Причем, резервирование по каждой строке не очень удобно, поэтому реализована отдельная форма резервирования, в которой можно резервировать номенклатуру сразу по всему заказу на продажу (производственному заказу, заказу на перемещение и т.п.). Изменения производятся вручную, каких-то приоритетов нет.
Вопрос 2

Цитата:

Какие товары разрешено резервировать? (К примеру, только физически доступное, или также и ожидаемые приходы) Разделяете ли Вы приходы в результате внутренних перемещений и внешних процессов (производство, закупки)? (К примеру, можно резервировать то, что есть на складе + то, что должно приехать в течении 1 дня с других складов.)
Бывает ли необходимость жесткой резервации строк заказа против какого-то конкретного заказа на покупку (зарезервированного в заказанных)? Если да, то зачем?

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

Цитата:

Вопрос 3
Как и кто уведомляется в случае конфликтов? К примеру, если я хочу забрать на свой заказ какие-то товары, которые уже были зарезервированы, смогу ли я это сделать? Кто в таком случае будет уведомлен и как?

Конфликты разруливаются вручную. Уведомления высылаются ответственным продавцам за день до окончания срока резервирования и в день снятия резервов (точнее в ночь) при помощи стандартного механизма уведомлений.

Цитата:

Вопрос 4
Какие модификации функциональности резервирования у вас установлены? С какой целью?

В основном, модификации касаются интерфейса резервирования, в том числе,

• резервирования через несколько компаний. Из того, что затрагивает ядро:
• классификация номенклатуры с точки зрения правил резервирования.
• автоматическое резервирование не только на складе отгрузки, но и на складах пополнения.

Пытались реализовать то, о чем говорит Ivanhoe, но пока отложили. Хотя, на мой взгляд, это очень даже востребовано.

[kashperuk]

Цитата:

Сообщение от Raven Melancholic

Причем, резервирование по каждой строке не очень удобно, поэтому реализована отдельная форма резервирования, в которой можно резервировать номенклатуру сразу по всему заказу на продажу (производственному заказу, заказу на перемещение и т.п.). Изменения производятся вручную, каких-то приоритетов нет.

А почему в таком случае не используете автоматическое резервирование?

Цитата:

Сообщение от Raven Melancholic

автоматическое резервирование не только на складе отгрузки, но и на складах пополнения.

А можно про это поподробнее? Я что-то не понял, в чем модификация.

[Raven Melancholic]

Цитата:

Сообщение от kashperuk

А почему в таком случае не используете автоматическое резервирование?

У нас отгрузка идет не с тех складов, на которых хранится номенклатура (включая и филиалы и Москву). Причем, отгрузочный склад это не просто виртуальный склад, представляющий собой дебакадер склада хранения готовой продукции, а именно отдельный склад. Хранится ГП и резервируется на складе хранения, заказ на продажу идет со склада отгрузки, перед отгрузкой происходит перемещение со склада ГП на склад отгрузки. Автоматическое резервирование резервирует только на складе, указанном в строке заказа (точнее зависит от настройки аналитики) либо на любом, то есть, без учета настроек пополнения. Как-то это можно разрулить сайтами (правда не уверен, что сильно поможет), но у нас DAX4.

Цитата:

Сообщение от kashperuk

А можно про это поподробнее? Я что-то не понял, в чем модификация.

В принципе, ответ тот же.

[fed]

Цитата:

Сообщение от kashperuk

А почему в таком случае не используете автоматическое резервирование?



А можно про это поподробнее? Я что-то не понял, в чем модификация.

Типичная ситуация: Фирма имеет один склад отгрузки (в центре города, с хорошими путями подъездами,большим количеством эстакад для погрузки/выгрузки, но маленькими площадями) и несколько складов хранения (с большими площадями, но на выселках и с плохими путями подъезда). В идеале, для автоматизации подобной ситуации надо было бы использовать сводное. Типа сейлы создают заказы, потом сводное (которое каждые 2-3 часа запускают) создает плановый заказ на перенос, потом его утверждают и тп.
Но на практике - только из за этого покупать модуль сводного планирования не целесообразно. Поэтому зачастую просто делают какую-то доработку которая при резервировании позволяет автоматически создать некий журнал переноса с удаленного склада на склад отгрузки и резервирует в транзите между строкой заказа и строкой журнала переноса (ну или заказа на перенос).
Мне, правда, такой подход не очень нравится. Мы для этого использовали разделение сейлового и складского резервирования. Грубо говоря - сейлы резервируют на уровне только сайта. Далее, время от времени, складские нажимают некую кнопочку, по которой система проверяет все заказы в неком статусе и по тем из них, по которым зарезервировано больше чем есть на складе отгрузки, формирует строки журнала переноса. Как-то такой подход покрасившее малость...

[Serg]

Цитата:

Сообщение от fed

Мы для этого использовали разделение сейлового и складского резервирования. Грубо говоря - сейлы резервируют на уровне только сайта. ...

Fed, а можешь рассказать поподробней суть доработки сейлового резервирования? Мы что-то такое сделали, на уровне сайта и получается, что если кто-то укажет склад или партию в другом заказе, то общая сумма резерва может просто удвоиться или утроиться, так как контроль остатка идет только по InventDimId.

[fed]

Цитата:

Сообщение от Serg

Fed, а можешь рассказать поподробней суть доработки сейлового резервирования? Мы что-то такое сделали, на уровне сайта и получается, что если кто-то укажет склад или партию в другом заказе, то общая сумма резерва может просто удвоиться или утроиться, так как контроль остатка идет только по InventDimId.

Мы в inventSum добавили два разных поля для двух разных видов резервов. Точнее говоря - для сейлового резервирования мы использовали стандартные поля, а для складского - нестандартные. Далее мы для сейлов сделали отдельную форму "В наличии" в которой показывались остатки в разрезе сайта и партии, с учетом сейлового резервирования. Для складских сделали другую форму в наличии, которая показывала остатки с учетом складского резервирования и по всем складским аналитикам.
На какой-то стадии обработки продажи (по созданию picking list по моему), система автоматически пыталась создать складской резерв поверх сейлового. А в момент физического списания по packing slip, система контроллировала оба остатка. Во первых, проверялось что после списания для данного сайта и партии остаток (как физическое наличие - сейловый резерв) не упадет ниже ноля. Во вторых проверялось для для полного набора складской аналитики после списания, остаток (как физическое наличие - складской резерв) не упадет ниже ноля. Если хотя бы одно из этих условий не выполнялось - операция откатывалась.

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

[Ivanhoe]

Цитата:

Сообщение от kashperuk

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

Надеюсь, не только "оптимизация", но и "развитие функциональности"?
Постараюсь ответить по опыту наиболее характерных проектов.

Цитата:

Сообщение от kashperuk

Вопрос 1
Когда, кем, и для чего вообще у вас резервируются товары?
В каких случаях резервации меняются? (К примеру, если появляется более ранний заказ, или заказ от более приоритетного клиента, т.д.) Как это делается? (Вручную? Кем?)
Есть ли у кого-то какой-то автоматический механизм приоритизации одной резервации над другой?

Говорим только про товары или вообще про номенклатуры?
Как правило резервирование делается двух видов:
1. Под продажу. Делает продавец заранее, чтобы гарантировать клиенту отгрузку (не забываем, что очень часто доставка имеет реальную цену и просто так гонять машину никто не будет). Как правило, резерв вешается не определенный период, очень часто есть доработка по автоматическому снятию резерва по истечении этого периода. С явной приоритизацией резервов не сталкивался, разве что когда запас нулевой и есть некий документ "заказа", такие "заказы" превращаются в реальный резерв по приходу ТМЦ, как правило по методу ФИФО (понятно, что это все доработки).
2. Технический резерв. Выполняется под отгрузку (shipment), при разноске отгрузочной (picking list без WMS), при работе с журналами инвентаризации, переносами и т.п. Т.е. этот резерв фиксирует явные складские аналитики (в том числе, чтобы вручную не указывать) и блокирует ТМЦ для других движений.

Цитата:

Сообщение от kashperuk

Вопрос 2
Какие товары разрешено резервировать? (К примеру, только физически доступное, или также и ожидаемые приходы) Разделяете ли Вы приходы в результате внутренних перемещений и внешних процессов (производство, закупки)? (К примеру, можно резервировать то, что есть на складе + то, что должно приехать в течении 1 дня с других складов.)
Бывает ли необходимость жесткой резервации строк заказа против какого-то конкретного заказа на покупку (зарезервированного в заказанных)? Если да, то зачем?

Как правило, в основном используется физически доступное количество (причем, частенько приходится его менять, исключая, например, зарегистрированное, но не принятое количество).
Если же возникает потребность резервировать в ожидаемых приходах, то тут как правило стандартом не обходится и используется какое-нибудь "решение" по цепочкам поставок (бронирование): возможность "заказать" ТМЦ, возможность консолидировать заказы, автоматическое распределение резервов по факту прихода на основании исходных заявок, возможность перемещать ТМЦ вместе с резервом (гарантируем резерв по всей цепочке поставок), контроль на продажу только в рамках исходного документа продажи. При этом знаю примеры, когда использовалось не резервирование, а формирования уникального номера партии в заказе на продажу и все движение ТМЦ шло под этой партией. Также в рамках такого "решения", как правило, необходимо уметь "обмениваться" резервами между документами / авторами; обычно хочется разделять ожидаемые закупки от ожидаемых других приходов (инвентаризация, перенос и т.п.).

Цитата:

Сообщение от kashperuk

Вопрос 3
Как и кто уведомляется в случае конфликтов? К примеру, если я хочу забрать на свой заказ какие-то товары, которые уже были зарезервированы, смогу ли я это сделать? Кто в таком случае будет уведомлен и как?

Встречался с таким только на проектах, где использовалось наше "решение" по цепочкам поставок: есть возможность "запросить" передачу резерва, при этом идет оповещение владельцу и возможность "передать". Все это, конечно, доработки.

Цитата:

Сообщение от kashperuk

Вопрос 4
Какие модификации функциональности резервирования у вас установлены? С какой целью?

В принципе, основные модификации описал выше. Уже отвечал ранее: очень бы хотелось от MS в стандарте разделить резервирование "логическое" и "физическое" (я даже надеялся, что это будет в 2012 с вводом разделения складских аналитик на три группы). Без этого практически не внедрить WMS на нормальном складе.
Ну и было бы вообще праздником получить возможность "логические" резервы уметь двигать человеческим способом (маркировку не предлагать между складскими аналитиками (склады, ячейки и т.п.).

[kashperuk]

Цитата:

Сообщение от Ivanhoe

С явной приоритизацией резервов не сталкивался, разве что когда запас нулевой и есть некий документ "заказа", такие "заказы" превращаются в реальный резерв по приходу ТМЦ, как правило по методу ФИФО (понятно, что это все доработки).

А чем это отличается от "Зарезервированно в заказанных"? В смысле, в чем доработка?

[Ivanhoe]

Цитата:

Сообщение от kashperuk

А почему в таком случае не используете автоматическое резервирование?

А можно про это поподробнее? Я что-то не понял, в чем модификация.

1. Отвечу со своей стороны. Автоматическое резервирование срабатывает "один раз" при смене этого метода. Если мы уже работали с заказом и в какой-то момент нужно заново все зарезервировать (скорее всего то, чего не было в первый раз) - то нужна кнопочка.
2. Скорее всего есть некая цепочка поставок. Отгрузка (заказ на продажу) на складе "Филиал", а товар есть на складе "РЦ", нужен резерв именно на "РЦ". И потом перемещение с "РЦ" на "Филиал" и только потом отгрузка клиенту.

Цитата:

Сообщение от kashperuk

А чем это отличается от "Зарезервированно в заказанных"? В смысле, в чем доработка?

Зарезервировано в заказанных (если не пользоваться маркировкой) работает как общая копилка. И первый попавшийся приход обновит первый попавшийся резерв. А на практике нужен резерв в конкретном ожидаемом приходе. Почему не используется в таком случае маркировка - отдельный вопрос

[twilight]

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

[Ivanhoe]

Цитата:

Сообщение от twilight

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

Это есть в уже "стандартном" решении от Microsoft Process Industries:
1. Отдельная настройка в разрезе клиентов (групп, всех) и номенклатур (групп, всех) по допустимым срокам.
2. В партии и срок годности, и "best before".
3. При резервировании в зависимости от настройки (какую дату смотреть), клиента и номенклатуры подбираются партии. Все это названо резервирование по FEFO.

P.S. правда работает это в "обычном" резервировании, если использовать контур WMS, то про него разработчики, похоже, забыли

[twilight]

Цитата:

Сообщение от Ivanhoe

P.S. правда работает это в "обычном" резервировании, если использовать контур WMS, то про него разработчики, похоже, забыли

А у нас как раз эта доработка сделана для проектов по WMS )

[Ivanhoe]

Как должно быть:
1. Логическое: продавец видит на складе 1000 штук, резервирует 100. При этом ему все равно какая партия и в какой ячейке лежит. После резерва любые 900 штук могут быть списаны со склада - по любой партии и из любой ячейки.
2. Физическое: кладовщик активирует отгрузку по заказу продавца. Система для 100 штук ищет нужные партии (например, по дате) и ячейки комплектации. После этого никто не может "забрать" зарезервированные 100 штук из этих партий и ячеек, только отгрузка по этому же заказу.

Как есть в Dynamics AX 2009:
После резервирования заказа на продажу, товар резервируется в конкретной партии и в конкретной ячейке комплектации.
После этого никто не может забрать товар из этой ячейки / партии, а ведь между резервом и отгрузкой может быть n-дней, в течении которых кладовщикам приходится брать товар из других ячеек (буферных, используя каждый раз погрузчик).
Между резервом и отгрузкой, возможно, потребуется оформить инвентаризацию - и опять же товар в ячейке зарезервирован, и чтобы его списать надо а) снять резерв б) обеспечить чтобы его никто не забрал в) списать товар по инвентаризации г) обеспечить по заказу на продажу новый резерв.

[fed]

Цитата:

Сообщение от Ivanhoe

Как должно быть:
1. Логическое: продавец видит на складе 1000 штук, резервирует 100. При этом ему все равно какая партия и в какой ячейке лежит. После резерва любые 900 штук могут быть списаны со склада - по любой партии и из любой ячейки.
2. Физическое: кладовщик активирует отгрузку по заказу продавца. Система для 100 штук ищет нужные партии (например, по дате) и ячейки комплектации. После этого никто не может "забрать" зарезервированные 100 штук из этих партий и ячеек, только отгрузка по этому же заказу.

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

[Ivanhoe]

Цитата:

Сообщение от fed

Я конечно потом напишу поподробнее, но я в свое время тоже делал эту ошибку и считал что кладовщик может что-то резервировать только по заказу продавца.

Ни сколько не спорю, но и ошибку не делаю
Расписал самый простой пример, где понятно различие логического и физического резервирования (еще говорят "мягкое резервирование", "жесткое резервирование").

Про складские операции уже писал выше: см. про "Технический резерв".