есть расширение
IWO10009 Заказ ТОРО: проверка клиента к моменту "Сохранение"

оно срабатывает непосредственно перед сохранением/созданием
заказа.
Но в этот момент еще неизвестен номер создаваемого заказа.

Мне нужно выполнить определенные действия (запустить свою прогу, которая автоматически привяжет созданный заказ к нужной группе),
ПОСЛЕ сохранения заказа.

Вопрос - как это сделать? Какое расширение использовать?
Или есть другие методы?

Как бы на вскидку 2 способа:
1. Ломать SAPLCOIH - искать место, где номер заказа уже известен и уже там реализовывать свой функционал. Но это совсем в лоб.

2. Создать транзакцию, скажем ZIW31, в которой:
а) вызываем IW31
b) после завершения IW31 читаем из памяти ANR
c) запускаем свой функционал
юзерам, которые создают заказы в ролях даем ZIW31 вместо IW31

Хотя наверняка есть более элегантные решения.
Если найдется - поделитесь, плиз!

1. Самое простое решение но потом накатят ноты... или еще что-то...
2. Нет гарантии, что, например, пользователь корректно выйдет
из транзакции... К тому же есть автоматические функции создания заказов, как в стандарте - так и собственные... Везде ломать?

Ищу... пока ищу...

А для чего надо включать заказ в группу на этапе создания?
А если он создан ошибочно? А если потом изменят атрибуты, по которым определяется принадлежность заказа к группе?
У нас EXIT включает заказы в группы только при деблокировании.

ошибиться - трудно, т.к. единственным атрибутом - будет ЕО,
но, конечно, все возможно.
Можно это сделать и при деблокировании, конечно!
Скажите, плиз, какой EXIT вы при этом используете?

Собственные - через BAPI или как-то по другому?

например IBAPI_ALM_ORDERHEAD_CREATE
можно автоматически создать заказ через сообщение... и т.д.

Exit для проверки перед деблокированием IWO10002

если создавать заказ - и сразу деблокировать его,
то в этом exit - также еще неизвестен номер заказа

Может быть я не совсем поняла, что за группы , но существует стандартный способ разделения заказов.
1.Можно воспользоваться в spro, Заказы ТОРО-Общие данные - Пользовательский статус заказа.
Далее создаете статусную схему (в данном случае - группы заказов), надо указать тип объектов. Потом присваиваете статусную схему необходимым видам заказов.
Таким образом, происходит распределение по группам, которые Вы завели на стадии создания заказа. Тем более, что можно поставить стандартно условие, что орг-эк. операции можно проводить, только после смены статуса, например, какого-то фиктивного.
Это отрабатывает хорошо и при необходимости можно статус без проблем поменять.
2. А еще можно использовать группы обработки в основной записи заказа. Это информационное поле, а справочник можно создать самим. Почему удобно использовать гр.обработки - есть стандартный СО-отчет и списком заказы можно тоже отсортировать.
ВН, если найдешь какое-нибудь решение, то поделись, пожалуйста, что сделал. Интересно.

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

ой

Спасибо! Попробую... расскажу обязательно о результатах

согласен.
вполне разумно.
Только у нас не так много людей, чтобы четко разграничивать
обязанности.
Хотя это и не совсем правильно, но создает и деблокирует
заказы у нас - одно лицо.
Проверки в заказе поставить - не проблема, для этого
я использую IWO10009
но если не найду другого решения, то так и поступлю:
чтобы он сначала сохдал заказ, а потом деблокировал

Здесь речь идет пожалуй о группах СО-заказов (KOH1). Чем хорошо их использование - один и тот же заказ, в зависимости от каких-либо критериев, можно засунуть в разные группы - соответственно и анализировать потом в разных ракурсах.

А по поводу момента, когда необходимо это делать - все-таки наверное момент деблокирования самый походящий, дажи исходя из
идеологии процесса обработки заказа (открытие, разрешения/утверждения, деблокирование, обработка, ...)

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

2 BH: Но если вы все-таки что-нить откопаете (что-нить стандартное) - поделитесь - я копал это событие, для других правда целей, в итоге - модификация. Надеюсь вы найдете бескровный вариант !