O mecanismo da folha de pagamento no SAP HCM é uma ferramenta confiável e ao mesmo tempo flexível. Essa ferramenta permite que você leve em consideração todos os requisitos da legislação e regulamentos locais no campo da remuneração dos funcionários. No entanto, o outro lado da moeda dessa versatilidade é a complexidade e a forte sensibilidade às mudanças nas configurações.
Por exemplo, a figura acima mostra uma visão da definição de uma rubrica salarial. Um parâmetro ou caixa de seleção definido incorretamente levará a um cálculo incorreto.
Além disso, o preço de um erro pode ser muito alto, tanto em termos monetários quanto em termos de reputação.
Também é importante notar que o erro pode não ocorrer imediatamente, mas apenas alguns meses após o cálculo. Nesse caso, pode ser necessário recalcular os salários por vários meses ou criar um esquema especial de cálculo corretivo. Ambos os cenários são extremamente demorados e arriscados, portanto, eles só podem ser considerados como último recurso.
De onde vêm esses erros? A funcionalidade de RH está em constante evolução; os requisitos legislativos e de negócios estão mudando. Para atender a esses requisitos, é necessário fazer alterações regularmente nas configurações do SAP HCM. Em nossa empresa, todas as alterações são implementadas em lançamentos mensais. As atualizações padrão da SAP também saem uma vez por mês e são instaladas com o lançamento.
Atualizações do fornecedor são pacotes que contêm notas com alterações nos programas e configurações. A figura mostra a composição do service pack SAPK-60866INEAHRCRU, contendo quatro notas de folha de pagamento para a Rússia.
A instalação de seus próprios produtos de desenvolvimento \ configurações e service packs padrão pode alterar as configurações atuais e levar à operação incorreta do sistema.
Teste de regressão
Como posso confirmar que a funcionalidade existente não foi afetada pelas atualizações padrão do SAP e pelos meus próprios novos desenvolvimentos / configurações?
É claro que você pode analisar todas as alterações, todas as notas padrão. Crie exemplos para eles e realize testes funcionais.
Mas aqui deve-se ter em mente que o número de notas pode estar na casa das dezenas e elas podem afetar a funcionalidade que o acompanha. E se adicionarmos a isso o tamanho da nossa empresa (mais de 270.000 funcionários são calculados no SAP HR), o número de casos possíveis excederá uma quantidade razoável.
Para resolver esse problema, os funcionários do nosso departamento “Business Applications SAP HR Management” desenvolveram um mecanismo para testes de regressão de salários.
A essência desse mecanismo é bastante simples. Primeiro, um padrão é criado - calculando os salários no sistema original.
Em seguida, as atualizações são instaladas no sistema e um novo cálculo da folha de pagamento é feito. Os resultados são salvos como dados de liberação.
E, no último estágio, o padrão é reconciliado com os dados de liberação.
Os testes ocorrem em todo o volume de números de pessoal.
Agora vamos falar sobre isso com mais detalhes.
Nosso SAP HCM possui um cenário clássico de 3 sistemas. Um sistema de desenvolvimento (vamos chamá-lo de HRD), um sistema de teste (HRT) e um sistema produtivo (HRP). Todas as melhorias são necessariamente testadas na HRT, enquanto as características técnicas do sistema de teste estão próximas das características do produtivo.
O teste de regressão é dividido em etapas:
- Preparação do sistema HRT
- Preparação de dados de teste
- Remoção do padrão
- Release release
- Reconciliação de resultados
Fase de preparação do sistema de teste HRT
Nesta fase, os especialistas da base estão preparando o sistema HRT. A HRT é restaurada a partir de um backup de um sistema produtivo em uma data específica. I.e. os dados no HRP e HRT tornam-se os mesmos.
Fase de preparação dos dados de teste
Apesar de os dados entre os sistemas produtivo e de teste estarem alinhados, o teste da folha de pagamento deve ser realizado em um período ainda calculado. Para fazer isso, prepare os dados do teste:
Como queremos calcular um novo período, precisamos gerar registros de data e hora para funcionários com registro positivo. Para fazer isso, usando o programa desenvolvido, os carimbos de hora de chegada / partida no IT2011 são gerados a partir da programação do funcionário no IT0007.
- Manutenção de dados IT0027 Compartilhamento de custos
Para funcionários com registro positivo, o compartilhamento de custos 0027IT é preenchido através da cópia de dados do IT1018 usando um programa especialmente projetado.
- Atualização de dados para cálculo de adiantamento
Os dados do teste são preparados na íntegra nos números pessoais atribuídos a cada unidade de cálculo. Para fazer isso, preencha IT267 Off-Cycle Payment usando a transação HRUU0267.
Para calcular férias, bônus, demissões e vários tipos de licença médica, são criados dados de teste para cerca de 20 funcionários.
Depois que todos os dados de teste foram iniciados, o backup do sistema HRT é realizado.
Estágio de remoção do padrão
Esta fase inclui:
Para isso, uma variante é criada na transação de avaliação de tempos pt60, que é usada posteriormente no programa RPCS0000. O programa padrão RPCS0000 é usado para executar avaliações de tempos em paralelo por grupos de grupos de pessoas. O uso do RPCS0000 pode reduzir significativamente o tempo de avaliação do tempo.
- Salvando o benchmark para resultados de avaliação de tempos
Depois de concluir a avaliação do tempo, você deve salvar o resultado. Para isso, foi criado um programa especial que armazena os resultados da avaliação (tabelas ZES e ZL) em arquivos de texto:
Um fragmento do arquivo padrão de avaliação de tempos criado:
- Execução da folha de pagamento (pagamentos regulares e entre liquidações)
Os cálculos são realizados por meios padrão (programa HRCUCLACM e transação PUST) em todo o volume de números pessoais.
- Salvando resultados de cálculos para reconciliação subsequente
Para isso, no relatório standard sobre rubricas salariais PC00_M99_CWTR, salvamos a opção para visualizar o cálculo necessário (regular ou entre liquidação). Para salvar os dados de cálculo no sistema de desenvolvimento HRD, um programa do usuário foi desenvolvido. Um dos parâmetros de entrada para este programa é a versão gerada do relatório PC00_M99_CWTR:
Após elaborar este programa no sistema de desenvolvimento de RH, os resultados de referência do cálculo da folha de pagamento serão salvos:
No sistema de teste HRT, é executada uma execução produtiva de lançamentos no sistema financeiro de teste. Depois disso, usando um programa especialmente projetado, os dados de postagem são carregados no sistema de desenvolvimento HRD como referência para reconciliação futura.
Após a conclusão deste programa, os resultados de referência dos lançamentos no sistema financeiro serão salvos no sistema de desenvolvimento HRD:
- Formação de registros para transferência
Após o cálculo do salário, formamos um registro para transferência. Usando o programa do usuário desenvolvido, esses registros também são armazenados em arquivos de texto como referência.
Um fragmento do arquivo padrão do registro de transferência salarial:
Os relatórios fiscais 6-NDFL e 2-NDFL são gerados usando os relatórios padrão RPCPAYRU_6NDFL e HRULNDFL, respectivamente. Para necessidades de teste, eles foram estendidos com lógica para armazenar resultados em tabelas transparentes. Depois que o relatório de impostos é gerado em um ambiente de teste, esses resultados são transferidos para o sistema de desenvolvimento usando um programa do usuário.
Padrão de dados fiscais recebidos:
Release Release Release
Após a remoção do padrão, é necessário restaurar o sistema de teste a partir do backup feito após o estágio de preparação dos dados de teste. I.e. obtemos um sistema com dados de teste concluídos, mas sem cálculos. Todas as atualizações são instaladas neste sistema - desenvolvimentos proprietários e service packs padrão da SAP. Depois disso, cálculos regulares e entre folhas de pagamento, lançamentos e outras ações são executadas de maneira semelhante às ações no estágio de remoção da norma.
Estágio de reconciliação
Depois de remover o padrão e liberar, chega a vez do estágio de reconciliação. Nesta fase
comparamos os dados recebidos antes de instalar as atualizações com os dados no sistema atualizado. E com base na análise das discrepâncias, tiramos conclusões sobre a presença de erros nas atualizações instaladas.
- Conciliação dos resultados da avaliação de tempos
Para fazer isso, lançamos o programa para automatizar a verificação dos resultados do cálculo no modo "Comparação de padrão e liberação". Como um dos parâmetros, indicamos o diretório em que o arquivo padrão de avaliação de tempos foi salvo.
Se houver uma diferença entre os dados padrão e de liberação, este relatório os exibirá.
A publicação de dados do release e do benchmark já está no sistema de desenvolvimento. Para verificação, é utilizado um relatório do usuário, no qual indicamos as datas de lançamento e o padrão como parâmetros:
Se houver uma diferença entre os dados padrão e de liberação, este relatório os exibirá.
- Reconciliação de relatórios fiscais
Os dados com os resultados da geração de relatórios de 2-NDFL e 6-NDFL no estágio de remoção do padrão e da liberação foram transferidos para o sistema de desenvolvimento de HRD. Um relatório do usuário é usado para verificar os dados. Onde os parâmetros de entrada são as datas de remoção do padrão \ release e o usuário sob o qual essas remoções ocorreram:
Se houver diferenças nos dados, eles serão exibidos.
- Reconciliação da folha de pagamento
Os dados obtidos durante o cálculo regular dos salários, com várias inter-liquidações no sistema de teste na fase de formação do padrão e liberação, foram transferidos para o sistema de desenvolvimento. Agora, no sistema de desenvolvimento, há uma verificação dos dados no padrão e na liberação usando o programa do usuário desenvolvido:
Todas as discrepâncias recebidas estão disponíveis no relatório.
- Reconciliação de registros para transferência
No estágio do release, foram gerados arquivos de texto com dados do registro para listagem. Comparamos esses dados de referência com os registros de listagem criados após a instalação das atualizações.
No caso de discrepâncias, elas são exibidas no relatório.
Todas as discrepâncias obtidas são analisadas por especialistas do departamento de suporte do SAP HCM. Se o motivo da discrepância for erros nas configurações / designs, eles serão corrigidos e testados na próxima iteração. I.e. o sistema de teste é restaurado novamente a partir do backup realizado após o estabelecimento dos dados de teste, instala atualizações com correções de bugs e executa novamente as etapas de remoção da liberação e reconciliação.
Essa abordagem permite testes de alta qualidade de processos críticos como folha de pagamento e é usada não apenas no teste de lançamentos / atualizações mensais, mas também nas atividades do projeto. Portanto, apenas este ano foi aplicado com sucesso em dois grandes projetos - reorganização de pessoas jurídicas e atualização do sistema SAP HCM para o nível de aprimoramento 8.