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

[kashperuk]

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

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



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

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

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

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

[EVGL]

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

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

[Ivanhoe]

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

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

[Raven Melancholic]

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

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

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

[Ivanhoe]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[Serg]

Цитата:

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

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

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

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

[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 )

[FFelix]

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

Цитата:

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

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

[Ivanhoe]

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

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

[fed]

Цитата:

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

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

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

[Ivanhoe]

Цитата:

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

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

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

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

[fed]

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

1. Как тут уже много раз обсуждалось - есть два вида резервирования, сейловое и складское.Сейловое запрещает перемещение товара за пределы организации (то есть - разрешает его переносить, но запрещает его списывать или продавать). Складское - запрещает любые движения товара, но тем не менее, не запрещает его резервировать по сейловому. Замечу также, что меня очень веселят вопросы насчет приоретизации резервирования Ты там напомни своим коллегам, что резервирование в заказанных и маркировка являются отражением отношения покрытия в сводном плане. Если у тебя вдруг появился более приоритетный заказ, то надо не механизм резервирования править, а механизм сводного планирования. Чтобы это сводное планирование в рамках одной номенклатуры например, порушила бы все связи покрытия, перетасовала бы данные о покрытии, а потом бы обновила маркировки и резервирования в связанных складских проводках. Более того - в системе вообще не хватает механизма, который бы позволял восстановить или создать резервирование на основании данных о покрытии. То есть: В штатной ситуации, когда ты фирмишь плановые заказы, система генерирует маркировки между складскими проводками по покрывающей и покрываемой чистым потребностям. Но вот если ты например из за какой-то внештатной ситуации создал некоторые заказы в ручную (или если у тебя пользователи направили ручками созданные заказы), то сделующее сводное планирование создаст по таким заказам покрытие, но никаких маркировок и резервов уже не будет создано. До какой-то степени, ситуацию лечит развертывание (Explosion), но проблема в том что штатное развертывание создает резервы и маркировки только для данной складской проводки. (А хотелось бы какой-то механизм который бы делал это для космбинации маски номенклатуры и маски складских аналитик). Я подобный инструмент делал, но до ума не доводил (по крайней мере масок и настроек я там не делал).

2. Резервирование в заказанных и резервирование на складе обычно жестко разделяют. Подход стандартной аксапты, при котором можно незаметно для пользователя зарезервировать 10 штук на складе и 5 штук в транзите, почти никого не устраивает. Обычно стандартную форму резервирования используют только для резервирования на складе. (Резервирование в транзите отключают галочкой). Для резервирования в транзите обычно делают свою отдельную форму, в которой выводят приходные складские проводки в статусе "Заказано" и напротив каждой позволяют поставить количество. Дальше все это превращается в маркировки и в статус "Зарезервированно в заказанных". В типичной торговой организации, сейл ДОЛЖЕН уметь четко сказать своему клиенту когда приедет его товар. Для этого надо четко поддерживать "жесткой резервации строк заказа против какого-то конкретного заказа на покупку". Если клиенту сказать что товар зарезервирован в заказанных безотносительно заказа на закупку и когда-то (ну по крайней мере до наступления конца света) приедет, то клиент пойдет к другому поставщику. Кроме того - контроль резервирования в заказаных обычно делают не по дате, а по статусу строки закупки (которого в стандарте нету). То есть - например по каким-то номенклатерам можно резеровать товар в транзите только после того как поставщик подтвердил прием заявки на поставку, по каким-то - только после того как поставщик нам накладную по факсу отправил и тп. Таким образом, возможность резервирования определяется не датой поставки, а ее вероятностью.

3. Была сделана форма переноса резервов с чужих заказов. Ну то есть - можно в своем заказе нажать на пимпочку и вывести вражеские резервы по той же номенклатуре и против каждого поставить количество. Но в каждой складской проводке пишется ответственный продавец из шапки заказа и отдельно настроены жесткие права - кто у кого может тырить резервы. Кроме того - ведется протокол переноса резервов (и вообще всех операций с резервами).
4. Во первых мы разделили понятие сейлового и складского резервирования. Честно говоря, разделили не совсем удачно, поскольку на первых порах не понимали что складское резервирование может случаться вообще без сейлового. В конце концов (уже после того как проект запустился и года два проработал), их окончательно разделили, но реализацию нельзя назвать удачной. Но как-то работает. Во вторых - мы ввели понятие пула резервов. Он начал свою жизнь просто как удобный механизм перекидки резервов. Просто можно в строке заказа кликнуть на кнопочку "Взять резерв из пула" и "Отдать резерв в пул". У пула есть права доступа. Снимать резервы я могу в любой пул, а забирать резервы могу только из пула, к которому у меня есть права доступа. В дальнейшем мы завели иерархию пулов - пул сейла, пул отдела, пул рабочей группы (может состоять из нескольких сейлов). Далее мы сделали автоматическое резервирование в транзите. После того как статус строки закупки достигает некого значения, товар автоматически резервируется в заказанных между пулами резервов в соответствии с некими настраиваемыми таблицами пропорций. После этого сейлы могут товар растащить из своих пулов под свои заказы. Далее мы сделали автоматическое удаление просроченных резервов. То есть - если складская проводка была зарезервирована более чем N дней назад но так и не была отгружена, резерв автоматически переводится в пул более высокого уровня (отдела, рабочей группы или чего-то подобного). Ну а спустя какое-то время неликвиды из пула верхнего уровня просто разрезервируются. Да, еще пожалуй замечу, что резервирование в пулы бывает только сейловое. Складские о нем не знают и они их не касается. Про перекидку резервов между заказами я написал уже. Про протоколирование операций с резервами - тоже упомянул. Думая об интеграции со сводным (которого на этом проекте не было), я бы предложил прописывать ссылку на пул резервов в прогнозах продаж и оттуда копировать в сводный план. Тогда при фирминге планового заказа можно было бы автоматом прописывать резерв в заказанных для данного пула резервов.

