Привет коллеги!
Искал по форуму и на нашел. А меж тем - у SAP, для российского расчета зарплаты, есть функционал под названием Report Management System (HCM_LOC_CI_91).
Почитать можно тут: https://help.sap.com/viewer/319c1e41862 ... 4147b.html
Кто нибудь пробовал его включать и настраивать? Может есть у кого презентации от SAP на эту тему? Есть ли практический смысл от этого функционала? Какие сценарии использования?

Есть презентация. Пощупали - вроде как работает.
Практический смысл - для форм "тяжелых" отчетов не обрабатывать все табельные при каждом запуске. Типа, раз запустил, сохранил инфу в ИТ 3400. Запустил следующий раз - инфа быстренько подхватилась из инфотипа. Неправильно подготовились данные для нескольких табельных - переделываем ИТ 3400 только для них, "здоровые" табельные не нужно заново обрабатывать.
Как-то так.

именно, что только попробовали:)
суть в чем:
1) показатели отчета по каждому челу теперь сохраняются в табличках
2) отчет формируется в 3х режимах: по старинке (чего-то собрал, выплюнул в форму), по-старинке с сохранением в RMSные таблички, на основании RMS табличек. Это значит, что теперь каждое подразделение может формировать отчет по своим ТН, а мы его потом схлопнем в один.
3) построен процесс формирования отчетности (по аналогии с расчетом ЗП: подготовка отчета, закрытие периода, корректировка). инфотип, про который писал calm - это аналог ИТ0003.

Из плюсов
+теперь промежуточные значения хранятся в таблицах, значит наконец можно по-человечески анализировать кто в какую графу вошел
+таблицы плоские, кластеров нет
+раз таблицы, значит есть варианты корректировки руками (стандартных интерфейсов для этого нет, но нам-то это раз плюнуть... ну максимум - два)
+после исправления ошибки не обязательно переформировывать отчет по всему предприятию, достаточно по отдельным людям, перезапись в таблицах производится нормально
+по сути окончательная версия отчета собирается не по исходным данным ЗП, а по RMSным таблицам. А это значит существенно быстрее
+можно встраивать свои проверки формы (все построено на ООП и можно прописывать свои методы и бизнес-шаги)
+вроде бы можно делать корректировочную отчетность (утверждение громкое, но почти безосновательное - сам не пробовал)

Из минусов:
- пока в стандарте только одна форма. Если пользователи увидят такую технологию в одном отчете, то потом сильно захотят и другие.
- если включать новые формы, то надо много абапа. очень много. он простой, примеры стандарта есть, но его много. Раньше была одна логика сбора: по исходным данным. Сейчас 2 - исходные данные + RMS таблицы. Соответственно, писать надо 2 вещи: 1- разложить данные по RMS-таблицам, 2 - собрать потом данные на основании rms-таблиц (в пдф или xml)

P.S. Все это впечатления шапочного знакомства. В принципе, штука перспективная, но хз сколько там багов

Заглянул, так сказать, под капот этой штуки.

Абапа там... Ковырять не перековырять..
Около 20 ракурсов с хелпом в духе "чтобы создать логическую запись, укажите атрибуты логической записи".
Код такой.. не для скучных людей. От вызова метода типа "получить список табельных, участвующих в отчете" до селекта к таблице проходит 5 (пять) уровней вложенности методов (стек вызовов). Ну и т.п.
Создание объекта делается через фабрики, не менее чем тремя уровнями стека вызовов, причем на конце имя класса всё равно будет прописано хардкодно.
Бизнес-логика раскидана по нескольким классам, которые прописываются в десяток ракурсов.

Короче, если пользователю не понравится какая-нибудь цифирька в отчете, распутывать клубок будет тем ещё приключением.

