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

[kashperuk]

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

[kashperuk]

Zitat:

Zitat von fed

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

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

[Ivanhoe]

Zitat:

Zitat von kashperuk

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

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

[fed]

Zitat:

Zitat von kashperuk

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

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

[fed]

Zitat:

Zitat von Ivanhoe

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

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

[Vals]

Zitat:

Zitat von fed

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

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

[Maximin]

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

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

[Ivanhoe]

Zitat:

Zitat von Vals

При этом появляются новые фишки, которыми мало кто пользуется в силу незнания и привычки.

Подскажите, пожалуйста, какие новые фишки появились в 2009 в обсуждаемой области?
Мне лично кроме нескольких новых форм, из которых можно начать сборку / обрабатывать накладные по заказам и функциональности (громко сказано) ATP на ум больше ничего не пришло

Кстати, вопрос чуть в сторону, кто-то использует ATP (available to promise) вместо / параллельно с резервированием?

[Atar]

Zitat:

Zitat von kashperuk

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

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

Zitat:

Zitat von kashperuk

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

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

Zitat:

Zitat von kashperuk

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

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

[kashperuk]

Zitat:

Zitat von Raven Melancholic

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

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

Zitat:

Zitat von Raven Melancholic

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

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

[kashperuk]

Zitat:

Zitat von Ivanhoe

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

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

[Ivanhoe]

Zitat:

Zitat von kashperuk

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

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

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

Zitat:

Zitat von kashperuk

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

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

[Raven Melancholic]

Zitat:

Zitat von kashperuk

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

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

Zitat:

Zitat von kashperuk

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

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

[fed]

Zitat:

Zitat von kashperuk

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



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

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

[Ivanhoe]

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

Zitat:

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.

[ALES]

Zitat:

Zitat von fed

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

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

[Serg]

Zitat:

Zitat von fed

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

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

[fed]

Zitat:

Zitat von Serg

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

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

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

[pitersky]

Zitat:

Zitat von fed

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

Да, создавать шаблоны отображения InventSum было бы совсем неплохо
Только не комбобокс нужен, конечно, а лукап к отдельному справочнику. Чтобы можно было пользовательски администрировать эти шаблоны.

[kashperuk]

Zitat:

Zitat von fed

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

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