Коллеги!
Вот такая проблема со сведением JN20 из ТПР25.
Это сведение выполняет вычитание из суммы одного элемента налогового учета (поле RTAXOBJ) суммы другого. Для определенности возмем два первых пакета, в котором вычисляется формула
05-250-44 = FACT-01 - 04-160-4.
Первый пакет записывает сумму FACT-01 на элемент 05-250-44 используя операцию замещения поля RTAXOBJ на 05-250-44;
второй пакет записывает сумму 04-160-4 с обратным знаком на 05-250-44 используя ту же операцию замещения.
При проверке такого сведения выдается предупреждение
GL420: Возможно замещение значений других пакетов значениями данного
Diagnosis
For each field movement defined in the rollup, a separate internal table is generated in which the data is summarized and stored. If you use several rollup sequences in a rollup with different field movements, it is quite possible that a sequence will overwrite the values of a sequence that has already been processed.
Procedure
Please check whether the above situation can occur. If the quantities created by the different sequences are out of sync, you can execute the rollup. If a sequence could be overwritten, you should divide this 'critical' rollup into several individual rollups.

Собственно это и случается при выполнении сведения. Сумма из второго пакета затирает сумму из первого, то есть в результате мы имеем 05-250-44 = -04-160-4.
Разнесение таких пакетов по отдельным сведениям проблему не решает, кроме того, ведь в ТПР применили именно пакеты.

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

Собственно говоря, вы сами ответили на свой вопрос



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

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

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

Согласен. И для вычитания тоже. Но, повторюсь, это сведение взято из ТПР25, от себя изменен только код БЕ. Разработчики ТПР25 же как-то получали желаемый результат?

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



Если вы принципиально хотите использовать исключительно стандартные в рамках ТПР по 25 главе сведения, то обратитесь в SAP CIS за комментариями. Думаю, что наиболее исчерпывающий ответ смогут дать только SAP CIS, ведь именно они разрабатывали ТПР по 25 главе.

Коллеги!
Всем спасибо. Проблема решена. Спасает галка "ЗначНарастИтог" в управлении выполнением сведения.
Раньше почему-то не по глазам было.