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

[mazzy]

Есть функционал "резервирование в заказанных" (другими словами, резервирование в ожидаемых приходах).
Сейчас "резервирование в ожидаемых приходах" выполняется только для уже введенных приходов (закупки, инвентаризация, журналы).

Если я сломаю Аксапту и разрешу ей "резервировать в ожидаемых приходах" до создания самих приходов, то на какие грабли я наступлю?

Первое, что приходит в голову: сейчас "резервирование в заказанных" выполняет автоподбор аналитик по тем аналитикам приходов. Мне нужно будет автоподбор аналитик переместить туда, где выполняется смена статуса с "Зарезервировано в заказанных" на статус "Физ.зарезервировано".

Есть ли еще подводные камни? Что будет со сводным планированием?
Интересует в первую очередь ax2009. Но также будут интересны мнения и по другим версиям

Заранее

[slava09]

Я не совсем понял как это будет происходить.
Будет какая-то функция, которая принудительно и произвольно переведет статус расхода складской проводки из "В заказе", на "Зарезервировано в заказано"?

[DMA]

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

[mazzy]

Цитата:

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

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

Хороший вопрос.

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

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

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

==================
Будет ли число приоритетов больше двух? (сейчас высокоприоритетные и низкоприоритетные). Заказчик предполагает, что такое возможно в ДАЛЕКОМ будущем. Попытка сформулировать алгоритм для более сложной приоритезации вызвала массу споров. Поэтому СЕЙЧАС принято решение ограничится двумя приоритетами.

У нас есть несколько вариантов решения для приоритезации.
В этой ветке хотелось бы понять:
1) кто-нибудь ходил путем резервирования в заказанных?
2) какие грабли стоит ждать?

Заранее спасибо.

[miklenew]

Цитата:

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

1) кто-нибудь ходил путем резервирования в заказанных?

Ходили. Но не при такой задаче.
Попробуйте требования уточнить. Что вы хотите получить от резервирования?

[mazzy]

Цитата:

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

Я чё-то вообще не понял. Как зарезервировать если ни лота ни проводки ещё нет.

Как это нет? Заказ на продажу уже есть.

Цитата:

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

Может тогда новый статус ввести: зарезервировано в возможных.

он уже есть. называется ReserveOnOrdered.

Цитата:

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

У вас общее доступное количество будет не понятно что выдавать.

почему непонятно. будет выдавать минус. как и сейчас, в стандартном функционале.

Цитата:

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

Что вы хотите получить от резервирования?

Эм... Ладно вечером скриншоты.

[mazzy]

угу... понял. скриншоты желаемого нарисую ночером.

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

инструмент (один из рассматриваемых вариантов): расширить механизм резервирования таким образом, чтобы он ставил признак "зарезервировано в заказанном" даже при отсутствии ожидаемых приходов.

вопрос: какие грабли стоит ждать при выборе этого инструмента? особенно в модуле сводное планирование.

[miklenew]

Цитата:

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

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

Я чё-то вообще не понял. Как зарезервировать если ни лота ни проводки ещё нет.
У вас перестанут сходиться проводки с остатками. Даже если допилите остатки.
У вас общее доступное количество будет не понятно что выдавать.
Может тогда новый статус ввести: зарезервировано в возможных.
Чтоб потом несостыковки по проще было развести.
Но всё равно не понимаю связь будет на основе чего.
Чтобы взять 10 чего-то, нужно чтоб в остатки они уже были.
Или в минус уходить на спец статусе зарезервировано в возможных.
А потом покрывать этот минус планированием.
Или может эту информацию не в остаток помещать, а в спец таблицу.
А при покрытие (приход или что это будет) уже резервировать по информации из спец таблицы.

[mazzy]

Приостановил реиндексацию и генерацию всех баз, кроме ax2009 Contoso.
Напомню, что хочется:

Цитата:

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

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

инструмент (один из рассматриваемых вариантов): расширить механизм резервирования таким образом, чтобы он ставил признак "зарезервировано в заказанном" даже при отсутствии ожидаемых приходов.

вопрос: какие грабли стоит ждать при выборе этого инструмента? особенно в модуле сводное планирование.

Итак, резервирование в заказанных - один из вариантов для приоритезации.
Дело в том, что когда разносится закупка, то Аксапта АВТОМАТИЧЕСКИ переводит статус "резерв в закупленных" в статус "зарезервировано". Именно это и хочется использовать.

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

===============
Вернемся к Аксапте.
Во-первых, общее доступное количество в ax2009 считает не так сказал miklenew.

В ax2009 оно считается как
this.availPhysical()+ this.Ordered - this.InOrder + this.Arrived - this.ReservOrdered

Смотрим в стандартную Contoso базу.
Я выбрал номенклатуру (не спецификацию) с простой аналитикой (только сайт и склад), у которой запрещены отрицательные остатки


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


Теперь предположим, что это высокоприоритетная продажа.
Я хочу зарезервировать весь этот товар.
Я ожидаю, что 45 штук (физически доступно) будет немедленно зарезервировано
Я ожидаю, что 25 штук (ожидается приход) будет зарезервировано в ожидаемых закупках.
Оставшиеся 30 штук штатный функционал Аксапты не резервирует


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


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

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

Вопрос только один - где-нибудь аукнется тот факт, что количество "заразервировано в заказанном" станет больше, чем "всего заказано"? Особенно волнует сводное планирование. Тут vals прав.

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

[miklenew]

Цитата:

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

