Le moteur de paie de SAP HCM est un outil fiable et en même temps flexible. Cet outil vous permet de prendre en compte les éventuelles exigences de la législation et des réglementations locales en matière de rémunération des salariés. Cependant, le revers de la médaille d'une telle polyvalence est la complexité et la forte sensibilité aux changements de paramètres.
Par exemple, la figure ci-dessus montre une vue de la définition d'une rubrique de salaire. Un paramètre ou une case à cocher mal réglé entraînera un calcul incorrect.
De plus, le prix d'une erreur peut être très élevé tant en termes monétaires qu'en termes de réputation.
Il convient également de noter que l'erreur peut ne pas se produire immédiatement, mais seulement quelques mois après le calcul. Dans ce cas, il peut être nécessaire de recalculer les salaires sur plusieurs mois ou de créer un schéma de calcul correctif spécial. Ces deux scénarios sont extrêmement chronophages et risqués, ils ne peuvent donc être considérés qu'en dernier recours.
D'où ces erreurs peuvent-elles provenir? La fonctionnalité RH évolue constamment, les exigences législatives et les exigences commerciales évoluent. Pour répondre à ces exigences, vous devez régulièrement apporter des modifications à vos paramètres SAP HCM. Dans notre entreprise, toutes les modifications sont mises en œuvre dans les versions mensuelles. Les mises à jour standard de SAP sortent également environ une fois par mois et sont installées avec la version.
Les mises à jour du fournisseur sont des packages contenant des notes avec des modifications de programmes et de paramètres. La figure montre la composition du Service Pack SAPK-60866INEAHRCRU, contenant quatre notes de paie pour la Russie.
L'installation de vos propres produits de développement \ paramètres et service packs standard peut modifier les paramètres actuels et entraîner un fonctionnement incorrect du système.
Test de régression
Comment puis-je confirmer que la fonctionnalité existante n'a pas été affectée par les mises à jour SAP standard et mes propres nouveaux développements / paramètres?
Vous pouvez bien sûr analyser tous les changements, toutes les notes standard. Créez des exemples pour eux et effectuez des tests fonctionnels.
Mais ici, il faut garder à l'esprit que le nombre de notes peut être des dizaines et qu'elles peuvent affecter la fonctionnalité qui l'accompagne. Et si nous ajoutons à cela la taille de notre entreprise (plus de 270 000 employés sont calculés dans SAP HR), le nombre de cas possibles dépassera un montant raisonnable.
Pour résoudre ce problème, les employés de notre département «Business Applications SAP HR Management» ont développé un mécanisme de test de régression des salaires.
L'essence de ce mécanisme est assez simple. Tout d'abord, une norme est créée - en calculant les salaires sur le système d'origine.
Ensuite, des mises à jour sont installées sur le système et un nouveau calcul de paie est effectué. Les résultats sont enregistrés en tant que données de version.
Et à la dernière étape, la norme est réconciliée avec les données de version.
Les tests ont lieu sur l'ensemble du volume des effectifs.
Parlons maintenant de cela plus en détail.
Notre SAP HCM a un paysage classique à 3 systèmes. Un système de développement (appelons-le HRD), un système de test (HRT) et un système productif (HRP). Toutes les améliorations sont nécessairement testées en HRT, tandis que les caractéristiques techniques du système de test sont proches des caractéristiques du productif.
Les tests de régression sont divisés en étapes:
- Préparation du système HRT
- Préparation des données de test
- Suppression de la norme
- Release release
- Rapprochement des résultats
Phase de préparation du système de test HRT
À ce stade, les spécialistes de la base préparent le système HRT. HRT est restauré à partir d'une sauvegarde d'un système productif à une date spécifique. C'est-à-dire les données dans HRP et HRT deviennent les mêmes.
Phase de préparation des données de test
Malgré le fait que les données entre les systèmes de production et de test sont alignées, les tests de paie doivent être effectués sur une période non encore calculée. Pour ce faire, préparez les données de test:
Puisque nous voulons calculer une nouvelle période, nous devons générer des horodatages pour les employés qui sont enregistrés positivement. Pour ce faire, à l'aide du programme développé, des horodatages d'arrivée / de départ dans IT2011 sont générés à partir de l'horaire de l'employé dans IT0007.
- Maintenance des données IT0027 Partage des coûts
Pour les employés qui sont enregistrés positivement, le partage des coûts 0027IT est rempli en copiant les données d'IT1018 à l'aide d'un programme spécialement conçu.
- Gestion des données pour le calcul de l'acompte
Les données de test sont entièrement préparées sur les effectifs affectés à chaque unité de calcul. Pour ce faire, remplissez IT267 Paiements hors cycle à l'aide de la transaction HRUU0267.
Pour calculer les vacances, les primes, les licenciements et divers types de congés de maladie, des données de test sont créées pour environ 20 employés.
Une fois toutes les données de test démarrées, la sauvegarde du système HRT est effectuée.
Étape de suppression de la norme
Cette phase comprend:
Pour cela, une variante est créée dans la transaction d'évaluation du temps pt60, qui est ensuite utilisée dans le programme RPCS0000. Le programme standard RPCS0000 est utilisé pour exécuter des évaluations de temps en parallèle par des groupes de groupes de personnel. L'utilisation de RPCS0000 peut réduire considérablement le temps d'évaluation du temps.
- Enregistrement de la référence pour les résultats de l'évaluation du temps
Après avoir terminé l'évaluation du temps, il est nécessaire de sauvegarder le résultat. Pour ce faire, un programme spécial a été créé qui stocke les résultats de l'évaluation (tableaux ZES et ZL) dans des fichiers texte:
Un fragment du fichier standard d'évaluation du temps créé:
- Effectuer la paie (paiements réguliers et inter-règlements)
Les calculs sont effectués par des moyens standard (programme HRCUCLACM et transaction PUST) sur l'ensemble du volume des effectifs.
- Enregistrement des résultats de calcul pour un rapprochement ultérieur
Pour ce faire, dans le rapport standard sur les rubriques PC00_M99_CWTR, nous sauvegardons l'option de visualisation du calcul nécessaire (régulier ou inter-règlements). Pour sauvegarder les données de calcul dans le système de développement HRD, un programme utilisateur a été développé. L'un des paramètres d'entrée de ce programme est la version générée du rapport PC00_M99_CWTR:
Après avoir élaboré ce programme dans le système de développement HRD, les résultats de référence du calcul de la paie seront enregistrés:
Dans le système de test HRT, une exécution productive des écritures vers le système financier de test est effectuée. Après cela, à l'aide d'un programme spécialement conçu, les données de publication sont téléchargées dans le système de développement de HRD comme référence pour une réconciliation future.
Une fois ce programme terminé, les résultats de référence des affectations au système financier seront sauvegardés dans le système de développement du DRH:
- Formation de registres de transfert
Après avoir calculé le salaire, nous formons un registre de transfert. En utilisant le programme utilisateur développé, ces registres sont également stockés dans des fichiers texte comme référence.
Un fragment du fichier standard du registre des transferts de salaires:
Les rapports fiscaux 6-NDFL et 2-NDFL sont générés à l'aide des rapports standard RPCPAYRU_6NDFL et HRULNDFL, respectivement. Pour les besoins de test, ils ont été étendus avec une logique pour stocker les résultats dans des tableaux transparents. Une fois la déclaration fiscale générée dans un environnement de test, ces résultats sont transférés au système de développement à l'aide d'un programme utilisateur.
Norme de données fiscales reçues:
Phase de publication
Une fois la norme supprimée, il est nécessaire de restaurer le système de test à partir de la sauvegarde effectuée après l'étape de préparation des données de test. C'est-à-dire nous obtenons un système avec des données de test finies, mais sans calculs. Toutes les mises à jour sont installées sur ce système - développements propriétaires et service packs standard de SAP. Après cela, les calculs de paie réguliers et inter-règlements, les écritures et autres actions sont effectués de manière similaire aux actions au stade de la suppression de la norme.
Étape de réconciliation
Après avoir supprimé la norme et publié, le tour de l'étape de réconciliation arrive. A ce stade
nous comparons les données reçues avant d'installer les mises à jour avec les données du système mis à jour. Et sur la base de l'analyse des écarts, nous tirons des conclusions sur la présence d'erreurs dans les mises à jour installées.
- Rapprochement des résultats de l'évaluation du temps
Pour ce faire, nous lançons le programme d'automatisation de la vérification des résultats de calcul en mode "Comparaison standard et release". En tant que paramètre, nous indiquons le répertoire dans lequel le fichier standard d'évaluation du temps a été enregistré.
S'il existe une différence entre les données standard et de version, ce rapport l'affichera.
- Affichage du rapprochement
La publication des données de la version et de la référence est déjà dans le système de développement. Pour la vérification, un rapport utilisateur est utilisé, dans lequel nous indiquons les dates de sortie et la norme en tant que paramètres:
S'il existe une différence entre les données standard et de version, ce rapport l'affichera.
- Rapprochement des déclarations fiscales
Les données avec les résultats de la génération de rapports de 2-NDFL et 6-NDFL au stade de la suppression de l'étalon et de la libération ont été transférées au système de développement HRD. Un rapport utilisateur est utilisé pour vérifier les données. Où les paramètres d'entrée sont les dates de suppression de la version standard \ et l'utilisateur sous lequel ces suppressions ont eu lieu:
S'il y a des différences dans les données, elles sont affichées.
Les données obtenues lors du calcul régulier des salaires, avec divers inter-règlements dans le système de test au stade de l'élaboration de la norme et de la version, ont été transférées au système de développement. Maintenant, dans le système de développement, il y a une vérification des données sur la norme et la version à l'aide du programme utilisateur développé:
Toutes les divergences reçues sont disponibles dans le rapport.
- Rapprochement des registres pour le transfert
Au stade de la publication de la version, des fichiers texte contenant des données de registre pour la liste ont été générés. Nous comparons ces données de référence avec les registres de listage créés après l'installation des mises à jour.
En cas de divergences, elles sont affichées dans le rapport.
Toutes les divergences obtenues sont analysées par des spécialistes du service d'assistance SAP HCM. Si la raison de la divergence est des erreurs dans les paramètres / conceptions, elles sont corrigées et testées lors de la prochaine itération. C'est-à-dire le système de test est à nouveau restauré à partir de la sauvegarde effectuée après l'établissement des données de test, installez les mises à jour avec des corrections de bogues et répétez les étapes de suppression de la version et de la réconciliation.
Cette approche permet de tester de très haute qualité un processus aussi critique que la paie et est utilisée non seulement lors du test des versions / mises à jour mensuelles, mais également dans les activités de projet. Ainsi, cette année seulement, il a été appliqué avec succès sur deux grands projets - la réorganisation des entités juridiques et la mise à jour du système SAP HCM au niveau d'amélioration 8.