Дабы не плодить темы, решил спросить тут.
Кто нибудь в RMS для страховых взносов пользуется фоновыми операциями, теми что позволяют формировать фоном XML и PDF.
Как отрабатывает фоновое задание, когда из текущего периода формируешь данные из предыдущего периода.
То есть сейчас нахожусь в 4ом квартале, слой за 3ий квартал закрыт.
Фоновик прерывается не начавшись с сообщением о том что нет открытых отчетов.
В диалоге работает норм.

После анализа склоняюсь к выставлению тикета, но на всякий случай решил предварительно уточниться здесь)

Здравствуйте дамы и господа.

Наш проект SAP сворачивается, но под закат, было решено настроить RMS СЗВ-стаж.
Помогите, пожалуйста, последний раз, разобраться с этой технологией.
Вычитал, что поставщиком данных для СЗВ-стаж является отчет СЗВ-М.
Пытался (безуспешно) настроить SZVM и область отчетности для нее. Настраивал как виртуальную орг.единицу с использованием признака 33ONM.
Настроил ежемесячный график отчета (SZVM M M) для 2021 года с типом REG0 (Регулярный).
Создал сессию для периода 01 2021 года, запускаю "Агрегацию данных", получаю сообщение "HRPAY99RU_RMS_PL088 - Список сотрудников для вида отчета SZVM в области SZVM пустой на дату 31.01.2021.
Отчет СЗВ-М ранее не формировали из SAP, но при выполнении отчета транзакцией "HRPADRU_SZVM - Форма СЗВ-М" данные за указанный период выбираются, файл формируется.
Для CITAX, знаю, что область отчетности определяется по таблице RUDAT (Плательщик НДФЛ), как должно быть настроено для СЗВ - не понятно.
Подскажите, как выглядит общая схема настроек для RMS СЗВ-стаж или где найти презентации с описанием настроек для RMS СЗВ-М и СЗВ-стаж.

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

Заранее благодарю.

Опыта настройки отдельно СЗВ-стаж, минуя СЗВ-М нет,
но пользуемся СЗВ-М на RMS, СЗВ-стаж факультативно запускал, не считая особенностей проекта СЗВ-стаж формируется.
PUST на проекте используется?

Что показывает журнал в спулах по итогам агрегации?

Уважаемый gomer4ik, спасибо что откликнулись.
Я постараюсь подробней описать текущую ситуацию сегодня чуть позже. Буду вам очень признателен за любую помощь.

Здравствуйте, ситуация следующая (отчет SZVM):

Я в ступоре.
Сначала настроил периоды в ракурсе V_T7799RU_RMS_CD следующим образом:
M 2021 1 2021 2 01.01.2021 31.01.2021
M 2021 2 2021 3 01.02.2021 28.02.2021
M 2021 3 2021 4 01.03.2021 31.03.2021
M 2021 4 2021 5 01.04.2021 30.04.2021
M 2021 5 2021 6 01.05.2021 31.05.2021
M 2021 6 2021 7 01.06.2021 30.06.2021
M 2021 7 2021 8 01.07.2021 31.07.2021
M 2021 8 2021 9 01.08.2021 31.08.2021
M 2021 9 2021 10 01.09.2021 30.09.2021
M 2021 10 2021 11 01.10.2021 31.10.2021
M 2021 11 2021 12 01.11.2021 30.11.2021
M 2021 12 2022 1 01.12.2021 31.12.2021

Далее, настраивал периоды в ракурсе V_HR99RURMSD_ASE.
Для января все сохранилось без проблем:
1 2021 REG0 Регулярный сеанс 01.01.2021 31.01.2021

При попытке настроить период для февраля месяца
2 2021 REG0 Регулярный сеанс 01.02.2021 28.02.2021
получил сообщение об ошибке о том, что начало периода должно быть 1 января.

