Возможно старая и очевидная тема, но пролистал форум, не нашел ответов. Стартуем не с начала года, нужно при загрузке зп грузить все перерасчеты (указывать для каждого во к какому периоду он относится). Стандартная BAPI BUS7023 вроде не умеет такого (или я не понял как ей отделить "для" и "в" периоде). Посоветуйте как быть

есть две таблички t558b и t558d + фунция trans
я думаю, что должно все получиться.

Это все понятно и работает. Как мне сказать, что вид оплаты 0001 в сумме 1000р относится в 01.2008 за 01.2008, а 0001 в сумме 200р относится в 05.2008 за 01.2008? То есть, как перерасчитанное значение вида оплаты положить с признаком "для периода".

Известные грабли. Никак в стандарте.
В общем, либо нарываемся на косяки с отчетностью по ЕСН, либо с отчетностью по НДФЛ. Править - корректировками баз через 15ИТ, например

Ни разу не пробовал , но если загрузить все данные, которые относятся к январю в январе, прогнать загрузочную схему - вычистить таблицы T558B и D , потом загрузить январь в феврале ( если перерасчетов не было, то загрузить то-же, что было в январском расчете , потом февраль в феврале, потом расчитать загрузочной схемой уже 2 месяца , потом снова очистить таблицы , и так повторять до момента старта.

Т.е. заготовить N комплектов загрузочных файлов, и выполнять последовательно расчет с принудительным перерасчетом с января, каждый раз перезагружая таблицы "правильным" набором данных .
Геморрою много, займет сама процедура кучу времени, но по идее такая вот "послойная загрузка" должна дать вам то, чего хочется

Угу. Но стандартная функция TRANS так не умеет.

Возможно, я не понял, но ИМХО функция TRANS только импортирует данные из соответствующих таблиц в таблицу IT.
Function TRANS transfers the payroll results from different tables, that were written from the old payroll account on a sequential data medium, to the internal input table IT.

А в кластер данные записываются как обычно EXPRT UR.
Это в схеме RU30.

Верно понял Только мне от этого не легче

Собственно да, согласен А если в схеме RU30 прописать вместо PGM TRN => PGM ABR ? И указать принудительный обратный расчет? Или это уже фантазия?

Тогда возникает вопрос, а как правильно положить данные в таблицы T***

мне кажется поможет следующий подход:

1) делим ВО по периодам и кладем их (все ВО за ОДИН период) в табличку переноса;
2) создаем управляющую запись расчета за нужный период;
3) производим расчет ЗП с помощью схемы YLK0;
4) удаляем управляющую запись расчета и записи из таблички переноса ВО;
5) шаги 1-4 повторяем для каждого периода;

по-идее должно помочь

Попробовал. Не помогло. Функция TRANS загружает данные только из того, периода, который относится к управляющей записи. Следовательно, никогда не получится ссылки "для периода". Всегда Для периода будет равно в периоде.

Тоже попробовал. Данные в кластере просто перетираются тем, что идет из TRANS. Таким образом теряется ссылка на "для периода".

Попробовал еще раз. Доработал схему RU30 в части загрузки уже сохраненного расчета и добавления к перерасчету. Заработало. Придется делать комплект файлов нарастающих и грузить... Ужснах.

ну подождите, вот например я недавно грузил данные за предыдущий год, вот что в кластере:
http://radikal.ru/F/s44.radikal.ru/i103/0901/3e/6ad0e9ef03cd.jpg.html
соответственно если немного изменить пункт 1 в моем алгоритме: выбираем все ВО, которые относятся к нужным периодам и кладем их в табличку, а далее по алгоритму. И тогда "в-период" у нас будет равен управляющей записи, а "для-период" данным ВО. Так же должно работать?

Ест ньюанс, оказывается, в функции PGM. Если по умолчанию оставить TRN, то независимо от управляющей записи все во лягут в периоде=для периода=период из T558*.

Поэтому я первый раз загрузил все во таким образом, чтобы оригинальные цифры легли так, как они были начислены по факту. А второй раз грузил только суммы перерасчетов и в схеме исправил на PGM ABR