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

а если по /n или /nex вышли?


Т.е. в вашей системе транзакция ещё не проведена, а в смежной уже зарезервировалось?
М.б. следует проводить "моделирование" резервирования, чтобы убедиться, что там лимиты есть? А уже в момент SAVE выполнять уже само резервирование, - распределённую транзакцию фактически: в ON COMMIT в фазе V1 резервировать во внешней системе, при не успешности у вас просто в обоих системах откатится.

Не прокатит. В зависимости от свободного от резерва количества во внешнеей системе мне нужно контролировать изменяемое количество в САП (выводить из заказа только свободное количество). При этом если два раза уменьшат количество одного и того же материала в заказе САП, то во внешней системе должен пройти адекватныйц контроль и предыдущее количество должно быть уже зарезервировано. Иначе в момент сохранения придётся заново всё перепроверять. Кроме того - в апдейт процессе не получается отправить в WEB коммит -JSON почему то не отправляется, хотя логи показывают, что запрос был сформирован. Короче говоря, нужен экзит в момент выхода без сохранения. Всю модель описывать тут не буду, но, поверьте на слово, надо именно так.

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

Жесть конечно (транзакционная)

Может быть тогда вам более сложным но надёжным путём пойти: вести учёт неких квитанций подтверждения резервирования в смежной системе?
Т.е. както так:
1. в момент изменения кол-ва прошёл успешно вызов резервирования во внешней;
2. в табличку-журнал легла запись-квитанция "для транзакции XXXXX резервирование произведено" (где XXXXX наверное из сериализуемого счётчика диапазона номеров брать уникальное);
3. если сохраняют заказ, то в конце апдейта своя запись-квитанция удаляется из таблички п.2;
4. периодическое фоновое задание (или админ) мониторит табличку 2, если там надолго зависли записи, значит ктото нафигачил резервирований в смежной системе, а у себя заказ не сохранил, - запускаем "подметальщик", прибиваем эти резервирования в смежной системе.

Тогда у вас более менее стабильно-гарантированно будет при любых выкидываниях из заказа (вплоть до перезагрузки сервера AS) обеспечиваться асинхронная чистка мусорных резервирований в смежной системе.

Такой вот "неонлайновый" метод у нас уже есть. И хранить "квитанции" нет смысла - у нас и так есть таймаут по которому резервы снимутся. И, в принипе ничего "жесткого-транзакционного" здесь нет. Реализовано уже всё, кроме отката:-(.

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

Т.е. задача сводится к "как повестить в VA02 кастомный обработчик кнопок выхода из транзакции".
А нельзя вызывать VA02 из Z-транзакции-обёртки, и в ней уже анализировать результат возврата назад? Вот тут квитанции бы тоже пригодились.

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

По второму - попробую добавить для этого заказа своё окошко принятия решения о сохранении.

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

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

Вы не совсем правильно поняли логику программы. Пользователь хочет уменьшить количество в заказе на Н штук, но так как этот заказа резервирует количества для внешней системы, то нужно "спросить" а можно ли убрать Н или только меньшее количество? В итоге система не позволяет пользователю вводить неправильные количества в определённом виде заказа. Соответственно, если мы уменьшае количество в заказе на Н штук, то это количество надо вывести из оборота во внешней системе. И вот чем долбше я отлаливлваю нужные экзиты, тем более уверенно река тянется к верному Z и BAPI. К примеру - как отловить в VA02 удаление позиции? ведь удаление это то же уменьшение количества (только в ноль) Вот я, лично, уже устал от дебага.

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


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

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