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

[kashperuk]

Цитата:

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

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

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

[Ivanhoe]

Цитата:

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

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

В итоге надо списать всю 1000, но резерв продавца должен гарантировать, что ему, как минимум, об этом сообщат. Как максимум - он сначала сам должен отказаться от резерва (или "передать" ответственному за инвентаризацию).

[fed]

Цитата:

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

В итоге надо списать всю 1000, но резерв продавца должен гарантировать, что ему, как минимум, об этом сообщат. Как максимум - он сначала сам должен отказаться от резерва (или "передать" ответственному за инвентаризацию).

Тут, кстати, можно упомянуть об еще об одной фишке, которой в аксапте не хватает.
Зачастую во внедрениях заводятся, гм, 'не визуальные' складские аналитики. Например - номер договора на поставку или собственник товара или что-то подобное. Одинаковые товары с разными аналитиками визуально никак не различимы. А теперь представим что у нас на складе лежит 300 сепулек, из которых 120 закуплены по договору A, 100 - по договору B и 80 по договору C. Внезапно при проведении инвентаризации выясняется что 10 сепулек куда-то потерялось. Складским надо быстро провести инвентаризацию по данной номенклатуре, при этом они знать не знают про эти договора (это чисто для расчета себестоимости аналитика).Приходится писать какую-то отдельную форму инвентаризации, которая выводит только 'визуальные' аналитики, а при необходимости списания, она по каким-то правилам подставляет в проводки невизуальные. Правила бывают разные. Обычно что-то типа: В первую очередь списывать то что незарезервировано, если зарезервировано, то снимать резервы по принципу LIFO и списывать соответствующий товар. Естественно - при таком форсированом снятии резерва, система должна оставлять запись в протоколе резервирования/разрезервирования и оповещать ответственного продавца...

[Vals]

Цитата:

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

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

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

[ALES]

Цитата:

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

Тут, кстати, можно упомянуть об еще об одной фишке, которой в аксапте не хватает.
...Приходится писать какую-то отдельную форму инвентаризации...

IMHO стандартная инвентаризация это отдельный "ужас" и аксапте ее (инвентаризации) сильно не хватает

[kashperuk]

Цитата:

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

Тут, кстати, можно упомянуть об еще об одной фишке, которой в аксапте не хватает.
Зачастую во внедрениях заводятся, гм, 'не визуальные' складские аналитики. Например - номер договора на поставку или собственник товара или что-то подобное. Одинаковые товары с разными аналитиками визуально никак не различимы. А теперь представим что у нас на складе лежит 300 сепулек, из которых 120 закуплены по договору A, 100 - по договору B и 80 по договору C. Внезапно при проведении инвентаризации выясняется что 10 сепулек куда-то потерялось. Складским надо быстро провести инвентаризацию по данной номенклатуре, при этом они знать не знают про эти договора (это чисто для расчета себестоимости аналитика).Приходится писать какую-то отдельную форму инвентаризации, которая выводит только 'визуальные' аналитики, а при необходимости списания, она по каким-то правилам подставляет в проводки невизуальные. Правила бывают разные. Обычно что-то типа: В первую очередь списывать то что незарезервировано, если зарезервировано, то снимать резервы по принципу LIFO и списывать соответствующий товар. Естественно - при таком форсированом снятии резерва, система должна оставлять запись в протоколе резервирования/разрезервирования и оповещать ответственного продавца...

А может просто проблема в том, что для этого пытаются использовать складские аналитики? Натягивая на них функционал, на который они изначально не были рассчитаны? И получается, как с Catch Weight в AX Retail - через ж...

[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

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

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

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

[ALES]

Цитата:

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

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

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

[kashperuk]

Цитата:

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

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

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

[fed]

Цитата:

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

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

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

[Atar]

Цитата:

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

Хмм, а зачем еще один вид аналитик?

Речь не про вид аналитик, а про параметр аналитики - но это, по-моему, все правильно поняли.

Цитата:

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

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

Да. это было бы удобно: какие аналитики сейл указал в заказе на продажу (строке складского журнала и т.д.), таковые и считать "сейловыми".
Но это может вносить путаницу, с которой потом трудно разобраться: по одной части запасов резерв в таком разрезе аналитик, по другой - в другом.

Цитата:

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

Можешь привести несколько примеров аналитик, которые все сэйлы обязательно должны указывать?

Как уже сказали выше - Сайт и Склад. Но уверен, что будут клиенты, для которых и это избыточно - захотят сейлово резервировать запасы в целом в компании, не по складам.

[Ivanhoe]

Цитата:

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

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

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

[kashperuk]

Цитата:

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

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

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

[kashperuk]

Всем спасибо за ответы. Надо осмыслять по чуть-чуть.
Я буду отписываться с доп.вопросами по ходу.
Еще кто-то что-то хочет может добавить?

[Maximin]

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

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

[Ivanhoe]

Кстати, в Connect есть такой запрос :
https://connect.microsoft.com/dynami...-transfer-them

Цитата:

We have a need due to limited warehouse space to transfer material/items to and from remote warehouses for use on production lines or for shipping to customers. Currently in AX if we reserve the items against the production or sales orders then we have to unallocate, do the transfer, and re-allocate. This is not ideal and would greatly prefer the ability to transfer items without having to go through this three step process.

[kashperuk]

Понял, спасибо.

[Vals]

Бывает и наоборот: у меня перед глазами форма учёта серийных номеров которая ничего не знает о складской аналитике Серийный номер