Доброе время суток, уважаемые!
У нас возникла необходимость создавать заявки на материалы до деблокирования заказа, но не раньше чем заказу будет присвоен определенный пользовательский статус - я, честно говоря, была уверена, что это можно будет сделать присвоив виду заказа Влияние на создание рез/заявки - "Немедленно" и запретив орг.-эк. операцию "Материал: заявка на материал" для остальных пользовательских статусов. Но при тестировании этот подход не дал результатов - если в заказе указано, что заявка должна формироваться немедлено, то заявка при прогоне ППМ формируется независимо от статусов.
Подскажите, пожалуйста, в чем я не права и что можно сделать в данной ситуации (может быть, как-то иначе решить ее).
С надеждой и уважением!

БАДИ MD_CHANGE_MRP_DATA позволяет исключить из планирования различные потребности (в т.ч. и резервирования) при прогоне ППМ.

Спасибо!
а управлять орг-эк.операциями с помощью статусов, значит, нельзя?..

Можно.

А как? в смысле, почему же не сработала описанная мной выше схема?

Дело в том, что если каким-либо СИСТЕМНЫМ статусом явно разрешена или запрещена операция, её нельзя перекрыть пользовательским статусом. Системный статус имеет преимущество.
Управлять операциями посредством сисетмных статусов тоже можно, но осторожно.

Спасибо
Теперь все окончательно ясно

Уважаемые, подскажите!
Правильно ли я понимаю, что никакими пользовательскими статусами нельзя запретить изменения в деблокированном заказе?
Нужно сделать так чтобы с заказом можно было бы работать: списывать затраты, обрабатывать резервирования и т.д., но для изменения заказ был бы закрыт для всех пользователей, а для отдельных пользователей можно было бы разрешить его изменение. Думал сделать это через пользовательский статус, а не получается.
Неужели нужно будет юзер-экзит писать?

Дополнительная проверка через юзер-экзит в данном случае, пожалуй, одно из наиболее оптимальных решений. Буквально только что нечто подобное реализовывали.
Единственная альтернатива, на мой скромный взгляд, - требует серъезного административного ресурса: создается ключ полномочий для польз.статуса, без которого невозможно деблокирование (обычно - утверждение заказа ТОРО - обычно, гл.инженером). Думаю, как запретить деблокирование без польз.статуса - в курсе. Далее - полномочия на "утверждение" выдаются тому самому "узкому кругу лиц" и ТОЛЬКО им. После установки статуса "Утвержден" дальнейшее изменение возможно только при наличии полномочий на утверждение, следовательно кто-то ниже гл.инженера изменять заказ не сможет. Минус - деблокировать заказ в этом случае сможет также только лицо имеющее права на утверждение. Здесь как раз и необходим тот самый "ресурс" - заставить лиц "уполномоченных" самим в системе заказы утверждать и деблокировать, так еще и изменять при необходимости. На практике зачастую логин и пароль такого "полномочного" лица становятся известны чуть ли не всем подряд, соответственно и заказы изменяются как угодно....
P.S. ой, как длинно получилось... если слишком запутано - переспросите, постараюсь прояснить

Хм, вот пример.
У заказа ТОРО системный статус "ОТКР - Открыто", данный статус явно разрешает деблокирование
Я создаю статусную схему с пользовательским статусом "ЗДЕБ - Запрет деблокирования", который явно запрещает деблокирование.
Присваиваю статусную схему заказу, устанавливаю статус ЗДЕБ.
Система не позволяет деблокировать заказ. Получается пользовательский статус перекрывает системный?