Механизм расчета заработной платы в SAP HCM является надежным и в то же время гибким инструментом. Этот инструмент позволяет учитывать любые требования законодательства и локальных нормативных актов в области вознаграждения сотрудников. Однако обратной стороной медали такой универсальности являются сложность и сильная чувствительность к изменениям настроек.
Например, на рисунке выше представлен ракурс настройки вида оплаты. Один ошибочно установленный параметр или флажок приведет к неверному расчету.
При этом цена ошибки может быть очень велика как в денежном выражении, так и в репутационном плане.
Также стоит отметить, что ошибка может проявиться не сразу, а только через несколько месяцев после расчета. В этом случае может потребоваться перерасчет заработной платы за несколько месяцев, либо создание специальной корректирующей схемы расчета. Оба эти сценария крайне трудоемки и рискованны, поэтому могут рассматриваться только как крайнее средство.
Откуда же могут появиться такие ошибки? HR-функционал постоянно развивается, меняются требования законодательства и требования бизнеса. Для соответствия этим требованиям необходимо регулярно вносить изменения в настройки SAP HCM. В нашей компании все изменения реализуются в ежемесячных релизах. Стандартные обновления от SAP также выходят примерно раз в месяц и устанавливаются вместе с релизом.
Обновления от вендора представляют собой пакеты, содержащие ноты с изменениями программ и настроек. На рисунке представлен состав пакета обновления SAPK-60866INEAHRCRU, содержащий четыре ноты по зарплате для России.
Установка собственных релизных разработок\настроек и стандартных пакетов обновлений может изменить текущие настройки и привести к некорректной работе системы.
Как подтвердить, что существующая функциональность не была затронута стандартными обновлениями SAP и собственными новыми разработками\настройками?
Можно конечно проанализировать все изменения, все стандартные ноты. Создать под них примеры и провести функциональное тестирование.
Но тут нужно учитывать, что количество нот может исчисляться десятками и они могут затрагивать сопутствующий функционал. А если к этому добавить размер нашей компании (в SAP HR рассчитывается более 270 000 сотрудников), то количество возможных кейсов превысит разумные рамки.
Для решения этой проблемы сотрудниками нашего отдела «Бизнес-приложений САП Управление персоналом» был разработан механизм регрессионного тестирования заработной платы.
Суть этого механизма довольно проста. Сначала создается эталон – путем расчета заработной платы на первоначальной системе.
Затем на систему устанавливаются обновления и производится новый расчет заработной платы. Полученные результаты сохраняются как данные релиза.
И на последнем этапе производится сверка эталона с данными релиза.
Тестирование происходит на всем объеме табельных номеров.
Теперь поговорим об этом более подробно.
Наш SAP HCM имеет классический 3х-системный ландшафт. Система разработки (назовем ее HRD), система тестирования(HRT) и продуктивная система (HRP). Все доработки обязательно тестируются в HRT, при этом технические характеристики тестовой системы приближены к характеристикам продуктива.
Регрессионное тестирование делится на этапы:
На данном этапе специалисты базиса подготавливает систему HRT. HRT восстанавливают из бэкапа продуктивной системы на определенную дату. Т.е. данные в HRP и HRT становятся одинаковыми.
Несмотря на то что, данные между продуктивной и тестовой системой выровнены, тестирование расчета зарплаты необходимо проводить на еще не рассчитанном периоде. Для этого необходимо подготовить тестовые данные:
Поскольку мы хотим рассчитывать новый период, то нам необходимо сгенерировать временные отметки для сотрудников, находящихся на позитивном учете. Для этого, при помощи разработанной программы, из графика сотрудника в ИТ0007 генерируются временные отметки прихода\ухода в ИТ2011.
Для сотрудников, находящихся на позитивном учете, заполняется 0027ИТ Распределение затрат, путем копирования данных из ИТ1018 при помощи специально разработанной программы.
Тестовые данные подготавливаются на полном объеме табельных номеров, присвоенных каждой единице расчета. Для этого заполняется ИТ267 Внециклические выплаты при помощи транзакции HRUU0267.
Для расчета отпусков, премий, увольнений и различных видов больничных создаются тестовые данные для порядка 20 сотрудников.
После того как все тестовые данные заведены выполняется back-up системы HRT.
Этот этап включает в себя:
Для это в транзакции оценки времени pt60 создается вариант, который в дальнейшем используется в программе RPCS0000. Стандартная программа RPCS0000 служит для параллельного запуска оценки времени по группам табельных номеров. Использование RPCS0000 позволяет существенно сократить время оценки времени.
После завершения оценки времени необходимо сохранить полученный результат. Для этого создана специальная программа, сохраняющая результаты оценки (таблицы ZES и ZL) в текстовые файлы:
Фрагмент созданного файла эталона оценки времени:
Расчеты выполняются стандартными средствами (программа HRCUCLACM и транзакция PUST) на всем объеме табельных номеров.
Для этого в стандартном отчете по видам оплат PC00_M99_CWTR сохраняем вариант для просмотра необходимого расчета (регулярного или межрасчетного). Для сохранения данных расчета в системе разработки HRD была разработана пользовательская программа. Одним из входных параметров для этой программы является созданный вариант отчета PC00_M99_CWTR:
После отработки этой программы в системе разработки HRD будут сохранены эталонные результаты расчета зарплаты:
В тестовой системе HRT выполняется продуктивный прогон проводок в тестовую финансовую систему. После этого при помощи специально разработанной программы данные по проводкам загружаются в систему разработки HRD в качестве эталона для будущей сверки.
После выполнения этой программы в системе разработки HRD будут сохранены эталонные результаты проводок в финансовую систему:
После расчета зарплаты формируем реестр на перечисление. При помощи разработанной пользовательской программы эти реестры так же сохраняются в текстовых файлах в качестве эталона.
Фрагмент файла эталона реестра на перечисление зарплаты:
Налоговые отчеты 6-НДФЛ и 2-НДФЛ формируются при помощи стандартных отчетов RPCPAYRU_6NDFL и HRULNDFL соответственно. Для нужд тестирования они были расширены логикой по сохранению результатов в прозрачных таблицах. После формирования налоговой отчетности в тестовой среде, эти результаты передаются в систему разработки при помощи пользовательской программы.
Полученный эталон налоговых данных:
После того как эталон снят, необходимо восстановить систему тестирования из бэкапа, сделанного после этапа подготовки тестовых данных. Т.е. мы получаем систему с заведенными тестовыми данными, но без расчетов. На данную систему устанавливаются все обновления – собственные разработки и стандартные пакеты обновления от SAP. После чего производятся регулярные и межрасчетные расчеты заработной платы, формирования проводок и прочие действия аналогичные действиям на этапе снятия эталона.
После снятия эталона и релиза, наступает очередь этапа сверки. На этом этапе
мы сравниваем данные полученные до установки обновлений, с данными на обновленной системе. И на основании анализа расхождений делаем выводы о наличии ошибок в поставленных обновлениях.
Для этого запускаем программу автоматизации сверки результатов расчета в режиме «Сравнение эталона и релиза». В качестве одного из параметров указываем каталог, в котором был сохранен файл эталона оценки времени.
Если между данными эталона и релиза есть разница, то данный отчет ее отобразит.
Данные по проводкам из релиза и эталона уже находятся в системе разработки. Для сверки используется пользовательский отчет, в котором в качестве параметров указываем даты релиза и эталона:
Если между данными эталона и релиза есть разница, то данный отчет ее отобразит.
Данные с результатами формирования отчетов 2-НДФЛ и 6-НДФЛ на этапе снятия и эталона, и релиза были перенесены в систему разработки HRD. Для сверки данных используется пользовательский отчет. Где входными параметрами являются даты снятия эталона\релиза и пользователь, под которым эти снятия происходили:
Если в данных есть различия, то они отображаются.
Данные, полученные при регулярном расчете заработной платы, при различных межрасчетах в тестовой системе на этапе формирования эталона и релиза были перенесены в систему разработки. Теперь в системе разработки происходит сверка данных по эталону и релизу при помощи разработанной пользовательской программы:
Все полученные расхождения доступны в отчете.
На этапе снятия релиза были сформированы текстовые файлы с данными реестров на перечисление. Сравниваем эти эталонные данные с реестрами на перечисление, созданными после установки обновлений.
В случае наличия расхождений, они отображаются в отчете.
Все полученные расхождения анализируются специалистами отдела поддержки SAP HCM. Если причиной расхождения стали ошибки в настройках\ разработках они исправляются и тестируются в следующей итерации. Т.е. тестовую систему снова восстанавливают из бэкапа снятого после заведения тестовых данных, устанавливают обновления с исправлениями ошибок и заново проводят этапы снятия релиза и сверки.
Данный подход позволяет весьма качественно проводить тестирование такого критичного процесса как расчет заработной платы и используется не только при тестировании ежемесячных релизов\обновлений, но и в проектной деятельности. Так, только в этом году он был успешно применен на двух больших проектах – реорганизация юридических лиц и обновление системы SAP HCM до уровня enhancement 8.
Например, на рисунке выше представлен ракурс настройки вида оплаты. Один ошибочно установленный параметр или флажок приведет к неверному расчету.
При этом цена ошибки может быть очень велика как в денежном выражении, так и в репутационном плане.
Также стоит отметить, что ошибка может проявиться не сразу, а только через несколько месяцев после расчета. В этом случае может потребоваться перерасчет заработной платы за несколько месяцев, либо создание специальной корректирующей схемы расчета. Оба эти сценария крайне трудоемки и рискованны, поэтому могут рассматриваться только как крайнее средство.
Откуда же могут появиться такие ошибки? HR-функционал постоянно развивается, меняются требования законодательства и требования бизнеса. Для соответствия этим требованиям необходимо регулярно вносить изменения в настройки SAP HCM. В нашей компании все изменения реализуются в ежемесячных релизах. Стандартные обновления от SAP также выходят примерно раз в месяц и устанавливаются вместе с релизом.
Обновления от вендора представляют собой пакеты, содержащие ноты с изменениями программ и настроек. На рисунке представлен состав пакета обновления SAPK-60866INEAHRCRU, содержащий четыре ноты по зарплате для России.
Установка собственных релизных разработок\настроек и стандартных пакетов обновлений может изменить текущие настройки и привести к некорректной работе системы.
Регрессионное тестирование
Как подтвердить, что существующая функциональность не была затронута стандартными обновлениями SAP и собственными новыми разработками\настройками?
Можно конечно проанализировать все изменения, все стандартные ноты. Создать под них примеры и провести функциональное тестирование.
Но тут нужно учитывать, что количество нот может исчисляться десятками и они могут затрагивать сопутствующий функционал. А если к этому добавить размер нашей компании (в SAP HR рассчитывается более 270 000 сотрудников), то количество возможных кейсов превысит разумные рамки.
Для решения этой проблемы сотрудниками нашего отдела «Бизнес-приложений САП Управление персоналом» был разработан механизм регрессионного тестирования заработной платы.
Суть этого механизма довольно проста. Сначала создается эталон – путем расчета заработной платы на первоначальной системе.
Затем на систему устанавливаются обновления и производится новый расчет заработной платы. Полученные результаты сохраняются как данные релиза.
И на последнем этапе производится сверка эталона с данными релиза.
Тестирование происходит на всем объеме табельных номеров.
Теперь поговорим об этом более подробно.
Наш SAP HCM имеет классический 3х-системный ландшафт. Система разработки (назовем ее HRD), система тестирования(HRT) и продуктивная система (HRP). Все доработки обязательно тестируются в HRT, при этом технические характеристики тестовой системы приближены к характеристикам продуктива.
Регрессионное тестирование делится на этапы:
- Подготовка системы HRT
- Подготовка тестовых данных
- Снятие эталона
- Снятие релиза
- Сверка результатов
Этап подготовки тестовой системы HRT
На данном этапе специалисты базиса подготавливает систему HRT. HRT восстанавливают из бэкапа продуктивной системы на определенную дату. Т.е. данные в HRP и HRT становятся одинаковыми.
Этап подготовки тестовых данных
Несмотря на то что, данные между продуктивной и тестовой системой выровнены, тестирование расчета зарплаты необходимо проводить на еще не рассчитанном периоде. Для этого необходимо подготовить тестовые данные:
- Генерация временных меток
Поскольку мы хотим рассчитывать новый период, то нам необходимо сгенерировать временные отметки для сотрудников, находящихся на позитивном учете. Для этого, при помощи разработанной программы, из графика сотрудника в ИТ0007 генерируются временные отметки прихода\ухода в ИТ2011.
- Ведение данных ИТ0027 Распределение затрат
Для сотрудников, находящихся на позитивном учете, заполняется 0027ИТ Распределение затрат, путем копирования данных из ИТ1018 при помощи специально разработанной программы.
- Ведение данных для расчета аванса
Тестовые данные подготавливаются на полном объеме табельных номеров, присвоенных каждой единице расчета. Для этого заполняется ИТ267 Внециклические выплаты при помощи транзакции HRUU0267.
Для расчета отпусков, премий, увольнений и различных видов больничных создаются тестовые данные для порядка 20 сотрудников.
После того как все тестовые данные заведены выполняется back-up системы HRT.
Этап снятия эталона
Этот этап включает в себя:
- Выполнение оценки времени
Для это в транзакции оценки времени pt60 создается вариант, который в дальнейшем используется в программе RPCS0000. Стандартная программа RPCS0000 служит для параллельного запуска оценки времени по группам табельных номеров. Использование RPCS0000 позволяет существенно сократить время оценки времени.
- Сохранение эталона результатов оценки времени
После завершения оценки времени необходимо сохранить полученный результат. Для этого создана специальная программа, сохраняющая результаты оценки (таблицы ZES и ZL) в текстовые файлы:
Фрагмент созданного файла эталона оценки времени:
- Выполнение расчета заработной платы (регулярные и межрасчетные выплаты)
Расчеты выполняются стандартными средствами (программа HRCUCLACM и транзакция PUST) на всем объеме табельных номеров.
- Сохранение результатов расчета для последующей сверки
Для этого в стандартном отчете по видам оплат PC00_M99_CWTR сохраняем вариант для просмотра необходимого расчета (регулярного или межрасчетного). Для сохранения данных расчета в системе разработки HRD была разработана пользовательская программа. Одним из входных параметров для этой программы является созданный вариант отчета PC00_M99_CWTR:
После отработки этой программы в системе разработки HRD будут сохранены эталонные результаты расчета зарплаты:
- Формирование проводок
В тестовой системе HRT выполняется продуктивный прогон проводок в тестовую финансовую систему. После этого при помощи специально разработанной программы данные по проводкам загружаются в систему разработки HRD в качестве эталона для будущей сверки.
После выполнения этой программы в системе разработки HRD будут сохранены эталонные результаты проводок в финансовую систему:
- Формирование реестров на перечисление
После расчета зарплаты формируем реестр на перечисление. При помощи разработанной пользовательской программы эти реестры так же сохраняются в текстовых файлах в качестве эталона.
Фрагмент файла эталона реестра на перечисление зарплаты:
- Формирование налоговой отчетности
Налоговые отчеты 6-НДФЛ и 2-НДФЛ формируются при помощи стандартных отчетов RPCPAYRU_6NDFL и HRULNDFL соответственно. Для нужд тестирования они были расширены логикой по сохранению результатов в прозрачных таблицах. После формирования налоговой отчетности в тестовой среде, эти результаты передаются в систему разработки при помощи пользовательской программы.
Полученный эталон налоговых данных:
Этап снятия релиза
После того как эталон снят, необходимо восстановить систему тестирования из бэкапа, сделанного после этапа подготовки тестовых данных. Т.е. мы получаем систему с заведенными тестовыми данными, но без расчетов. На данную систему устанавливаются все обновления – собственные разработки и стандартные пакеты обновления от SAP. После чего производятся регулярные и межрасчетные расчеты заработной платы, формирования проводок и прочие действия аналогичные действиям на этапе снятия эталона.
Этап сверки
После снятия эталона и релиза, наступает очередь этапа сверки. На этом этапе
мы сравниваем данные полученные до установки обновлений, с данными на обновленной системе. И на основании анализа расхождений делаем выводы о наличии ошибок в поставленных обновлениях.
- Сверка результатов оценки времени
Для этого запускаем программу автоматизации сверки результатов расчета в режиме «Сравнение эталона и релиза». В качестве одного из параметров указываем каталог, в котором был сохранен файл эталона оценки времени.
Если между данными эталона и релиза есть разница, то данный отчет ее отобразит.
- Сверка данных проводок
Данные по проводкам из релиза и эталона уже находятся в системе разработки. Для сверки используется пользовательский отчет, в котором в качестве параметров указываем даты релиза и эталона:
Если между данными эталона и релиза есть разница, то данный отчет ее отобразит.
- Сверка налоговой отчетности
Данные с результатами формирования отчетов 2-НДФЛ и 6-НДФЛ на этапе снятия и эталона, и релиза были перенесены в систему разработки HRD. Для сверки данных используется пользовательский отчет. Где входными параметрами являются даты снятия эталона\релиза и пользователь, под которым эти снятия происходили:
Если в данных есть различия, то они отображаются.
- Сверка расчета заработной платы
Данные, полученные при регулярном расчете заработной платы, при различных межрасчетах в тестовой системе на этапе формирования эталона и релиза были перенесены в систему разработки. Теперь в системе разработки происходит сверка данных по эталону и релизу при помощи разработанной пользовательской программы:
Все полученные расхождения доступны в отчете.
- Сверка реестров на перечисление
На этапе снятия релиза были сформированы текстовые файлы с данными реестров на перечисление. Сравниваем эти эталонные данные с реестрами на перечисление, созданными после установки обновлений.
В случае наличия расхождений, они отображаются в отчете.
Все полученные расхождения анализируются специалистами отдела поддержки SAP HCM. Если причиной расхождения стали ошибки в настройках\ разработках они исправляются и тестируются в следующей итерации. Т.е. тестовую систему снова восстанавливают из бэкапа снятого после заведения тестовых данных, устанавливают обновления с исправлениями ошибок и заново проводят этапы снятия релиза и сверки.
Данный подход позволяет весьма качественно проводить тестирование такого критичного процесса как расчет заработной платы и используется не только при тестировании ежемесячных релизов\обновлений, но и в проектной деятельности. Так, только в этом году он был успешно применен на двух больших проектах – реорганизация юридических лиц и обновление системы SAP HCM до уровня enhancement 8.
