Механизм расчета заработной платы в SAP HCM — надежный и в то же время гибкий инструмент. Этот инструмент позволяет учитывать любые требования законодательства и локальных нормативных актов в сфере оплаты труда сотрудников.
Однако обратной стороной этой универсальности является сложность и чрезвычайная чувствительность к изменению настроек.
Например, на рисунке выше показан вид настройки типа оплаты.
Один неправильно выбранный параметр или флажок приведет к неправильному расчету.
При этом цена ошибки может быть очень высокой как в денежном, так и в репутационном плане.
Также стоит отметить, что ошибка может проявиться не сразу, а лишь через несколько месяцев после расчета.
В этом случае может возникнуть необходимость перерасчета заработной платы за несколько месяцев или создания специальной корректирующей схемы расчета.
Оба эти сценария чрезвычайно трудоемки и рискованны, и их следует рассматривать только в качестве крайней меры.
Откуда могут взяться такие ошибки? Функционал HR постоянно развивается, меняются законодательные требования и требования бизнеса.
Чтобы соответствовать этим требованиям, вам необходимо регулярно вносить изменения в настройки SAP HCM. В нашей компании все изменения реализуются в ежемесячных релизах.
Стандартные обновления от SAP также выходят примерно раз в месяц и устанавливаются вместе с релизом.
Обновления от производителя представляют собой пакеты, содержащие заметки об изменениях программ и настроек.
На рисунке показан состав пакета обновления SAPK-60866INEAHRCRU, который содержит четыре зарплатные накладные для России.
Установка собственных релизных разработок/настроек и стандартных пакетов обновлений может изменить текущие настройки и привести к некорректной работе системы.
Регрессионное тестирование
Как я могу убедиться, что стандартные обновления SAP и мои собственные новые разработки/индивидуальные настройки не повлияли на существующую функциональность? Можно, конечно, проанализировать все изменения, все стандартные записи.Создайте для них примеры и проведите функциональное тестирование.
Но здесь нужно учитывать, что количество заметок может исчисляться десятками и они могут влиять на сопутствующий функционал.
А если к этому добавить размер нашей компании (SAP HR насчитывает более 270 000 сотрудников), то количество возможных случаев превысит разумные пределы.
Для решения этой проблемы сотрудники нашего отдела управления персоналом SAP Business Applications разработали механизм регрессионного тестирования заработной платы.
Суть этого механизма довольно проста.
Сначала создается стандарт – путем расчета заработной платы по исходной системе.
Затем в систему устанавливаются обновления и выполняется новый расчет заработной платы.
Полученные результаты сохраняются как данные выпуска.
И на последнем этапе эталон сравнивается с данными релиза.
Тестирование происходит по всему объему табельной численности.
Теперь поговорим об этом более подробно.
Наш SAP HCM имеет классическую трехсистемную структуру.
Система разработки (назовем ее HRD), система тестирования (HRT) и производственная система (HRP).
Все улучшения обязательно тестируются в HRT, а технические характеристики тест-системы приближены к характеристикам продукта.
Регрессионное тестирование делится на этапы:
- Подготовка системы HRT
- Подготовка тестовых данных
- Удаление стандарта
- Удаление релиза
- Сверка результатов
Ээтап подготовки тест-системы ЗГТ
На этом этапе специалисты базы готовят систему HRT. HRT восстанавливается из резервной копии продуктивной системы на определенную дату.Те.
данные в HRP и HRT становятся идентичными.
?Этап подготовки тестовых данных
Несмотря на то, что данные между производственной и тестовой системами согласованы, тестирование расчетов заработной платы необходимо проводить на еще не рассчитанном периоде.Для этого необходимо подготовить тестовые данные:
- Создание временных меток
Для этого с помощью разработанной программы генерируются отметки времени прихода/ухода в IT2011 из расписания сотрудника в IT0007.
- Ведение данных IT0027 Распределение затрат
- Ведение данных для расчета авансовых платежей
Для этого заполните IT267 «Нециклические платежи», используя транзакцию HRUU0267. Для расчета отпусков, премий, увольнений и различных видов больничных создаются тестовые данные примерно по 20 сотрудникам.
После ввода всех тестовых данных выполняется резервное копирование системы HRT.
Эстандартный шаг удаления
Этот этап включает в себя:- Выполнение оценки времени
Использование RPCS0000 может значительно сократить время оценки времени.
- Справочник по сохранению результатов оценки времени
Фрагмент созданного стандартного файла оценки времени:
- Выполнение расчетов по заработной плате (регулярные и межрасчетные платежи)
- Сохранение результатов расчета для последующей сверки
Разработана специальная программа для сохранения данных расчета в системе разработки HRD. Одним из входных параметров этой программы является сгенерированный вариант отчета PC00_M99_CWTR: 
После запуска этой программы стандартные результаты расчета заработной платы будут сохранены в системе разработки HRD: 
- Создание транзакций
После этого с помощью специально разработанной программы данные транзакций загружаются в систему разработки HRD как стандарт для будущей сверки.
После выполнения этой программы эталонные результаты проводок в финансовую систему будут сохранены в системе развития HRD: 
- Формирование реестров переводов
С помощью разработанной пользовательской программы эти регистры также сохраняются в текстовых файлах в качестве справки.
Фрагмент стандартного файла реестра перечислений заработной платы: 
- Формирование налоговой отчетности
Для нужд тестирования они были расширены логикой хранения результатов в прозрачных таблицах.
После формирования налоговой отчетности в тестовой среде эти результаты передаются в систему разработки с помощью пользовательской программы.
Итоговый стандарт налоговых данных: 
? Шаг удаления релиза
После удаления стандарта необходимо восстановить систему тестирования из резервной копии, сделанной после этапа подготовки тестовых данных.Те.
получаем систему с введенными тестовыми данными, но без расчетов.
В данной системе установлены все обновления – собственные разработки и стандартные пакеты обновлений от SAP. После чего проводятся регулярные и межрасчетные расчеты по заработной плате, формируются проводки и другие действия аналогичны тем, что были на этапе удаления стандарта.
? кран сверки
После удаления стандарта и его выпуска наступает очередь этапа сверки.На данном этапе Сравниваем данные, полученные до установки обновлений, с данными об обновленной системе.
И на основе анализа несоответствий делаем выводы о наличии ошибок в поставляемых обновлениях.
- Сверка результатов оценки времени
В качестве одного из параметров мы указываем каталог, в котором был сохранен файл стандарта оценки времени.
Если есть разница между справочными и релизными данными, этот отчет отобразит ее.
- Сверка данных транзакций
Для сверки используется пользовательский отчет, в котором в качестве параметров указываем дату выпуска и ссылку: 
Если есть разница между справочными и релизными данными, этот отчет отобразит ее.
- Сверка налоговой отчетности
Где входными параметрами являются даты удаления стандарта/релиза и пользователя, под которым произошли эти изъятия: 
Если есть различия в данных, они отображаются.
- Сверка заработной платы
Сейчас в системе разработки данные сверяются со стандартом и релизом с помощью разработанной пользовательской программы: 
Все полученные расхождения доступны в отчете.
- Сверка реестров переводов
Сравниваем эти справочные данные с реестрами переноса, созданными после установки обновлений.
Если есть расхождения, они отображаются в отчете.
Все полученные расхождения анализируются специалистами отдела поддержки SAP HCM. Если причиной несоответствия являются ошибки в настройках/разработке, они исправляются и тестируются на следующей итерации.
Те.
тестовая система вновь восстанавливается из резервной копии, сделанной после создания тестовых данных, устанавливаются обновления с исправлением ошибок и заново проводятся этапы выпуска и проверки.
Такой подход позволяет очень качественно протестировать такой ответственный процесс, как расчет заработной платы, и используется не только при тестировании ежемесячных релизов/обновлений, но и в проектной деятельности.
Так, только в этом году он был успешно применен на двух крупных проектах – реорганизации юридических лиц и обновлении системы SAP HCM до уровня расширения 8. Теги: #Управление разработкой #разработка #тестирование ИТ-систем #тестирование с использованием #HR-технологий #sap #расчеты #регрессионное тестирование #зарплаты
-
Ядерная Война
19 Oct, 24 -
Тестирование Модуля Cisco Nme-Rvpn + По Kav
19 Oct, 24 -
Как Я Ремонтировал Аккумулятор Ноутбука
19 Oct, 24 -
Москва, 9 Августа — Backend Stories 4.0
19 Oct, 24 -
Обучение Онлайн
19 Oct, 24
