Как сделать, чтобы резервирование не мешало текущим отгрузкам?

[twilight]

Здравствуйте!
На складе планируется использовать WMS учет в Аксапте.
Сейчас работа ведется в Аксапте, но без адресного склада.
Менеджеры резервируют заказы на продажу заранее, за несколько дней, неделю или несколько недель до отгрузки и ждут получения денег от клиента. После получения денег они производят отгрузку.
Как можно сделать, чтобы это предварительное резервирование не мешало текущим отгрузкам после начала работы с адресным складом в Аксапте? Ведь теперь резервироваться все будет в разрезе аналитик склад, ячейка, паллета. И если предварительное резервирование зарезервирует палеты в ячейке комплектации или в буферных ячейках, которые ближе к воротам отгрузки. А первым отгружать нужно будет другой заказ. Получается паллеты, которые наиболее удобно сейчас брать для отгрузки заблокированы другими заказами!

[Vals]

Кратко здесь описал:
http://www.amand.ru/modules/wordpress/archives/114

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

[glibs]

Цитата:

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

...
неделю или несколько недель до отгрузки и ждут
...

Рациональный вариант — не резервировать. Снижаете оборачиваемость.

Нерациональный вариант — править механизм резервирования. Либо штатный, либо WMS-ный. Наверное, второй даже лучше. Чтобы он перебрасывал мешающий резерв. Т.е. запрограммировать следующее: менеджер хочет что-то отгрузить, видит глазами, что ему что-то мешает, заходит в мешающий заказ, снимает резерв автоматический, вручную цепляет этот же резерв на другую паллету. Только сделать это в транзакции и автоматически. Если у вас только склад-ячейка-паллета, то при реальной отгрузке произойдет WMS-перерезервирование с оптимизацией. Если есть еще аналитики, то будет отдельная песня. ГТД для WMS будет красной тряпкой. Это в копилку того, как надо было (не)делать ГТД.

[Zuek]

Цитата:

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

Рациональный вариант — не резервировать. Снижаете оборачиваемость.

Нерациональный вариант — править механизм резервирования. Либо штатный, либо WMS-ный. Наверное, второй даже лучше. Чтобы он перебрасывал мешающий резерв. Т.е. запрограммировать следующее: менеджер хочет что-то отгрузить, видит глазами, что ему что-то мешает, заходит в мешающий заказ, снимает резерв автоматический, вручную цепляет этот же резерв на другую паллету. Только сделать это в транзакции и автоматически. Если у вас только склад-ячейка-паллета, то при реальной отгрузке произойдет WMS-перерезервирование с оптимизацией. Если есть еще аналитики, то будет отдельная песня. ГТД для WMS будет красной тряпкой. Это в копилку того, как надо было (не)делать ГТД.

Не думаю, что не резервировать - рациональный вариант. Можно использовать резервирование типа развертывание, если дата поставки лежит в относительно "далеком" будущем если есть сводное планирование. А вот если его (сводного планирования нет), но есть товар (возможно, пользующийся большим спросом) и клиент, которому требуется время на оплату - резерв надо делать. Иначе его могут "напродовать" больше, чем есть на складе. Вот тут и встает вопрос о необходимости "перебрасывать" резервы в процессе комплектации (есть WMS или нет). Скажите, а что вы имели под "отдельной песней"? Можно по подробнее - очень интересно

[Raven Melancholic]

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

[twilight]

Цитата:

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

Кратко здесь описал:
http://www.amand.ru/modules/wordpress/archives/114

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

Не совсем понял, что вы имели в виду.
Как это связано с палетами?
Резервируется только товар, который в наличии на складе.
Партионного учета нет.

[twilight]

Цитата:

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

Рациональный вариант — не резервировать. Снижаете оборачиваемость.

Нерациональный вариант — править механизм резервирования. Либо штатный, либо WMS-ный. Наверное, второй даже лучше. Чтобы он перебрасывал мешающий резерв. Т.е. запрограммировать следующее: менеджер хочет что-то отгрузить, видит глазами, что ему что-то мешает, заходит в мешающий заказ, снимает резерв автоматический, вручную цепляет этот же резерв на другую паллету. Только сделать это в транзакции и автоматически. Если у вас только склад-ячейка-паллета, то при реальной отгрузке произойдет WMS-перерезервирование с оптимизацией. Если есть еще аналитики, то будет отдельная песня. ГТД для WMS будет красной тряпкой. Это в копилку того, как надо было (не)делать ГТД.

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