Почему мы это все сделали ? Ну про разделение сейлового и складского резервирования уже ivanhoe написал неплохо. А по поводу всего остального: Во многих фирмах, сейлы премируются неким процентом от маржи. В меньшей части - просто некоей долей своей базовой зарплаты помноженной на процент выполнения плана продаж. Соответственно, если я сейл, каждый раз когда я резервирую под свой заказ некоторый ходовой товар (допустим свежий iPhone), я фактически кладу в свой карман конкретные деньги. Зарезервировал 100 айфонов - считал штуку баксов в карман положил. В текущей версии аксапты, какие-либо механизмы разграничения доступа к резервам, управления резервами, протоколирования работы с резервами - отсутствуют. Как ты думаешь, что будет если в небольшую комнату - скажем метров 50 квадратных, засунуть 60 озверевших сейлов и в произвольный момент начать скидывать сверху купюры - разного номинала, разной стоимости и разной степени конвертируемости? Это - очень хорошая иллюстрация того, что случается при попытке внедрить стандартную аксаптовскую систему резервирования в среднестатистической торговой фирме. Я не уверен, что все что я тут написал нужно для всех клиентов, но

1. Разделение сейлового и складского резервов - must have
2. Протоколирование операций с резервами - must have
3. Пулы резервов - nice to have. Вообще механизм любопытный но требуется его додумывание для производственных фирм.
4. Автоматическое снятие резервов - тоже пожалуй что nice to have. Его не сложно самостоятельно реализовать если что.

Вообще вопросы в первоначальном Ванином сообщении расстраивают. Похоже у вас там опять каких-то чистых программистов набрали для разработки и каких-то MBAшников для постановки. Все-таки вопросы в стиле "К примеру, если я хочу забрать на свой заказ какие-то товары, которые уже были зарезервированы, смогу ли я это сделать?" вызывают глубокое недоумение...

[Atar]

Супер!
Небольшое уточнение.

Цитата:

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

Сейловое запрещает перемещение товара за пределы организации (то есть - разрешает его переносить, но запрещает его списывать или продавать).

Есть смысл запрещать перемещение зарезервированного сейлами товара за пределы сайта/склада/произвольного набора скл.аналитик.
Порой ни к чему резервировать товар в другом сайте, складе.
Да даже и из определённой (или одной) партии бывает нужно зарезервировать, но это скорее исключение.

[fed]

Цитата:

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

Супер!
Небольшое уточнение.

Есть смысл запрещать перемещение зарезервированного сейлами товара за пределы сайта/склада/произвольного набора скл.аналитик.
Порой ни к чему резервировать товар в другом сайте, складе.
Да даже и из определённой (или одной) партии бывает нужно зарезервировать, но это скорее исключение.

Да - правильно. Должен быть произвольный набор аналитик. Мы расширенный склад не использовали, но сделали некое подобие сайта (это еще трешка была), при этом сейлы резервировали на уровне сайта. А складские потом сами обеспечивали перевозку со склада хранения на склад отгрузки.
В общем - я бы сказал что надо вводить понятие аналитик сейлового резервирования и складского резервирования. Сейловый резерв ОБЯЗАН иметь заполненные аналитики сейлового резервирования, но опционально может иметь и дополнительные аналитики.

[Ivanhoe]

Цитата:

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

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

Каюсь, забыл. Полностью поддерживаю!!! В т.ч. делали "вычет" из премии за размер резерва у продавца.

[ALES]

Цитата:

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

Да - правильно. Должен быть произвольный набор аналитик. Мы расширенный склад не использовали, но сделали некое подобие сайта (это еще трешка была), при этом сейлы резервировали на уровне сайта. А складские потом сами обеспечивали перевозку со склада хранения на склад отгрузки.
В общем - я бы сказал что надо вводить понятие аналитик сейлового резервирования и складского резервирования. Сейловый резерв ОБЯЗАН иметь заполненные аналитики сейлового резервирования, но опционально может иметь и дополнительные аналитики.

1. Желательно чтобы все это дружило и с SCM.
2.В "сейловом" резервировании часто хотят видеть не только под кого резерв, но и срок(и) окончания резерва ("сейловое" резервирование подразделяют на несколько типов с точки зрения сроков и приоритетов при "снятии")

[kashperuk]

Цитата:

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

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

Хотелось бы уточнить - почему только 900? Ведь если, к примеру, вся 1000 испортилась (упали, скажем), то нужно списать всю 1000, не смотря на то, что они для какого-то заказа зарезервированны. Или нет?

[kashperuk]

Цитата:

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

Да - правильно. Должен быть произвольный набор аналитик. Мы расширенный склад не использовали, но сделали некое подобие сайта (это еще трешка была), при этом сейлы резервировали на уровне сайта. А складские потом сами обеспечивали перевозку со склада хранения на склад отгрузки.
В общем - я бы сказал что надо вводить понятие аналитик сейлового резервирования и складского резервирования. Сейловый резерв ОБЯЗАН иметь заполненные аналитики сейлового резервирования, но опционально может иметь и дополнительные аналитики.

Хмм, а зачем еще один вид аналитик? Разве не логичнее бы было просто дать возможность сэйлу указывать только те аналитики, которые он знает/хочет/названы клиентом?
Можешь привести несколько примеров аналитик, которые все сэйлы обязательно должны указывать?