Есть необходимость подгрузить дополнительно пару видов оплаты в результаты расчёта за прошлые месяцы. Сделали схемку:
почему-то правит Р, О, когда надо А-актуальные результаты. Что не так, не понимаю

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

Может, поможет проверка на актуальность периода:
IF ACT
тут функции, которые будут работать только в периоде A
ELSE
тут функции для периода P
ENDIF

так смысл-то как раз и в том, что я никак не могу залезть в А, правит что раньше - если нет О, то Р, если есть, то О. А правит только если оно одно и есть.

причём похоже что вчера работало, но ничего не ставили

PGM AUS
всегда так работает
это же оценка, а не расчет

пример:
имеем
012009 в 012009 О
012009 в 022009 P
022009 в 022009 P
012009 в 032009 А
022009 в 032009 А
032009 в 032009 А

схема за 012009 выдас только один период
012009 в 012009 А

схема за 022009 выдаст 3 периода (т.е. запустится 3 раза)
012009 в 012009 P
012009 в 022009 A
022009 в 022009 A

схема за 032009 выдас 5 периодов
012009 в 022009 P
022009 в 022009 P
012009 в 032009 А
022009 в 032009 А
032009 в 032009 А

потому проще в схему добавить проверку что в прошлый прогон ВО еще не подгружали. Посмотрите стандартные RUU* там таакая есть

скажите, а сможет подобная схема не просто откорректировать существующие периоды расчета, а и создать отсутствующие?

нет
для этого расчет нужен

Если есть возможность, то можно поподробнее об этой проверке:

пример схема RUU1 формирует отсутствующий ВО /860 в прошлых периодах:

правило RUU4 проверяет чтобы /860 не существовал в RT

так чем-то поможет проверка? разве что отсечь О и П, чтобы не правились. А А оно не изменило. Попробуем конечно.

Вы спросили почему правиться O P A в оценочной схемме. Я вам и описал почему

А чтобы тока А поправить проще всего это сделать в обычном расчете пустив перерасчет с нужного периода. Тока тогда все пересчитаются

А в оценочной это сложно. Можно поппытаться использовать IMPRT N дабы понять последний это расчет для этого периода или нет

может, подход в принципе не правильный

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

Если так, то тогда что вам мешает грузить средние во все расчёты, включая O и P?

не вижу смысла тащить в старые (еще и кривые номера)
1. чем плохо просто перевести табельный в другую БЕ? Средние опять же останутся. Перерасчеты за прошлые месяцы могут приводить и к изменению средних.
2. ну или хотя бы создать новые в новой БЕ
3. "отремонтировать" кластер RPUDIR00 для начала. При кривой versc и оценочная схема может криво работать, смотря что криво в структуре. Система может и валюту попытаться пересчитывать т.к. пусто <> RUB

Согласен!
однако кластер все одно лучше отремонтировать