Настроил все остальные периоды, начиная с февраля месяца по декабрь указав в качестве начала периода 1 января:
2 2021 REG0 Регулярный сеанс 01.01.2021 28.02.2021
3 2021 REG0 Регулярный сеанс 01.01.2021 31.03.2021
4 2021 REG0 Регулярный сеанс 01.01.2021 30.04.2021
5 2021 REG0 Регулярный сеанс 01.01.2021 31.05.2021
6 2021 REG0 Регулярный сеанс 01.01.2021 30.06.2021
7 2021 REG0 Регулярный сеанс 01.01.2021 31.07.2021
8 2021 REG0 Регулярный сеанс 01.01.2021 31.08.2021
9 2021 REG0 Регулярный сеанс 01.01.2021 30.09.2021
10 2021 REG0 Регулярный сеанс 01.01.2021 31.10.2021
11 2021 REG0 Регулярный сеанс 01.01.2021 30.11.2021
12 2021 REG0 Регулярный сеанс 01.01.2021 31.12.2021

в транзакции HR99RU_REPSE_MAINT Создал сеанс для января 2021 года.
Запустил агрегацию, все выбранные записи по сотрудникам упали в ошибку, какую - не понятно.
Удалил журнал, закрыл сеанс, открыл снова для января, запустил агрегацию - все данные выбрались без ошибок.
МАГИЯ!
Закрыл сеанс за январь 2021, открыл следующий сеанс для февраля 2021.
Получил ошибку: "Для SZVM ALLDIV 02 2021 некорректно настроен период сеансов"

Вернулся в ракурс V_T7799RU_RMS_CD и поменял дату начала периода на 01.01.2021 (Почему так - абсолютно не понятно).
Периоды стали выглядеть следующим образом:
M 2021 1 2021 2 01.01.2021 31.01.2021
M 2021 2 2021 3 01.01.2021 28.02.2021
M 2021 3 2021 4 01.01.2021 31.03.2021
M 2021 4 2021 5 01.01.2021 30.04.2021
M 2021 5 2021 6 01.01.2021 31.05.2021
M 2021 6 2021 7 01.01.2021 30.06.2021
M 2021 7 2021 8 01.01.2021 31.07.2021
M 2021 8 2021 9 01.01.2021 31.08.2021
M 2021 9 2021 10 01.01.2021 30.09.2021
M 2021 10 2021 11 01.01.2021 31.10.2021
M 2021 11 2021 12 01.01.2021 30.11.2021
M 2021 12 2022 1 01.01.2021 31.12.2021

После этого удалось запустить агрегацию и она отработала без ошибок.
Закрыл сеанс, открыл следующий - март 2021, запустил агрегацию и вуаля - опять все записи свалились в ошибку:
"Открытый отчет не найден для ключа 33SZVMALLDIV20211231" (класс сообщений HRPAY99RU_RMS_DL, № сообщения 19)

Список сотрудников в журнале пуст.

Что не так? Я в ступоре.

Заранее благодарю за помощь.

Пробуйте удалить записи из V_HR99RURMSD_ASE.
В V_T7799RU_RMS_CD восстановите данные как настроили сначала (01.01.2021 - 31.01.2021, 01.02.2021 - 28.02.2021 и т.д.).
Сеанс отчетности на всякий случай верните в 01.2021
Перед запуском агрегации кому-нибудь активному ТН в 01.2021 в инфо-типе 3400 передвиньте подтип SZVM на 01.01.2021.

А как вернуть сеанс отчетности в 01.2021? Удалить сеанс невозможно, поскольку есть журналы, и отредактировать текущий индекс периода невозможно.
Или сброс в ИТ3400 даты и есть перенос сеанса в 01.2021?

Если вы не в проде, используйте отчет *RMS*RDE*.
когда удалите слои, то система позволит удалить полностью сеанс отчетности, после этого создадите заново

Спасибо большое за помощь!
Удалось почистить журналы, после очистки записей в ракурсе V_HR99RURMSD_ASE агрегация прошла успешно.

Появилась новая ошибка при попытке сохранить орг.присвоение или финализировать журнал:
"Запись RMS 33SZVM_ACCEPT_STATUS2021022800000000000000ALLDIV должна быть записана только с ее даты окончания для периода".

Ошибка не мешает сохранять орг.присвоение и закрывать журнал.