Всем привет!
Насколько я знаю стандартный SAP PY - крайне не рекомендуется менять записи в кластере PY ручками или еще чем, кроме драйвера. Поскольку это собъет индекс и проводки разъедутся.
А есть ли подобные ограничения для кластера B2?
Вопрос вот в чем - один из клиентов в процессе миграции из одной системы SAP в другую потерял кластер B2. Обнаружили это уже после первого продуктивного расчета ЗП, откатить который уже нельзя. Имеем - B2 для всех сотрудников начиная с Июля сего года, ранее записей нет. Клиенту очень нужны для отчетности записи с Января сего года. Вопрос - что случится с кластером, если я сейчас загружу B2 за периоды предшуствующие существуюшей записи за Июль? Тенически такая возможность пока есть - историческая система SAP и она все еще доступна. Не сломаю ли я какой индекс...

Для зарплатной таблицы RT сохранение порядка записей важно для корректного сторнирования проводок . Таблицы раздела B2 не участвуют в создании проводок. Порядок записей в них не имеет значения .

На мой взгляд, сломаться ничего не должно. В кластере зарплаты идентификатором записи является ТН + порядковый номер расчета. По этой причине невозможно "засунуть" в кластер новые расчеты, ранее существующих.

В кластере B2 идентификатор записи ТН+месяц(в формате год+месяц). Тут нет никакого порядкового номера. Записи в это кластер можно загрузить независимо друг от друга в любой момент времени. Да и пересчетов тут никаких нет.

Кстати, если остальные данные были загружены, то может вообще не заморачиваться с загрузкой. Запускается оценка времени и все. Это можно не только с января этого года сделать, а вообще за все время.

Спасибо всем за ответы!

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

Поддерживаю, если есть возможность загрузить, то лучше загрузить.

честно говоря никогда не мигрировал кластер B2...
Я бы делал в следующем порядке:
1) убрал бы индикатор переоценки времени по всем работникам
2) сделал бы оценку времени с указанием периода: с первой даты в миграции до конца месяца предшествующего первому продуктивному расчету. При этом система сама создаст кластер в стандартном порядке, не пересчитывая уже созданные записи
3) перезаписал бы кластер данными миграции
4) убрал индикатор перерасчета для оценки времени и ЗП

И мне кажется roustr прав с концепцией хранения кластера, и нет видимых противопоказаний для создания кластера уже "после". Единственное можно еще подумать про интеграцию со всякими CATS и прочими, если она есть. Но здесь опять-таки: порядок записей в кластере B2 определяется периодом, не каким-то идентификатором.