Приветствую, коллеги

Преамбула:
1. событие BTE 940 "ПРОВОДКА: проверка после выхода из ОП-ОБРАБОТКИ" помещает в память данные выравнивания,
2. в дальнейшем при создании документа выравнивания данные из памяти используются одним из Шагов Третьего этапа ("Документ полностью") Замещения; логика обработок прописана в юзер-экзите.

Проблема:
предпосылка в этом Шаге сейчас пустая, т.е. Шагом обрабатываются все документы FI (большинство из которых к выравниванию вообще никак не относится).

Соответственно, я подумал, как из всего множества обрабатываемых в этом Шаге вычленить только реально нужные, т.е. только документы выравнивания, чтобы не гонять через этот Шаг всё на свете?

Перечислять все возможные SY-TCODE в предпосылке показалось плохой идеей, поскольку, во-первых, я могу какой-то из TCODE упустить, а во-вторых, я не знаю, какие TCODE используются в различных фоновых выравниваниях (при переносе НДС, разноске выписки и, т.д.).

Подумалось, что на старте работы юзер-экзита можно проверять наличие существования специфичной для выравнивания T_POSTAB (т.е. если таковая существует, юзер-экзит выполняется, а если таковая отсутствует, то он прекращает работу). Соответственно, друзья, вопрос звучит просто: как вы считаете, подойдёт ли такое решение? И если это всё-таки неприменимо, то в чём тут проблема? И как можно было бы по-другому пояснить Шагу Замещения, что обрабатываться должно только выравнивание?

Заранее благодарен за любые соображения!

Я так понял, автор че-то позамещать хочет на третьем моменте, а не проверить перечень анализируемых позиций.


Как раз SY-TCODE использовать - это нормально. Перечень транзакций для выравнивания довольно узок:
FB05 - проводка с выравниванием
FB1K - кредиторы
FB1S - счета ГК
FB1D - дебиторы

Есть огромное количество других, но все они (это видно в SE93) содержат "значение по умолчанию" из семейства FB*.
То есть даже при запуске F-44 SY-TCODE вернет FB1K. Дальше аналогично.

Автоматические транзакции выравнивания внутри содержат call transaction 'FB05'. Таким образом, этими четырьмя транзакциями ограничивается все.
Вычет по НДС (26 программа) тоже запускает FB05.

Таким образом, использовать SY-TCODE - вполне сносное решение.

Из альтернатив - вид документа, но это только если с этим есть четкая дисциплина. К тому же FB05 позволяет вид документа задавать, так что, наверное, не подойдет.

Из более сложного - только в 940 событии отправлять в память индикатор (тупо = 'X'), а на третьем моменте кушать его из памяти и сразу чистить. Считывание единичного параметра из памяти по ресурсам никак не ударит. В качестве предпосылки в таком случае можно использовать, к примеру, минимальный набор (БЕ + новый документ, то есть BELNR = '' OR BELNR LIKE '$*). Остальное влепить в начале пользовательской подпрограммы и выходить по чеку, если что не так.

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

Yozhhhhh, огромное спасибо за пояснения по TCODE - думаю, это то, что надо (посмотреть через se93 я не сообразил). Собственно, так и сделаю, не мудрствуя лукаво.
C ВД, увы, не пройдёт - дисциплина это очень хорошо, и лишь немного жаль, что это не про нас.
P.S. И всё же, проверка на предмет существования T_POSTAB совсем не айс? Просто любопытно...

Если не знает транзакцию проверяй программу

Забирайте в начале замещения через assign SAPMF05A-POSTAB, есть такое в стеке.
Только смотреть надо не на то, пустая или нет. А на наличие записей с xaktp = 'X' при частичном выравнивании или xvort = 'X' при выравнивании с остатком.
Более подробно про эти поля как раз в ссылке у darkduck.

Все транзакции проводки имеют прогу SAPMF05A, че он там напроверяет?
Кстати, а по поводу программы ценная мысль... В фоновом режиме sy-tcode ничего не вернет, проверить можно только на sy-cprog... И получается, что при пакетнике в lsmw, запущенном в фоновом режиме, предпосылка на sy-tcode не отработает... Это только гипотеза, но, похоже, так и случится.

Коллеги, спасибо за подсказки и идеи
Yozhhhhh, всё-таки сомнения насчёт TCODE в фоновом режиме отчасти подтверждаются. Кстати, и приведённый вами закрытый список TCODE на поверку тоже оказался не совсем исчерпывающим - в частности, сходу обнаружился ещё один TCODE выравнивания, FBA8, ну т.е. при перечислении TCODE в предпосылке шансы что-то упустить всё-таки есть.

В-общем, так-таки попробую на старте экзита анализировать позиции POSTAB, и об итоговом результате черкну здесь в телеграфном стиле.

P.S. darkduck а этот ваш материал, конечно, я знаю, и даже не в одной ипостаси

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

это есть факт (с)
я понял что задумка автора была поймать все выравнивания

Добрый день!

bilimba,
скажите, пожалуйста, третий этап замещения отрабатывает без проблем? Вам удалось вычленить выравнивание описанным способом, через assign к postab в 3 этапе замещения ?

Berg, добрый день!
Нет, вычленить именно выравнивание в Замещении так и не удалось, в итоге нужный мне бизнес-процесс пришлось выделить отдельным новым Шагом

Что именно не получилось-то? Там и вычленять ничего не надо, даже assign не нужен. Таблица глобальная, уже заполненная сидит.

Изначально я думал проверять факт существования T_POSTAB - думал, что она специфична именно для выравнивания, но в процессе увидел, что при выполнении SAPMF05A она есть и в обычном документе без выравнивания, и дальше рыться в этом направлении не стал (возможно, зря)

Таблица там называется POSTAB. Она действительно есть всегда, а как же ей не быть, когда она объявлена как глобальная? Просто для обычной проводки она пустая. А в транзакциях выравнивания она заполнена. Так что да, это Вы погорячились