Как обеспечить высокоприоритетные продажи в стандартном функционале?

[mazzy]

постановка задачи здесь Можно ли сломать функционал резервирования в заказанных следующим образом...?
один из вариантов, при котором надо "ломать" штатный функционал с непонятными последствиями, приводится здесь.

Цитата:

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

Дык оно и само так работает
Я бы ничего в этом плане не делал по нескольким причинам:

Ок. Может быть есть другой вариант?
Как обеспечить высокоприоритетные заказы на продажу без изменений в коде?

Есть куча заказов. на разные даты. Некоторые высокоприоритетные.
Сводное планирование объединяет, сдвигает и т.п. В общем, работает.
Как обычно, через некоторое время выполняется закупка и товар приходит.
По ходу появляются новые заказы на продажу. В общем, процесс идет.

Главное, что на каждый момент времени текущих заказов на продажу как правило больше, чем пришедшего товара.

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

[miklenew]

Цитата:

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

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

Имеется в виду физ. разервирование для низкоприоритетных?
Т.к. до этого было

Цитата:

А низкоприоритетные смогут резервировать только из физического наличия.

Думаю полюбому встанет необходимость создания автоматического перерезервирования, по кнопке или глобальную процедуру.
Т.к. вновь созданный приоритетный заказ будет претендавать на остатки которые взял низкоприоритетный, когда ещё и в помине не было высокоприоритетного.

[oleg61858]

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

[GM2005]

А может быть использовать различные склады для обслуживания приоритености продаж? Фактически ведь речь идет о приоритетности (доступности) товарных запасов в первую очередь для тех или иных клиентов или продавцов (а они закрепляются за определенными складами). Просто выдержка из хелпа:

"Склад, используемый для пополнения текущего склада, если отмечено Пополнение. Главные склады можно определять на нескольких уровнях.
Главный склад используется со сводным планированием. Если указать главный склад для текущего склада и установить флажок Пополнение, все выпуски заполняются запланированными заказами на перемещение в данном складе. Если указать главный склад и не установить флажок Пополнение, создается иерархическая структура складов. Это необходимо, поскольку иначе невозможно указать особые правила для покрытия номенклатуры.

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

Уровень Склад
4 E2
4 E1
3 D
2 C2
2 C1
1 B
0 A

Примеры:

Склады могут пополняться только из складов более низких уровней. Это необходимо для предотвращения циркулярности.

Например, C2 может пополняться только B и A, поскольку D, E1 и E2 находятся на более высоких уровнях складов.

Склад может пополнять несколько складов, расположенных в иерархии выше него.

Например, B может напрямую пополнять C1 и C2.

Склад не может пополняться двумя складами.

Например, D не может пополняться одновременно C1 и C2.

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

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

На вкладке Сводное планирование можно определить склад покрытия для текущего склада. Можно также определить склад как склад пополнения, для которого запланированные заказы на перемещение создаются из главного склада в ходе сводного планирования.

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

[mazzy]

Спасибо за ответы.

Цитата:

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

Имеется в виду физ. разервирование для низкоприоритетных?

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

Цитата:

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

а так: блатная задача при попытке резервирования отбирает резерв у фраеров

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

Цитата:

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

1.Можно отделить высокоприоритетные заказы отдельным виртуальным складом.

Думали об этом. Но виртуальные склады сильно усложнят жизнь склада. Физических складов несколько. Там есть свои заморочки, чтобы вводить новый склад. Но это действительно один из рассматриваемых вариантов - карантинный склад.

Цитата:

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

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

А потом перерезервировать, а потом снимать резерв, а потом...
Жизнь сложнее, чем кажется. Что-то может не прийти, что-то может прийти раньше.
В общем, "распределять резервы" потенциально приведет к сканадалам.
Должен быть простой и предельно понятный для менеджеров алгоритм.

Цитата:

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

Должны быть статьи.

В смысле?

Цитата:

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

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

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

Понятно, что системным образом с дефицитом должно бороться сводное планирование. Но сводное планирование - отдельная пестня. Здесь вопрос только о гарантиях для высокоприоритетных.

Цитата:

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

А может быть использовать различные склады для обслуживания приоритености продаж?

Как я уже говорил. Такое решение сильно усложнит инвентаризацию. Склад ничего не знает о приоритетах. Работа склада - отдельная песня.

Цитата:

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

"Склад, используемый для пополнения текущего склада, если отмечено Пополнение.

Да. Это был почти первый вариант, пока зарубленный мной.
Слишком много придется прогать для склада, если мы пойдем этим путем.

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

[belugin]

а так: блатная задача при попытке резервирования отбирает резерв у фраеров

[Vals]

Цитата:

Как обеспечить высокоприоритетные заказы на продажу без изменений в коде?

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

По каким-то причинам приоритетные задачи создают узкое место.

[Vals]

Пополнение складов с главного используется для создания распределительного центра и сети региональных складов.

[Vals]

Цитата:

Цитата:
Сообщение от Vals
Должны быть статьи.
В смысле?

Как то давно я читал учебники по обработке очередей с приоритетами, содержащие мат методы.

Цитата:

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

Понятно, что системным образом с дефицитом должно бороться сводное планирование. Но сводное планирование - отдельная пестня. Здесь вопрос только о гарантиях для высокоприоритетных.

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

[mazzy]

Цитата:

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

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

Смотри:
ты сейчас говоришь о том, что потребность надо обеспечить. Да, согласен. И модуль сводное планирование будет работать.

я говорю немного о другом.
Предположим, что сводное планирование отработало и закупило.
Но бывают форс-мажоры (фура застряла, на таможне тянут и т.п.), которые приводят к локальным дефицитам.
В условиях дефицита (уже после того, как товар пришел, а закупка разнесена) нужно гарантировать, что высокоприоритетные продажи ГАРАНТИРОВАНО получат товар первыми.

Другими словами, как сделать так, чтобы мендежеры низкоприоритетных заказов не перехватили товар сразу после разноски закупки? Как ГАРАНТИРОВАТЬ, что закупленный товар попадет в первую очередь в высокоприоритетные продажи? (может быть даже в ущерб низкоприоритетным)

[belugin]

фачтически получается, что для низкоприоритетных физналичие = физналичие - зарезервировано в высокоприоритетных?

[mazzy]

да.

[belugin]

может просто такую доппроверку прилепить для низкоприоритетных?

[mazzy]

Цитата:

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

может просто такую доппроверку прилепить для низкоприоритетных?

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

[GM2005]

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

[mazzy]

Цитата:

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

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

Хм... интересная и новая мысль. надо подумать. Спасибо.

и в этом случае никакого резервирования...

[EVGL]

Цитата:

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

Хм... интересная и новая мысль. надо подумать. Спасибо.

и в этом случае никакого резервирования...

Резервирование в Аксапте - это верный путь к могиле и буксующему проекту.

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