Коллеги подскажите. Нужно чтобы вид оплаты не пересчитывался.
Полагаю, что это в импорте результатов последнего расчета
PORT Правило P06 NOAB - Передача релевантных данных в LRT?

В ракурсе v_t512w_d у вида - класс обработки 06 "0 - Вид оплаты не переносится", ветка у
Правила для P06 просто - 0.

Поделитесь соображениями.

Есть операция RETRO.

Возвращает Y если это ретро-расчет, N - в остальных случаях.

Как вариант:
Если ретро-расчет, то в конце перед записью в кластер нужно восстанавливать изначальные значения rte, num, amt для вида оплаты, чтобы он оставался с теми же значениями (с которыми когда-то изначально рассчитался).

А вообще, для чего это Вам?

Не туда смотрите. Да, таблица ORT заполняется прошлым расчетом. Вот только "прошлый" расчет может быть двух типов:
1) Прошлый вариант этого месяца. Допустим, мы считаем май месяц, во время которого запускается перерасчет апреля. Во время перерасчета апреля можно выполнять работы со старой версий расчета апреля. Этот тип возникает только во время перерасчета.
2) Расчет прошлого месяц. Для апреля,например, это будет март. Этот тип доступен всегда.

Так вот, PORT Правило P06 NOAB обработывает прошлый расчет второго типа. Этой функции предшествует вызыв RUPRT L (IMPORT L), которая как раз и загружает расчет прошлого месяца.

Фразу Нужно чтобы вид оплаты не пересчитывался я понял как - однажды посчитанное значение ВО при перерасчете нужно оставить без изменений. Если это так, то PORT Правило P06 NOAB не то место, на которое нужно обращать внимание для решения этой задачи.

Решить задачу можно разными путями.
1. Самодельный. По время расчета ВО, проверить что имеет место обратный расчет, и в этом случае взять значение из ORT. Приэтом нужно обеспечить, чтобы в ORT в это время был предыдущий вариант расчета этого месяца (функция IMPORT O).
Либо после расчета заменить расчитанное значение старым.
2. Использовать стандартные функции, например механизм просрочки (функция PRDNT, управлется таблицей T51P6). Либо можно использовать механиз, используемый при расчете налогов( 68-й класс обработки)

Я бы использовал PRDNT. Включите Ваш ВО в T51P6. В случае пересчета PRDNT восстановит строе значение. Я не помню, есть ли в настройке значение "восстановить старое значение, разницу отбросить", что подходит в вашем случае. Если нет, то PRDNT вычислит разницу и положит в ARRRS. В следующем месяце разница попадет в AOA, где ее нужно будет удалить. Все.

ЗЫ. Ваш ВО не должен резаться по сплитам.Иначен все становиться очень нетривально.

У нас была ситуация немного другая.
Необходимо было при перерасчете распределять налоги только на те ВО, по которым изменилась сумма нетто.
Решили ее обходным методом, в схеме расчета.
Это то что нужно или нет?

У человека перерасчет по алиментам за прошлый месяц. Соответственно система пересчитывает % почтового сбора (согласно вилке).
А на почте все по факту (по месяцу расчета) и эти перерасчёт им не нужны.

В общем хотим, чтоб почтовый с алиментов не пересчитывался.
Вопрос открыт - подскажите.

см. выше сообщение RoustR, только учтите, что у вас как минимум 3 в/о связанные друг с другом, база для алиментов, сами алименты и почтовый сбор от них.

Обычно достаточно зафиксировать базу алиментов. Если база не измениться, то и сами алименты не изменятся, не изменятся алименты - не изменятся почтовые сборы.

Подозреваю, что это в принципе неправильно.
Если изменится сумма алиментов, то и поменяется сумма почтового сбора.