В ax2009 оно считается как
this.availPhysical()+ this.Ordered - this.InOrder + this.Arrived - this.ReservOrdered

Хм. Действительно. В 3.0, 4.0 по другому. Во дают.

[aidsua]

mazzy, а почему Вы не хотите поставить заглушку, которая бы срабатывала при физическом получении товара (Управление запасами - Журналы - Прибытие номенклатуры - Прибытие Номенклатуры - Разноска) + (Заказ на покупку - Запасы - Регистрация), перерезервировала бы полученный товар по необходимому Вам/Заказчику механизму? Тем более, что это можно будет вынести в параметры/заказ/. программировать минимум, а работать должно (хотя и будет занимать больше времени, чем обычное резервирование).

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

[pitersky]

Цитата:

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

mazzy, а почему Вы не хотите поставить заглушку, которая бы срабатывала при физическом получении товара

Так вроде же речь шла именно о резервировании ДО фактического прихода...

[aidsua]

Цитата:

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

Так вроде же речь шла именно о резервировании ДО фактического прихода...

Понял. Начну сначала.
1. В Заказе на продажу есть дополнительное свойство, которое влияет на перезервирование ТМЦ (например, вип/обычный).
2. В момент приходования ТМЦ (мы делали в складской части) и в случае наличия незарезервированных ТМЦ из Заказов на продажу с типом "вип" -- выполняем снятие уже полученного ТМЦ с резерва (обычное резервирование) и резервировании в необходимом Заказе на продажу с типом "вип".
3. Пример:
3.0. Остаток на 2009-01-01 на складе 10 шт, зарезервировано 0 шт, физ.доступно 10 шт
3.1. Заказ на продажу 1, тип "обычный", резервирование "Автоматическое", от 2009-01-02, количество 12 шт. -- Статус "Физ.Зарезервировано" - 10 шт, "В заказе" - 2 шт
3.2. Заказ на продажу 2, тип "вип", резервирование "Автоматическое", от 2009-01-03, количество 4 шт. -- Статус "В заказе"
3.3. Заказ на продажу 3, тип "вип", резервирование "Автоматическое", от 2009-01-04, количество 5 шт. -- Статус "В заказе"
3.4. При необходимости получить максимально возможное кол-во ТМЦ для текущего вип клиента, например, по Заказу на продажу 2 -- выполняется дописанный функционал по Заказу на продажу, что позволяет "выцепить" все возможные остатки из зарезервированного в Заказах на продажу с типом "обычный". В нашем случае из Заказа на продажу будет снято с резерва 4шт ТМЦ. Получаем: Заказ на продажу 1 -- Статус "Физ.Зарезервировано" - 6 шт, "В заказе" - 6 шт; Заказ на продажу 2 -- Статус "Физ.Зарезервировано" - 4 шт.
3.5. Аналогично работает при приходорвании ТМЦ, только за основу берется Заказ на покупку (Номенклатура + Количество).

[miklenew]

Цитата:

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

до создания самих приходов

Может я фразу не правильно понял.
До создания приходов или до физ. разноски приходов?

[Vals]

Цитата:

Если я сломаю Аксапту и разрешу ей "резервировать в ожидаемых приходах" до создания самих приходов, то на какие грабли я наступлю?

Дык оно и само так работает
Я бы ничего в этом плане не делал по нескольким причинам:
1. Я не понимаю чё ты хочешь, а значит, ты фигово сформулировал задачу (а значит и клиент нифига не понимает, чё надо), а раз задача фигово сформулирована, значит её фиг решишь Ээээ... или я просто туплю

2. Цепочка заказа в Аксапте работает и так, в сводном есть параметр резервирования при утверждении спланированных заказов.

3. Если будешь ломать резервирование - сломаешь и эту цепочку.

4. Думаю, что задача решается процедурно в форме Спланированные заказы. Там хоть всю картинку увидишь.

P.S. Слушай, а ведь забавно, что ты написал "Ломать". Одного этого слова хватит, чтобы тебя остановить


P.S.

Цитата:

Сейчас "резервирование в ожидаемых приходах" выполняется только для уже введенных приходов (закупки, инвентаризация, журналы).

И для спланированных в сводном планировании в том числе.

[mazzy]

хе... это я фигово сформулировал.
поскольку заканчиваю переустановку компа, а аксапта еще не работает


сейчас-сейчас, сейчас, сейчас... она доустановится...
и проверю, и сформулирую.

в общем, я так понял, что в эту сторону никто не ходил.

[mazzy]

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

[Vals]

Цитата:

где-нибудь аукнется тот факт, что количество "заразервировано в заказанном" станет больше, чем "всего заказано"?

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

Слушай, а что бы ты делал, для решения этой задачи, если бы резервирования не было в принципе?

Параметр пометка при утверждении спланированных посмотри.

[mazzy]

Цитата:

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

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

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

Цитата:

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

Слушай, а что бы ты делал, для решения этой задачи, если бы резервирования не было в принципе?

Рассматривалось несколько вариантов (в порядке поступления):
= виртуальные склады
= прогать новую сущность (много прогать)
= прогать резервирование (какое-то распределение резервов)
= карантинный склад
= складская аналитика
= поле в существующей складской аналитике
= расширить механизм "резервирования в заказанном"

Цитата:

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

Параметр пометка при утверждении спланированных посмотри.

Спасибо. Поглядел.
Либо я чего-то не понимаю, либо одно из двух...
Можешь подробнее мысль пояснить?

[Zodiak]

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

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