Добрый день.
Может кто сталкивался с таким багом.
В постоянном переносе полей к полям HSL и TSL поставил эксит.
Для TSL он срабатывает, а для HSL - нет.

При полном удалении HSL и TSL из постоянного переноса полей, для TSL сумма не переносится , для HSL каким волшебным образом переносится сама.

То есть, на HSL не действует постоянный перенос полей и тем более эксит в нем.

Как можно устранить этот баг ?

cумма во внутр валюте переносится всегда без изменений, поскольку это значение вкачивается в какую-то внутр. структуру сразу после отработки правил выбора регистра и дальше вытаскивается оттуда уже перед самым обновлением группы таблиц. Поэтому насколько мне известно, вешать экзит в самом пост. переносе бесполезно, если только пораньше, в точке выбора регистра, когда еще не заполнились glu1 b glu2 как надо. А зачем вам кстати ее менять?

Заметил такой нюанс, в песочнице эксит на HSL срабатывает.
А в тест квалити - нет

Значит все-таки где-то баг ?

гм... ну тогда возможно баг! раньше это была фича

Добрый день!
Мы на проекте с помощью UEs на уровне постоянного переноса полей изменяем значения полей HSL и KSL.
Причиной, почему в одной системе UE «срабатывает», а в другой нет, может быть то, что не была выполнена актуализация кодирования (программа RGBCFL00) в целевой системе. К сожалению, инициализация выполнения этой программы не включается в качестве программы постобработки при изменении настройки постоянного переноса полей. Проверить можно, посмотрев отчет RGIMF000.
Если изменять таким образом значение поля TSL, то нужно иметь в виду, что присвоенный для этого поля UE очищается при повторной инсталляции соответствующей группы таблиц.
Не претендую на достоверность, поскольку занимаюсь FI/SL не так давно. Просто описываю ситуацию как она есть у нас.

Здравствуйте, Bourbon.
Спасибо за ответ.
Перегенерацию делал и тр. GZZG (пр. RGZZGLUX), и тр. GCCG (пр. RGBCFL00).
Сразу же смотрел пр. RGIMF000 , там все в порядке, программа перегенерилась, все постоянные переносы полей там присутствуют вместе с экситами.

Как выяснилось, проблема в инклуде J_3RF_TAX_GIMVINCL (E98_MVC).
Так вот, в строке 100 есть такой перформ:
PERFORM CALC_LOCAL_GROUP IN PROGRAM ('SAPLGLIN')
USING '10' L_WAERS
CHANGING <WA_GLU1>-HSL.

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

Добрый день, BRILDI.
Как вы верно заметили значение в ВВ вычисляется именно подпрограммой CALC_LOCAL_GROUP, но это не проблема.
Но пробема тут в другом, постоянный перенос полей отрабатывает раньше "пользовательского"преноса полей определенного в GCF*. А именно в в пользовательском переносе полей отрабатывает UE E98_MVC для переноса объекта ЭНУ, где заодно и вычисляется значение сумм ВВ.

Если вы хотели менять значение HSL, нужно это было делать именно в этом UE. Зачем трогать потоянный перенос полей, если есть пользовательский перенос.

Добрый день!
Вопрос в догонку по изменениям суммовых показателей.
Столкнулись с ситуацией, что при попытке заместить KSL/HSL на 0,00, замещение не выполняется (правильнее сказать, оно выполняется, но в последствии замещенное значение заменяется на исходное). Неважно на уровне постоянного или переменного (пользовательского) переноса полей вешать UE, эффект тот же.
Кто-нибудь сталкивался с подобной ситуацией? Как побороли?
Спасибо.