Насчет перебрасывания резервов - думали над этим вариантом. Но алгоритм перебрасывания резервов не слишком ясен, и есть сомнения насчет производительности. Да и вообще как то не нравится, что при таком подходе по складу будут все время хаотично перебрасываться резервы.

[Ivanhoe]

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

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

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

Используется Axapta 3.0 или AX 4.0?
В 4.0 в форме резервирования появился раздел "Блокировать резервирования", с помощью которого можно управлять резервированием в закупках по конкретной аналитике. Для этого ячейки и палеты должны быть не первичными аналитиками - при резервировании в закупке будет зафиксирован только склад, а ячейка и палета подберутся автоматически после физического прихода номенклатуры.

P.S. пока писал, многое прояснилось, так что частично уже неактуально.

[twilight]

Цитата:

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

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

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

[twilight]

Цитата:

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

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

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

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

Используется Axapta 3.0 или AX 4.0?
В 4.0 в форме резервирования появился раздел "Блокировать резервирования", с помощью которого можно управлять резервированием в закупках по конкретной аналитике. Для этого ячейки и палеты должны быть не первичными аналитиками - при резервировании в закупке будет зафиксирован только склад, а ячейка и палета подберутся автоматически после физического прихода номенклатуры.

P.S. пока писал, многое прояснилось, так что частично уже неактуально.

Менеджеры резервируют только исходя из остатков на складе. Ячейки и палеты им абсолютно безразличны.
Про ячейки хранения и ячейки комплектации не получится
Пример:
ячейка хранения на 100 штук
ячейка комплектации на 100 штук

Первый заказ резервирует в ячейке хранения
Второй заказ резервирует в ячейке комплектации

А первой оплата пришла по первому заказу. Получается придется брать товар из ячейки хранения, хотя он есть в ячейке комплектации.

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

Используется Axapta 3.0

[Vals]

Цитата:

В 4.0 в форме резервирования появился раздел "Блокировать резервирования", с помощью которого можно управлять резервированием в закупках по конкретной аналитике. Для этого ячейки и палеты должны быть не первичными аналитиками - при резервировании в закупке будет зафиксирован только склад, а ячейка и палета подберутся автоматически после физического прихода номенклатуры.

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

Цитата:

Не совсем понял, что вы имели в виду.
Как это связано с палетами?
Резервируется только товар, который в наличии на складе.
Партионного учета нет.

Эта задача вцелом не решается "в лоб" с помощью механизма резервирования. Вернее, не должна решаться, по моему мнению. Иначе, вам нужно будет перерезервировать перезервированное, чтобы зарезервировать перерезервированное

Цитата:

То ли делать модификацию, чтобы из заказа резервировалось только в разрезе склада.

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

В целом, нужно задуматься о следующем:
1. Почему отгрузка через месяц стоит в начале склада и "мешает другим"?
2. В чём суть процесса "манагеры ждут оплаты и резервируют товар"?
3. Почему, если клиент 100% возьмёт этот товар (так как по вашим словам, товар резервируется под будущую предоплату), его может не хватить?

[Ivanhoe]

Цитата:

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

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

+ В четверке можно руками проставлять блокировку на не первичные аналитики.

Цитата:

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

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

Я считал, что автоматически перерезервируется только в закупках, а не в наличии. В наличии это тоже работает?

[twilight]

Цитата:

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

В целом, нужно задуматься о следующем:
1. Почему отгрузка через месяц стоит в начале склада и "мешает другим"?
2. В чём суть процесса "манагеры ждут оплаты и резервируют товар"?
3. Почему, если клиент 100% возьмёт этот товар (так как по вашим словам, товар резервируется под будущую предоплату), его может не хватить?

1. Например, месяц назад товар был только в ячейке комплектации. Менеджер зарезервировал его. Две недели назад был приход товара в буферные ячейки (так как ячейка комплектации занята). Этот новый товар зарезервировали под другой заказ, отгрузка по которому раньше.
2. Товар отгружается по предоплате. Если оплата пришла, то по условиям договора товар нужно отгружать практически сразу после оплаты.
По-моему схема вполне нормальная, особенно в условиях текущего кризиса - мы не хотим выбивать с клиентов деньги за уже поставленный товар, а клиенты не хотят долго ждать товар после оплаты.
3. Без резервирования товара может нехватить, так как пока мы ждем оплату по текущему заказу, другой менеджер может получить заказ от другого клиента и оплату от другого клиента и отгрузить наш товар со склада. И когда придет оплата от текущего клиента, окажется что товара на складе нету и нужно ждать поставку.

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

[twilight]

Цитата:

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

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

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

[Atar]

Наиболее адекватным тут будет всё-таки отвязать понятие резервирование менеджером от резервирования на складе (из ячейки).
Их нельзя объединять, т.к. они несут разный смысл (первое - ограничивает менеджера возможностями склада/поставщиков, а второе - обеспечивает жесткое ограничение по отгрузке из заданной ячейки, т.е. рассчитано, что отгружаться оно будет уже сейчас, иначе снизится оборачиваемость).

Именно поэтому возникают сложности при попытке использования функционала резервирования для менеджеров в WMS Аксапта.

Из "штатных" средств тут может помочь только разделение учета на 2 компании - "для менеджеров и поставок" и "для WMS". Но тут всё равно наверняка придется много программировать для удобства пользователей и объединения бизнес-процессов.
Так что это достаточно опасный путь.

Лучше наверное всё-таки реализовать свой механизм отслеживания покрытия потребности в заказах (т.е. аналог резервирования без использования скл.проводок), а не производить постоянное перезервирование одной и той же продукции в течении недель (т.е. я соглашусь с glibs и Raven Melancholic), причем, можно даже сделать этот механизм с учетом дат планируемых поставок и отгрузок.
Это непросто реализовать (хотя, запрограммировать даже проще, чем продумать так, чтобы механизм был прост для понимая менеджерами), но зато позволит достигнуть цели без ломания стандартных алгоритмов резервирования и комплектации.

[Atar]

Цитата:

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

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

Да, конечно, если сработало физрезервирование, остатков на это количество уже нет, и оно не может быть зарезервировано под что-то ещё

[glibs]

Цитата:

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

...
Скажите, а что вы имели под "отдельной песней"?
...

Резервирование при комплектации - проблемы с автоматическим резервированием

Кратко. Если для номенклатуры используется аналитика кроме склад-ячейка-паллета, и в заказе на продажу поставить резерв (а он всегда поставится по конкретной ГТД/партии/СН), то в WMS перестает работать механизм комплектации из ячейки комплектации (с транспортировкой пополнения ячейки комплектации). Система предложит вам пробежаться по складу и достать товар непосредственно из тех ячеек, где он лежит. Стащить всю паллету ради конкретного зарезервированного товара с конкретным СН в ячейку комплектации она не предложит.

С т.з. партий это кому как. С т.з. СН по идее логично (если вы осознанно поставили резерв на конкретный СН). А вот с т.з. ГТД — как говорится, ни в кое-куда, ни в красную армию. Однозначно.

Кажется, не совсем кратко получилось .

[glibs]

Цитата:

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

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

IMHO, чересчур радикально.

[glibs]

Цитата:

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

...
менеджеры насоздают заказов больше, чем есть в наличии.
...

Ну, создавать заказы — это еще не обещать продать.

Цитата:

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

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

Ладно. Вопрос философский. Хотят (осознанно) хозяева морозить оборотные средства — их дело.

Цитата:

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

...
алгоритм перебрасывания резервов не слишком ясен
...

Могу дать только один совет. Пока методологию без системы (в голове) не уясните — не лезьте в разработку.

Цитата:

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

...
есть сомнения насчет производительности
...

У вас есть опыт работы с механизмом резервирования в WMS или просто стереотипы? Попробуйте.

[twilight]

Цитата:

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

У вас есть опыт работы с механизмом резервирования в WMS или просто стереотипы? Попробуйте.

Как-то раз сделали модификацию, чтобы резервирование шло упорядоченно по наличию товара. Т. е. сначала берем палету с наибольшим количеством товара и резервируем ее, потом с более меньшим и т. д. И резервирование стало выполняться реально долго - вместо нескольких секунд стало несколько минут. Так что все зависит от алгоритма.