Votre modèle de données pour le traitement de la paie
Votre modèle de données pour le traitement de la paie
- Champs de données optimisés pour l’analyse de la paie
- Suivi détaillé des activités pour cartographier le cycle de vie
- Instructions détaillées pour extraire les données de paie d’Oracle HCM Cloud
Attributs du traitement de la paie
| Nom | Description | ||
|---|---|---|---|
| Dernière mise à jour des données LastDataUpdate | Horodatage de la dernière modification de l’enregistrement dans la base de données source. | ||
| Description Indique si les données utilisées pour l’analyse sont à jour. À la différence de l’horodatage de l’événement, il correspond à la dernière modification de la ligne dans la base de données, effectuée par un processus ETL ou une mise à jour du système. Il permet de vérifier l’actualité des données et de diagnostiquer les retards d’extraction. Pourquoi est-ce important ? Permet aux analystes de savoir s’ils consultent des données en temps réel ou obsolètes. Où trouver ces données Colonne LAST_UPDATE_DATE, présente dans presque toutes les tables Oracle HCM. Exemples 2023-10-02T12:00:00Z2023-10-06T01:00:00Z | |||
| Dossier de paie PayrollRecord | Identifiant unique représentant un employé pour une période de paie donnée. | ||
| Description Le dossier de paie sert d’identifiant central du cas pour l’analyse Process Mining. Il s’agit d’une concaténation ou d’une clé unique qui associe l’identifiant de l’affectation de l’employé à celui de la période de paie. Cet attribut regroupe toutes les activités liées au paiement d’un employé pour un cycle donné, de la soumission initiale de la feuille de temps au virement bancaire final et à la déclaration fiscale. Il permet de distinguer les paiements d’un même employé en janvier et en février. Pourquoi est-ce important ? Il sert d’ID de cas et regroupe tous les événements distincts dans une seule instance de processus à des fins d’analyse. Où trouver ces données Construit à partir de PAY_ASSIGNMENT_ACTIONS ou d’une combinaison du numéro de personne et du nom de la période de paie dans Oracle HCM. Exemples EMP1001-2023-M01EMP5992-2023-W42300000018273645US-NY-A123-JAN23 | |||
| Horodatage de l’événement EventTimestamp | Date et heure exactes auxquelles l’activité a eu lieu. | ||
| Description Indique le moment précis où une activité s’est déroulée. Cet horodatage est essentiel pour calculer les durées et les délais, ainsi que pour repérer les goulots d’étranglement. Pour les étapes automatisées, il correspond à l’heure d’exécution du système. Pour les étapes manuelles, comme les approbations, il s’agit de l’horodatage de l’action de l’utilisateur consignée dans le journal des transactions. Pourquoi est-ce important ? Cet horodatage est essentiel pour ordonner les événements chronologiquement et calculer tous les KPI liés au temps. Où trouver ces données Colonnes CREATION_DATE ou ACTION_DATE des tables de transactions concernées, comme PAY_ACTION_INFORMATION. Exemples 2023-10-01T08:30:00Z2023-10-01T14:15:22Z2023-10-05T09:00:00Z | |||
| Nom de l’activité ActivityName | Étape ou événement précis du cycle de paie. | ||
| Description Cet attribut indique le nom de l’événement qui se produit dans le processus de paie. Exemples : « Feuille de temps soumise », « Calcul de la paie lancé » et « Paiement effectué ». Il constitue la dimension principale pour découvrir le processus et analyser ses variantes. Dans Oracle HCM Cloud, il est souvent déduit du type ou du statut de l’action dans les tables des actions de paie. Pourquoi est-ce important ? Il définit le « quoi » du processus et permet de reconstituer la cartographie du processus. Où trouver ces données Déduit du code ACTION_TYPE dans PAY_PAYROLL_ACTIONS ou des changements de statut consignés dans les journaux d’audit. Exemples Calcul de la paie lancéFeuille de temps approuvéeVirement bancaire généréException d’audit signalée | |||
| Système source SourceSystem | Nom du système à l’origine de l’événement. | ||
| Description Indique le logiciel ou le module qui a généré le point de données. Pour ce processus, la valeur principale est « Oracle HCM Cloud Payroll ». Dans un environnement complexe, cet attribut peut toutefois distinguer le moteur de paie principal, le module de gestion du temps et des activités ou une interface bancaire externe. Pourquoi est-ce important ? Fournit des informations sur la provenance des données, notamment lors de l’intégration de données issues de systèmes de gestion du temps ou de sous-systèmes bancaires. Où trouver ces données Renseigné en dur lors de l’extraction ou dérivé des identifiants d’interface. Exemples Oracle HCM Cloud PayrollOracle Time and LaborInterface bancaire externe | |||
| Correction manuelle IsManualCorrection | Indique si l’activité a nécessité une intervention manuelle. | ||
| Description Indicateur booléen défini sur vrai pour des activités telles que « Correction des données effectuée » ou « Enregistrement de paie corrigé ». Il sert à calculer les indicateurs clés de performance « Taux de correction manuelle des données » et « Taux d’exactitude de la paie dès le premier traitement ». Pourquoi est-ce important ? Distingue le traitement entièrement automatisé des reprises manuelles. Où trouver ces données Dérivé du nom de l’activité ou de types d’action spécifiques indiquant des ajustements (par exemple, QuickPay ou Balance Adjustment). Exemples truefalse | |||
| Échéance de traitement du SLA SlaProcessingDeadline | Date et heure limites auxquelles le paiement doit être effectué. | ||
| Description Enregistre l’échéance contractuelle ou légale du versement de la paie. Cet attribut est comparé à l’horodatage « Paiement effectué ». Il sert à calculer l’indicateur clé de performance « Respect de l’échéance de traitement du SLA » et à repérer les groupes de paie à risque. Pourquoi est-ce important ? Principal critère pour déterminer si le processus respecte les délais. Où trouver ces données Généralement un champ configuré (DFF) dans la définition de paie, ou une valeur calculée à partir de la date du chèque moins X jours. Exemples 2023-10-28T17:00:00Z2023-11-30T17:00:00Z | |||
| Groupe de données législatives LegislativeDataGroup | Répartit les données de paie par pays ou environnement réglementaire. | ||
| Description Dans Oracle HCM Cloud, le groupe de données législatives (LDG) répartit les données de paie et les données associées. Il correspond généralement à un pays ou à la législation d’un territoire donné. Cet attribut est essentiel pour filtrer l’analyse du processus par pays (par exemple, paie aux États-Unis ou au Royaume-Uni). Il est souvent associé à l’attribut générique Pays. Pourquoi est-ce important ? Les règles de conformité et les flux de processus varient souvent considérablement d’une juridiction à l’autre. Où trouver ces données Table PAY_ALL_PAYROLLS_F associée aux définitions des groupes de données législatives. Exemples Groupe de données législatives des États-UnisLDG du Royaume-UniPaie en France | |||
| Groupe de paie PayGroup | Regroupement logique des employés pour le traitement de la paie. | ||
| Description Correspond à la définition de paie à laquelle appartient l’employé (par exemple, « Production, paie hebdomadaire » ou « Siège, paie mensuelle »). Cet attribut est utilisé dans presque tous les Dashboards pour comparer les performances entre les cycles et les fréquences de paie. Pourquoi est-ce important ? Principal objet de configuration qui détermine la planification de la paie. Où trouver ces données Table PAY_ALL_PAYROLLS_F (Payroll Name). Exemples États-Unis, deux fois par moisRoyaume-Uni, mensuelSyndicat, hebdomadaire | |||
| Montant brut de la rémunération GrossPayAmount | Montant brut total calculé pour la période. | ||
| Description Correspond au montant brut calculé au cours du cycle. Il est utilisé dans les analyses « Exactitude du calcul des impôts et des avantages sociaux » et « Intégration des primes ». Les analystes peuvent ainsi mettre en relation les paiements élevés avec les délais de traitement ou les taux d’erreur. Pourquoi est-ce important ? Apporte un éclairage financier à l’analyse Process Mining. Où trouver ces données Table PAY_RUN_RESULT_VALUES, agrégée pour le solde Gross Pay. Exemples 5000.002350.5010000.00 | |||
| Nom de la période de paie PayrollPeriodName | Nom précis de la période couverte par le traitement de la paie. | ||
| Description Indique le cycle concerné, par exemple « Mensuel, janvier 2024 » ou « Période hebdomadaire 42 ». Cet attribut est essentiel au « Suivi du respect des échéances de SLA ». Il permet de regrouper les cas individuels des employés par lot de traitement pour produire des rapports agrégés. Pourquoi est-ce important ? Indispensable à l’analyse par lot et au suivi des SLA. Où trouver ces données Table PAY_TIME_PERIODS ou champ Time Period Name de la définition de paie. Exemples Mensuel 2023, période 10Hebdomadaire 2023, période 42Traitement des primes de décembre 2023 | |||
| Nom du département DepartmentName | Unité organisationnelle dans laquelle travaille l’employé. | ||
| Description Indique le département responsable de l’employé associé à l’enregistrement de paie. Cet attribut est essentiel au Dashboard « Efficacité de l’approbation des feuilles de temps ». En ventilant les données par département, les analystes peuvent repérer les unités opérationnelles qui approuvent régulièrement les feuilles de temps en retard, ce qui retarde le traitement global de la paie. Pourquoi est-ce important ? Permet d’analyser les causes profondes des retards liés aux approbations des responsables. Où trouver ces données Dérivé de l’affectation de l’employé en vigueur au moment du traitement de la paie. Exemples Ventes, Amérique du NordIngénierieRessources humainesLogistique | |||
| Utilisateur ayant effectué le traitement ProcessingUser | Identifiant ou nom de la personne qui réalise l’activité. | ||
| Description Indique l’identité du spécialiste de la paie, du responsable ou du compte système à l’origine de l’activité. Ces informations alimentent le Dashboard « Répartition de la charge de travail des spécialistes de la paie ». Elles aident à repérer les goulots d’étranglement liés aux ressources et les besoins de formation au sein de l’équipe paie. Pourquoi est-ce important ? Permet d’analyser la productivité des ressources et d’équilibrer la charge de travail. Où trouver ces données Colonnes CREATED_BY ou LAST_UPDATED_BY dans les tables de transactions. Exemples sysadminj.smithpayroll_batch_userm.doe | |||
| Indicateur de modification rétroactive RetroactiveChangeFlag | Indique si le traitement de la paie comprend des paiements rétroactifs. | ||
| Description Indicateur booléen défini sur vrai lorsque des éléments « Retropay » sont traités dans cet enregistrement. Il permet d’expliquer les délais de traitement plus longs ou les exceptions d’audit dans la « Comparaison des variantes du parcours de processus ». Les modifications rétroactives entraînent souvent des recalculs complexes portant sur des périodes antérieures. Pourquoi est-ce important ? Repère les cas complexes qui nécessitent naturellement un temps de traitement plus long. Où trouver ces données Présence d’entrées d’éléments « Retropay » dans PAY_ELEMENT_ENTRIES. Exemples truefalse | |||
| Juridiction fiscale TaxJurisdiction | État, province ou localité concerné par la déclaration fiscale. | ||
| Description Indique l’autorité fiscale principale associée à l’enregistrement de paie (par exemple, « CA » pour la Californie ou « NY » pour New York). Cet attribut alimente le Dashboard « Durée de traitement de la conformité fiscale ». Il permet de repérer les régions où le calcul et la déclaration des impôts sont plus complexes ou plus lents. Pourquoi est-ce important ? Ventile les performances selon la complexité réglementaire. Où trouver ces données Dérivé de la fiche fiscale de l’employé ou de l’adresse de son lieu de travail. Exemples CA-CalifornieNY-New YorkTX-TexasFédéral-États-Unis | |||
| Nombre d’itérations de prévisualisation PreviewIterationCount | Nombre de prévisualisations des résultats avant leur validation définitive. | ||
| Description Compteur incrémenté chaque fois que l’activité « Résultat de paie prévisualisé » se produit pour un même cas. Il mesure directement les données du Dashboard « Suivi des itérations de prévisualisation de la paie » et indique le volume de reprises ou le degré d’hésitation avant approbation. Pourquoi est-ce important ? Mesure l’efficacité de la phase de validation. Où trouver ces données Calculé lors de la transformation des données en comptant les occurrences d’activités spécifiques pour chaque ID de cas. Exemples 1350 | |||
| Statut du SLA SlaStatus | Statut catégoriel du respect du SLA (respecté ou non respecté). | ||
| Description Déduit de la comparaison entre l’horodatage « Paiement effectué » et l’« Échéance de traitement du SLA ». Les valeurs possibles comprennent « Dans les délais », « À risque » ou « En dépassement ». Il simplifie les rapports du « Suivi du respect des échéances de SLA » en regroupant les cas selon leur niveau de performance. Pourquoi est-ce important ? Transforme des comparaisons de délais complexes en catégories faciles à interpréter. Où trouver ces données Calculé en comparant l’horodatage de l’événement à l’échéance du SLA. Exemples RespectéEn dépassementRisque de dépassement | |||
| Type d’employé EmployeeType | Catégorie de l’employé (par exemple, salarié, rémunéré à l’heure ou prestataire). | ||
| Description Classe l’enregistrement de l’employé. Cet attribut est essentiel au Dashboard « Délai de publication des bulletins de paie numériques », car les règles ou les délais de traitement peuvent varier selon le type d’employé. Il permet de filtrer l’analyse et de comparer les performances du processus entre différents segments de la population active. Pourquoi est-ce important ? Les différents types d’employés suivent souvent des variantes de processus distinctes. Où trouver ces données Catégorie d’affectation ou conditions d’emploi dans PER_ALL_ASSIGNMENTS_M. Exemples Salarié à temps pleinEmployé à temps partiel rémunéré à l’heurePrestataireCadre dirigeant | |||
| Type d’exception d’audit AuditExceptionType | Catégorie de l’erreur ou de l’avertissement signalé lors de l’audit. | ||
| Description Classe le problème détecté lors de l’activité « Exception d’audit signalée » (par exemple, « Salaire net négatif » ou « Identifiant fiscal manquant »). Cet attribut alimente le Dashboard « Analyse des exceptions d’audit et des corrections » en mettant en évidence les problèmes récurrents de qualité des données. Pourquoi est-ce important ? Essentiel à l’analyse des causes profondes des boucles de reprise. Où trouver ces données Colonnes Message ou Error Code dans les journaux du processus de paie ou les rapports d’exception. Exemples Salaire net négatifNuméro de sécurité sociale manquantCoordonnées bancaires non validesLimite d’heures supplémentaires dépassée | |||
Activités de traitement de la paie
| Activité | Description | ||
|---|---|---|---|
| Calcul de la paie effectué | Fin réussie du processus Calculate Payroll, y compris les calculs du brut au net. Cet événement indique que les rémunérations, les retenues et les impôts ont été calculés pour l’affectation. | ||
| Pourquoi est-ce important ? Cette étape importante indique que les données sont prêtes à être validées. Une durée élevée peut signaler des problèmes de performance du système ou des formules rapides complexes. Où trouver ces données Interrogez PAY_PAYROLL_REL_ACTIONS en la reliant à PAY_PAYROLL_ACTIONS, lorsque ACTION_TYPE est R ou Q et que ACTION_STATUS passe à C (Complete). Données à recueillir Enregistré lorsque le statut de l’action Payroll Run passe à Complete Type d’événement explicit | |||
| Calcul de la paie lancé | Lancement du calcul principal de la paie pour une définition et une période de paie données. Cette étape marque le passage de la collecte des données à leur traitement. | ||
| Pourquoi est-ce important ? Cet événement marque le début de la période de traitement intensif. Il sert à calculer le temps de cycle total de l’exécution technique de la paie. Où trouver ces données Interrogez la table PAY_PAYROLL_ACTIONS avec ACTION_TYPE égal à R (Run) ou Q (QuickPay) et ACTION_STATUS indiqué comme démarré, ou déduit de la date de création. Données à recueillir Enregistré lors de l’insertion d’un enregistrement dans PAY_PAYROLL_ACTIONS Type d’événement explicit | |||
| Paiement effectué | Confirmation finale du traitement du paiement. Dans Oracle, cet événement correspond à la fin du flux de paiement ou au rapprochement dans Cash Management. | ||
| Pourquoi est-ce important ? Cet horodatage sert principalement à vérifier le respect des SLA et à déterminer si les employés ont été payés à temps. Où trouver ces données Peut être déduit de la date d’effet de l’action de virement bancaire ou obtenu explicitement dans les journaux de rapprochement de Cash Management (CE_STATEMENT_LINES). Données à recueillir Enregistré à partir de la date d’effet de l’action de paiement ou de l’événement de rapprochement Type d’événement explicit | |||
| Prépaiements calculés | Exécution du processus Prepayments, qui répartit le salaire net entre les modes de paiement choisis par l’employé (chèque, EFT, etc.). Cette étape vérifie que les montants calculés peuvent effectivement être versés. | ||
| Pourquoi est-ce important ? Cette étape fait le lien entre le calcul et le versement. Les échecs signalent généralement des coordonnées bancaires manquantes ou des modes de paiement non valides. Où trouver ces données Interrogez PAY_PAYROLL_ACTIONS avec ACTION_TYPE égal à P (Prepayments) et le statut Complete. Données à recueillir Enregistré lorsque l’action Prepayments se termine Type d’événement explicit | |||
| Virement bancaire généré | Génération du fichier EFT (Electronic Funds Transfer) ou d’un autre fichier de paiement. Cette étape technique crée le fichier d’instructions destiné à la banque. | ||
| Pourquoi est-ce important ? Mesure le temps de cycle de génération du fichier de paiement. Un retard à cette étape peut entraîner le dépassement de l’heure limite de traitement bancaire. Où trouver ces données Interrogez PAY_PAYROLL_ACTIONS avec ACTION_TYPE égal à M (Magnetic Tape), E (EFT) ou C (Check Writer). Données à recueillir Enregistré lorsque l’action EFT/Check se termine Type d’événement explicit | |||
| Bulletin de paie publié | Moment où le bulletin de paie devient accessible à l’employé dans Self Service. Cette étape suit l’archivage et peut être précédée d’un processus spécifique « Generate Payslip ». | ||
| Pourquoi est-ce important ? La disponibilité du bulletin influe sur la satisfaction des employés. Un délai important entre le paiement et la mise à disposition du bulletin génère des demandes d’assistance. Où trouver ces données Interrogez la table Documents of Record (HR_DOCUMENTS_OF_RECORD) ou vérifiez la fin du processus Generate Payslip dans PAY_PAYROLL_ACTIONS. Données à recueillir Enregistré lorsque le processus de génération du PDF du bulletin de paie se termine Type d’événement explicit | |||
| Calcul de la paie approuvé | Approbation officielle du registre ou du flux de paie dans le Dashboard Payroll. Elle intervient généralement après l’examen des rapports de validation et avant la génération des fichiers bancaires. | ||
| Pourquoi est-ce important ? Cette étape correspond à la validation par la direction. Le temps écoulé entre le calcul et l’approbation constitue la période de vérification. Où trouver ces données Interrogez PAY_REQ_FLOW_INSTANCES pour repérer les changements de statut ou la fin d’une tâche précise dans un modèle de flux de paie défini. Données à recueillir Enregistré lorsque le statut de l’instance de flux passe à Completed/Approved Type d’événement explicit | |||
| Coûts transférés | Transfert des résultats de comptabilisation des coûts de paie vers le grand livre. Cette étape clôt le cycle de paie sur le plan comptable. | ||
| Pourquoi est-ce important ? Cette étape garantit la conformité financière et l’enregistrement exact des coûts de main-d’œuvre. Tout retard empêche les équipes financières de clôturer les comptes. Où trouver ces données Interrogez PAY_PAYROLL_ACTIONS avec ACTION_TYPE égal à T (Transfer to GL) et le statut Complete. Données à recueillir Enregistré lorsque le processus Transfer to GL se termine Type d’événement explicit | |||
| Déclaration fiscale terminée | Génération des fichiers fiscaux réglementaires, par exemple le fichier fiscal trimestriel destiné aux tiers. Cette étape garantit le respect des obligations réglementaires pour la période de paie. | ||
| Pourquoi est-ce important ? Cet événement est essentiel pour le KPI de durée de traitement de la conformité fiscale. Un échec peut entraîner des pénalités. Où trouver ces données Interrogez PAY_PAYROLL_ACTIONS pour repérer les actions des groupes de données législatives liées aux déclarations fiscales, par exemple US Third Party Tax Filing. Données à recueillir Enregistré lorsque le flux de déclaration fiscale concerné se termine Type d’événement explicit | |||
| Données de primes importées | Création d’entrées d’éléments de paie pour les rémunérations variables, comme les primes ou les commissions, au moyen d’un chargeur par lots ou d’une importation HDL. Cette étape intègre les données de rémunération externes au calcul de la paie. | ||
| Pourquoi est-ce important ? Cet événement permet de suivre la rapidité d’intégration des rémunérations variables. Les importations tardives entraînent souvent des calculs de paie supplémentaires ou des corrections manuelles. Où trouver ces données Interrogez PAY_BATCH_HEADERS pour vérifier la fin de l’importation, ou suivez la création de PAY_ELEMENT_ENTRIES_F à l’aide d’une référence spécifique au système source. Données à recueillir Enregistré lorsque le traitement par lots des entrées d’éléments se termine correctement Type d’événement explicit | |||
| Dossier de paie corrigé | Mises à jour manuelles des entrées d’éléments ou des données d’affectation après un premier calcul de la paie, mais avant sa finalisation. Cette activité correspond aux reprises nécessaires pour corriger les erreurs ou traiter les exceptions. | ||
| Pourquoi est-ce important ? Cet événement révèle des inefficacités dans le processus et des problèmes de qualité des données. Réduire cette activité est essentiel pour améliorer le taux de précision de la paie dès le premier calcul. Où trouver ces données Déduit en repérant les mises à jour de PAY_ELEMENT_ENTRIES_F dont la date de dernière mise à jour se situe entre la date du premier calcul de la paie et celle des prépaiements. Données à recueillir Comparez les horodatages de mise à jour des entrées d’éléments à ceux des calculs de la paie Type d’événement inferred | |||
| Exception d’audit signalée | Enregistrement d’un message d’erreur ou d’avertissement pendant le calcul ou la validation de la paie. Cet événement signale les échecs de validation qui nécessitent une intervention humaine. | ||
| Pourquoi est-ce important ? Cet événement est essentiel pour repérer les problèmes de qualité des données. Un grand nombre d’exceptions augmente le travail manuel et le risque de non-respect des SLA. Où trouver ces données Interrogez la table PAY_MESSAGE_LINES liée à l’identifiant PAY_PAYROLL_REL_ACTION_ID concerné. Cette table contient les erreurs et les avertissements générés pendant les calculs. Données à recueillir Enregistré lors de l’insertion d’un enregistrement dans PAY_MESSAGE_LINES Type d’événement explicit | |||
| Feuille de temps approuvée | Confirmation que les données de temps soumises ont été vérifiées et approuvées par un responsable. Ce changement de statut déclenche le transfert des données vers les entrées d’éléments de paie. | ||
| Pourquoi est-ce important ? Cet événement est essentiel pour mesurer le délai d’approbation par le responsable. Les retards à cette étape sont une cause fréquente de régularisations rétroactives lors des périodes suivantes. Où trouver ces données Interrogez la table HWM_TM_REC_GRP_DTLS ou la vue HXT_TIMECARDS lorsque le statut passe à APPROVED. Comparez l’horodatage d’approbation à celui de la soumission. Données à recueillir Enregistré lorsque le statut passe à APPROVED dans Time and Labor Type d’événement explicit | |||
| Feuille de temps soumise | Événement initial : un employé ou un responsable soumet les données de temps et d’activité pour traitement. Dans Oracle HCM, cet événement est enregistré lorsque le statut de la feuille de temps passe à Submitted dans le module Time and Labor. | ||
| Pourquoi est-ce important ? Cet événement marque l’entrée des données brutes dans le processus de paie. Tout retard à cette étape se répercute sur les suivantes et réduit le temps dont disposent les spécialistes de la paie pour valider les calculs. Où trouver ces données Interrogez la table HWM_TM_REC_GRP_DTLS ou la vue HXT_TIMECARDS lorsque le statut passe à SUBMITTED. Utilisez l’horodatage de soumission. Données à recueillir Enregistré lorsque le statut passe à SUBMITTED dans Time and Labor Type d’événement explicit | |||
| QuickPay exécuté | Exécution d’un calcul de paie pour une seule personne (QuickPay), généralement utilisé pour vérifier des corrections. Cet événement sert d’indicateur indirect de l’activité de prévisualisation des résultats de paie. | ||
| Pourquoi est-ce important ? Des QuickPay fréquents pour une même personne indiquent une approche par essais et erreurs du traitement de la paie, plutôt qu’une Où trouver ces données Interrogez PAY_PAYROLL_ACTIONS avec ACTION_TYPE égal à Q (QuickPay). Comptez les occurrences par employé et par période de paie. Données à recueillir Enregistré lorsqu’une action QuickPay est consignée dans PAY_PAYROLL_ACTIONS Type d’événement explicit | |||
| Résultats d’archivage générés | Fin du processus Archive Periodic Payroll Results. Cet instantané fige les données pour la création des rapports et des bulletins de paie. | ||
| Pourquoi est-ce important ? Cette étape technique est nécessaire pour générer les bulletins de paie et les rapports réglementaires. Elle confirme que les données sont finalisées. Où trouver ces données Interrogez PAY_PAYROLL_ACTIONS avec ACTION_TYPE égal à X (Archive) et le statut Complete. Données à recueillir Enregistré lorsque l’action Archive se termine Type d’événement explicit | |||
Guides d’extraction
Étapes
Accéder à Data Exchange : Connectez-vous à Oracle HCM Cloud avec un utilisateur disposant du rôle « Human Capital Management Integration Specialist ». Accédez à My Client Groups > Data Exchange > Extract Definitions.
Créer une extraction : Cliquez sur l’icône « + » pour créer une extraction. Nommez-la « ProcessMind_Payroll_Extract ». Choisissez « Payroll » comme consommateur et « HR Archive » comme catégorie afin d’accéder aux données historiques des actions de paie.
Définir les groupes de données : Créez un groupe de données racine basé sur l’entité utilisateur
PAY_PAYROLL_REL_UE(Payroll Relationship). Il servira de point d’ancrage pour extraire les données liées à la relation de paie du salarié. Créez des groupes de données enfants pourPAY_ACTION_INFORMATION_UE,PAY_ELEMENT_ENTRY_UEetHWM_MEASURE_DAY_V_UE(pour les données de temps et d’activité).Configurer les enregistrements d’extraction : Dans les groupes de données, définissez des enregistrements qui aplatissent les données hiérarchiques. Créez des enregistrements spécifiques pour chaque type d’activité, par exemple un enregistrement filtrant les événements « Time Card » et un autre les événements « Run Results ».
Mettre en œuvre la logique SQL avec FastFormula ou BIP : Pour transformer des données de paie hiérarchiques en un journal d’événements linéaire, la méthode recommandée consiste à utiliser l’option « Extract Delivery Option » pour appeler un rapport BI Publisher. Vous pourrez ainsi utiliser comme modèle de données le SQL indiqué dans la section « Query » ci-dessous. Cette méthode est préférable au filtrage dans l’interface native pour créer un journal d’événements unifié.
Créer un modèle de données BI Publisher : Accédez à Tools > Reports and Analytics > Browse Catalog. Créez un modèle de données. Collez la requête SQL ci-dessous. Définissez les paramètres
bind_start_dateetbind_end_date.Associer l’extraction à BIP : Dans l’onglet « Delivery » de la définition d’extraction, créez une option de livraison. Sélectionnez « PDF » ou « XML » comme format de sortie. ProcessMind privilégie le CSV, mais vous convertirez la sortie BIP. Sélectionnez le rapport BI Publisher créé à l’étape précédente.
Définir les paramètres : Dans l’arborescence d’exécution de l’extraction, ajoutez les paramètres de date de début et de date de fin à transmettre dynamiquement à la requête BI Publisher.
Valider et soumettre : Validez la définition d’extraction pour détecter les erreurs. Cliquez sur « Submit Extract », puis saisissez les paramètres, par exemple les 90 derniers jours.
Suivre le processus : Accédez à « View Extract Results ». Attendez que le statut passe à « Succeeded ».
Télécharger le fichier de sortie : Téléchargez le fichier XML/CSV généré. Ouvrez-le pour vérifier que sa structure comprend les colonnes requises : PayrollRecord, ActivityName, EventTimestamp, etc.
Préparer les données pour ProcessMind : Si le fichier de sortie est au format XML, convertissez-le en fichier CSV plat et vérifiez que les en-têtes correspondent aux exigences des « Attributes to include ». Importez le fichier obtenu dans ProcessMind.
Configuration
- Mode d’extraction : « Changes Only » ou extraction complète. Pour le chargement initial, choisissez l’extraction complète. Pour les mises à jour quotidiennes, configurez « Changes Only » en fonction de la date de dernière mise à jour.
- Groupe de données législatives (LDG) : Si votre instance couvre plusieurs pays, il est fortement recommandé d’appliquer un filtre LDG, car les définitions de paie varient selon la législation.
- Plage de dates : Définissez
bind_start_dateetbind_end_datepour couvrir au moins 3 à 6 mois. Le Process Mining pourra ainsi prendre en compte des temps de cycle complets. - Taille des lots : Pour les volumes de paie importants (plus de 10 000 salariés), définissez la taille des lots à 2 000 dans la définition d’extraction afin d’éviter les délais d’expiration.
- Dates d’effet : Les tables de paie sont datées selon leur période de validité. La logique de la requête traite explicitement
effective_start_dateeteffective_end_datepour récupérer la version historique correcte de chaque enregistrement. - Sécurité : L’utilisateur qui exécute l’extraction doit disposer de profils de sécurité des données lui permettant de consulter toutes les paies et tous les services visés par l’analyse.
a Exemple de requête sql
/* Oracle HCM Cloud Payroll Extraction for ProcessMind */
/* Aggregating 16 specific activities into a unified Event Log */
SELECT
/* Attributes */
rel.person_number || '-' || ppa.payroll_action_id AS PayrollRecord,
'Time Card Submitted' AS ActivityName,
TO_CHAR(htr.creation_date, 'YYYY-MM-DD HH24:MI:SS') AS EventTimestamp,
'Oracle HCM Time and Labor' AS SourceSystem,
TO_CHAR(htr.last_update_date, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
pap.name AS PayrollPeriodName,
org.name AS DepartmentName,
NULL AS GrossPayAmount
FROM hwm_tm_rec htr
JOIN hwm_tm_rec_grp htrg ON htr.tm_rec_grp_id = htrg.tm_rec_grp_id
JOIN per_all_people_f rel ON htrg.person_id = rel.person_id
LEFT JOIN pay_all_payrolls_f pap ON htrg.payroll_id = pap.payroll_id
LEFT JOIN per_departments org ON rel.attribute1 = org.organization_id /* Adjust mapping */
WHERE htr.latest_version_flag = 'Y'
AND htr.tm_rec_status = 'SUBMITTED'
AND htr.creation_date BETWEEN :bind_start_date AND :bind_end_date
UNION ALL
SELECT
rel.person_number || '-' || ppa.payroll_action_id,
'Time Card Approved',
TO_CHAR(htr.last_update_date, 'YYYY-MM-DD HH24:MI:SS'),
'Oracle HCM Time and Labor',
TO_CHAR(htr.last_update_date, 'YYYY-MM-DD HH24:MI:SS'),
pap.name,
org.name,
NULL
FROM hwm_tm_rec htr
JOIN hwm_tm_rec_grp htrg ON htr.tm_rec_grp_id = htrg.tm_rec_grp_id
JOIN per_all_people_f rel ON htrg.person_id = rel.person_id
LEFT JOIN pay_all_payrolls_f pap ON htrg.payroll_id = pap.payroll_id
LEFT JOIN per_departments org ON rel.attribute1 = org.organization_id
WHERE htr.latest_version_flag = 'Y'
AND htr.tm_rec_status = 'APPROVED'
AND htr.last_update_date BETWEEN :bind_start_date AND :bind_end_date
UNION ALL
SELECT
rel.person_number || '-' || pee.element_entry_id,
'Incentive Data Imported',
TO_CHAR(pee.creation_date, 'YYYY-MM-DD HH24:MI:SS'),
'Oracle HCM Payroll',
TO_CHAR(pee.last_update_date, 'YYYY-MM-DD HH24:MI:SS'),
NULL,
org.name,
NULL
FROM pay_element_entries_f pee
JOIN pay_element_types_f pet ON pee.element_type_id = pet.element_type_id
JOIN per_all_assignments_m asg ON pee.assignment_id = asg.assignment_id
JOIN per_all_people_f rel ON asg.person_id = rel.person_id
LEFT JOIN per_departments org ON asg.organization_id = org.organization_id
WHERE pet.classification_name IN ('Supplemental Earnings', 'Voluntary Deductions')
AND pee.creator_type IN ('H', 'F') /* HDL or Flat File */
AND pee.creation_date BETWEEN :bind_start_date AND :bind_end_date
UNION ALL
SELECT
rel.person_number || '-' || ppa.payroll_action_id,
'Payroll Calculation Started',
TO_CHAR(ppa.creation_date, 'YYYY-MM-DD HH24:MI:SS'),
'Oracle HCM Payroll',
TO_CHAR(ppa.last_update_date, 'YYYY-MM-DD HH24:MI:SS'),
pap.name,
org.name,
NULL
FROM pay_payroll_actions ppa
JOIN pay_all_payrolls_f pap ON ppa.payroll_id = pap.payroll_id
JOIN pay_payroll_rel_actions pra ON ppa.payroll_action_id = pra.payroll_action_id
JOIN per_all_people_f rel ON pra.payroll_relationship_id = rel.person_id /* Simplified Join */
LEFT JOIN per_departments org ON rel.attribute1 = org.organization_id
WHERE ppa.action_type IN ('R', 'Q') /* Run or QuickPay */
AND ppa.creation_date BETWEEN :bind_start_date AND :bind_end_date
UNION ALL
SELECT
rel.person_number || '-' || ppa.payroll_action_id,
'Payroll Calculation Executed',
TO_CHAR(pra.action_sequence_date, 'YYYY-MM-DD HH24:MI:SS'),
'Oracle HCM Payroll',
TO_CHAR(pra.last_update_date, 'YYYY-MM-DD HH24:MI:SS'),
pap.name,
org.name,
(SELECT SUM(prrv.result_value) FROM pay_run_result_values prrv JOIN pay_run_results prr ON prrv.run_result_id = prr.run_result_id WHERE prr.payroll_rel_action_id = pra.payroll_rel_action_id) AS GrossPayAmount
FROM pay_payroll_rel_actions pra
JOIN pay_payroll_actions ppa ON pra.payroll_action_id = ppa.payroll_action_id
JOIN pay_all_payrolls_f pap ON ppa.payroll_id = pap.payroll_id
JOIN per_all_people_f rel ON pra.payroll_relationship_id = rel.person_id
LEFT JOIN per_departments org ON rel.attribute1 = org.organization_id
WHERE ppa.action_type IN ('R', 'Q')
AND pra.action_status = 'C'
AND pra.action_sequence_date BETWEEN :bind_start_date AND :bind_end_date
UNION ALL
SELECT
rel.person_number || '-' || ppa.payroll_action_id,
'Audit Exception Flagged',
TO_CHAR(pml.creation_date, 'YYYY-MM-DD HH24:MI:SS'),
'Oracle HCM Payroll',
TO_CHAR(pml.last_update_date, 'YYYY-MM-DD HH24:MI:SS'),
pap.name,
org.name,
NULL
FROM pay_message_lines pml
JOIN pay_payroll_rel_actions pra ON pml.source_id = pra.payroll_rel_action_id
JOIN pay_payroll_actions ppa ON pra.payroll_action_id = ppa.payroll_action_id
JOIN pay_all_payrolls_f pap ON ppa.payroll_id = pap.payroll_id
JOIN per_all_people_f rel ON pra.payroll_relationship_id = rel.person_id
LEFT JOIN per_departments org ON rel.attribute1 = org.organization_id
WHERE pml.message_level IN ('F', 'E') /* Fatal or Error */
AND pml.creation_date BETWEEN :bind_start_date AND :bind_end_date
UNION ALL
SELECT
rel.person_number || '-' || ppa.payroll_action_id,
'Payroll Record Corrected',
TO_CHAR(pee.last_update_date, 'YYYY-MM-DD HH24:MI:SS'),
'Oracle HCM Payroll',
TO_CHAR(pee.last_update_date, 'YYYY-MM-DD HH24:MI:SS'),
pap.name,
org.name,
NULL
FROM pay_element_entries_f pee
JOIN pay_payroll_rel_actions pra ON pee.creator_id = pra.payroll_rel_action_id
JOIN pay_payroll_actions ppa ON pra.payroll_action_id = ppa.payroll_action_id
JOIN pay_all_payrolls_f pap ON ppa.payroll_id = pap.payroll_id
JOIN per_all_people_f rel ON pra.payroll_relationship_id = rel.person_id
LEFT JOIN per_departments org ON rel.attribute1 = org.organization_id
WHERE pee.last_update_date > pee.creation_date
AND pee.last_update_date BETWEEN :bind_start_date AND :bind_end_date
UNION ALL
SELECT
rel.person_number || '-' || ppa.payroll_action_id,
'QuickPay Executed',
TO_CHAR(pra.action_sequence_date, 'YYYY-MM-DD HH24:MI:SS'),
'Oracle HCM Payroll',
TO_CHAR(pra.last_update_date, 'YYYY-MM-DD HH24:MI:SS'),
pap.name,
org.name,
NULL
FROM pay_payroll_rel_actions pra
JOIN pay_payroll_actions ppa ON pra.payroll_action_id = ppa.payroll_action_id
JOIN pay_all_payrolls_f pap ON ppa.payroll_id = pap.payroll_id
JOIN per_all_people_f rel ON pra.payroll_relationship_id = rel.person_id
LEFT JOIN per_departments org ON rel.attribute1 = org.organization_id
WHERE ppa.action_type = 'Q'
AND pra.action_status = 'C'
AND pra.action_sequence_date BETWEEN :bind_start_date AND :bind_end_date
UNION ALL
SELECT
rel.person_number || '-' || ppa.payroll_action_id,
'Prepayments Calculated',
TO_CHAR(pra.action_sequence_date, 'YYYY-MM-DD HH24:MI:SS'),
'Oracle HCM Payroll',
TO_CHAR(pra.last_update_date, 'YYYY-MM-DD HH24:MI:SS'),
pap.name,
org.name,
NULL
FROM pay_payroll_rel_actions pra
JOIN pay_payroll_actions ppa ON pra.payroll_action_id = ppa.payroll_action_id
JOIN pay_all_payrolls_f pap ON ppa.payroll_id = pap.payroll_id
JOIN per_all_people_f rel ON pra.payroll_relationship_id = rel.person_id
LEFT JOIN per_departments org ON rel.attribute1 = org.organization_id
WHERE ppa.action_type = 'P' /* Distribution */
AND pra.action_status = 'C'
AND pra.action_sequence_date BETWEEN :bind_start_date AND :bind_end_date
UNION ALL
SELECT
rel.person_number || '-' || ppa.payroll_action_id,
'Payroll Run Approved',
TO_CHAR(pfi.action_date, 'YYYY-MM-DD HH24:MI:SS'),
'Oracle HCM Payroll',
TO_CHAR(pfi.last_update_date, 'YYYY-MM-DD HH24:MI:SS'),
pap.name,
org.name,
NULL
FROM pay_flow_instances pfi
JOIN pay_payroll_actions ppa ON pfi.payroll_action_id = ppa.payroll_action_id
JOIN pay_all_payrolls_f pap ON ppa.payroll_id = pap.payroll_id
JOIN pay_payroll_rel_actions pra ON ppa.payroll_action_id = pra.payroll_action_id
JOIN per_all_people_f rel ON pra.payroll_relationship_id = rel.person_id
LEFT JOIN per_departments org ON rel.attribute1 = org.organization_id
WHERE pfi.status = 'COMPLETED'
AND pfi.instance_name LIKE '%Approval%'
AND pfi.action_date BETWEEN :bind_start_date AND :bind_end_date
UNION ALL
SELECT
rel.person_number || '-' || ppa.payroll_action_id,
'Archive Results Generated',
TO_CHAR(pra.action_sequence_date, 'YYYY-MM-DD HH24:MI:SS'),
'Oracle HCM Payroll',
TO_CHAR(pra.last_update_date, 'YYYY-MM-DD HH24:MI:SS'),
pap.name,
org.name,
NULL
FROM pay_payroll_rel_actions pra
JOIN pay_payroll_actions ppa ON pra.payroll_action_id = ppa.payroll_action_id
JOIN pay_all_payrolls_f pap ON ppa.payroll_id = pap.payroll_id
JOIN per_all_people_f rel ON pra.payroll_relationship_id = rel.person_id
LEFT JOIN per_departments org ON rel.attribute1 = org.organization_id
WHERE ppa.action_type = 'X' /* Archive */
AND pra.action_status = 'C'
AND pra.action_sequence_date BETWEEN :bind_start_date AND :bind_end_date
UNION ALL
SELECT
rel.person_number || '-' || ppa.payroll_action_id,
'Bank Transfer Generated',
TO_CHAR(pra.action_sequence_date, 'YYYY-MM-DD HH24:MI:SS'),
'Oracle HCM Payroll',
TO_CHAR(pra.last_update_date, 'YYYY-MM-DD HH24:MI:SS'),
pap.name,
org.name,
(SELECT SUM(ppp.value) FROM pay_pre_payments ppp WHERE ppp.payroll_action_id = ppa.payroll_action_id) AS GrossPayAmount
FROM pay_payroll_rel_actions pra
JOIN pay_payroll_actions ppa ON pra.payroll_action_id = ppa.payroll_action_id
JOIN pay_all_payrolls_f pap ON ppa.payroll_id = pap.payroll_id
JOIN per_all_people_f rel ON pra.payroll_relationship_id = rel.person_id
LEFT JOIN per_departments org ON rel.attribute1 = org.organization_id
WHERE ppa.action_type IN ('M', 'E') /* Mag Tape or EFT */
AND pra.action_status = 'C'
AND pra.action_sequence_date BETWEEN :bind_start_date AND :bind_end_date
UNION ALL
SELECT
rel.person_number || '-' || ppa.payroll_action_id,
'Payment Executed',
TO_CHAR(ppp.base_currency_value, 'YYYY-MM-DD HH24:MI:SS'),
'Oracle HCM Payroll',
TO_CHAR(ppa.last_update_date, 'YYYY-MM-DD HH24:MI:SS'),
pap.name,
org.name,
ppp.value AS GrossPayAmount
FROM pay_pre_payments ppp
JOIN pay_payroll_actions ppa ON ppp.payroll_action_id = ppa.payroll_action_id
JOIN pay_all_payrolls_f pap ON ppa.payroll_id = pap.payroll_id
JOIN pay_payroll_rel_actions pra ON ppa.payroll_action_id = pra.payroll_action_id
JOIN per_all_people_f rel ON pra.payroll_relationship_id = rel.person_id
LEFT JOIN per_departments org ON rel.attribute1 = org.organization_id
WHERE ppa.action_type IN ('H', 'E', 'M') /* Check or EFT */
AND ppa.effective_date BETWEEN :bind_start_date AND :bind_end_date
UNION ALL
SELECT
rel.person_number || '-' || ppa.payroll_action_id,
'Pay Slip Published',
TO_CHAR(pra.action_sequence_date, 'YYYY-MM-DD HH24:MI:SS'),
'Oracle HCM Payroll',
TO_CHAR(pra.last_update_date, 'YYYY-MM-DD HH24:MI:SS'),
pap.name,
org.name,
NULL
FROM pay_payroll_rel_actions pra
JOIN pay_payroll_actions ppa ON pra.payroll_action_id = ppa.payroll_action_id
JOIN pay_all_payrolls_f pap ON ppa.payroll_id = pap.payroll_id
JOIN per_all_people_f rel ON pra.payroll_relationship_id = rel.person_id
LEFT JOIN per_departments org ON rel.attribute1 = org.organization_id
WHERE ppa.action_type = 'G' /* Generate Payslip */
AND pra.action_status = 'C'
AND pra.action_sequence_date BETWEEN :bind_start_date AND :bind_end_date
UNION ALL
SELECT
rel.person_number || '-' || ppa.payroll_action_id,
'Costing Transferred',
TO_CHAR(pra.action_sequence_date, 'YYYY-MM-DD HH24:MI:SS'),
'Oracle HCM Payroll',
TO_CHAR(pra.last_update_date, 'YYYY-MM-DD HH24:MI:SS'),
pap.name,
org.name,
NULL
FROM pay_payroll_rel_actions pra
JOIN pay_payroll_actions ppa ON pra.payroll_action_id = ppa.payroll_action_id
JOIN pay_all_payrolls_f pap ON ppa.payroll_id = pap.payroll_id
JOIN per_all_people_f rel ON pra.payroll_relationship_id = rel.person_id
LEFT JOIN per_departments org ON rel.attribute1 = org.organization_id
WHERE ppa.action_type = 'T' /* Transfer to GL */
AND pra.action_status = 'C'
AND pra.action_sequence_date BETWEEN :bind_start_date AND :bind_end_date
UNION ALL
SELECT
rel.person_number || '-' || ppa.payroll_action_id,
'Tax Filing Completed',
TO_CHAR(pra.action_sequence_date, 'YYYY-MM-DD HH24:MI:SS'),
'Oracle HCM Payroll',
TO_CHAR(pra.last_update_date, 'YYYY-MM-DD HH24:MI:SS'),
pap.name,
org.name,
NULL
FROM pay_payroll_rel_actions pra
JOIN pay_payroll_actions ppa ON pra.payroll_action_id = ppa.payroll_action_id
JOIN pay_all_payrolls_f pap ON ppa.payroll_id = pap.payroll_id
JOIN per_all_people_f rel ON pra.payroll_relationship_id = rel.person_id
LEFT JOIN per_departments org ON rel.attribute1 = org.organization_id
WHERE ppa.report_category IN ('Tax', 'Regulatory') /* Customize based on local requirements */
AND pra.action_status = 'C'
AND pra.action_sequence_date BETWEEN :bind_start_date AND :bind_end_dateÉtapes
- Se connecter à Oracle BI Publisher : Accédez à l’environnement Oracle Cloud, puis à Tools > Reports and Analytics. Cliquez sur Browse Catalog pour ouvrir l’interface BI Publisher.
- Créer un modèle de données : Cliquez sur Nouveau (en haut à gauche), puis sélectionnez Modèle de données. Ce modèle accueillera la logique SQL d’extraction.
- Créer un jeu de données SQL : Dans l’onglet Diagram, cliquez sur l’icône Nouveau pour créer un jeu de données, puis sélectionnez SQL Query.
- Configurer la source de données : Nommez le jeu de données, par exemple
ProcessMind_Payroll_Extract. Définissez Source de données surApplicationDB_HCMou sur la connexion à votre base de données d’application HCM. Conservez le type Standard SQL. - Saisir la requête : Copiez le script SQL complet fourni dans la section Query ci-dessous et collez-le dans la zone de texte SQL Query. Veillez à ne pas inclure de mise en forme Markdown.
- Définir les paramètres : La requête utilise les variables de liaison
:p_start_dateet:p_end_date. Dans l’onglet Parameters du modèle de données, créez ces deux paramètres de type Date pour filtrer la période d’extraction, par exemple selonppa.EFFECTIVE_DATE. - Valider la structure des données : Cliquez sur OK, puis ouvrez l’onglet Données dans l’éditeur du modèle de données. Saisissez des dates d’exemple, par exemple
2023-01-01et2023-03-31, puis cliquez sur Afficher. Vérifiez que le résultat contient des lignes avecPayrollRecord,ActivityNameetEventTimestamp. - Enregistrer le modèle de données : Enregistrez le modèle dans un dossier partagé, par exemple
/Shared Folders/Custom/ProcessMining. - Créer un rapport à exporter : Cliquez sur Create Report, puis sélectionnez le modèle de données que vous venez d’enregistrer. Utilisez Report Wizard pour créer un tableau simple contenant toutes les colonnes. Décochez « Show Grand Totals ».
- Exporter au format CSV : Affichez le rapport dans Report Viewer. Cliquez sur le menu Actions (icône en forme d’engrenage), puis sur Export > Données > CSV.
- Transformer les données : Ouvrez le fichier CSV. Si les dates ne sont pas déjà au bon format, utilisez le format ISO 8601 (
YYYY-MM-DD HH:MM:SS). Aucune autre transformation ne devrait être nécessaire si le SQL a été correctement copié. - Importer le fichier : Importez le fichier CSV obtenu dans ProcessMind et associez les colonnes comme indiqué dans les exigences relatives aux données.
Configuration
- Connexion à la source de données : Utilisez
ApplicationDB_HCMou la source de données JNDI équivalente, avec un accès en lecture aux schémasPAY_etPER_. - Plage de dates : Une période d’extraction de 3 à 6 mois est recommandée pour couvrir des cycles de paie complets. Utilisez les paramètres
:p_start_dateet:p_end_datepour définir dynamiquement la période chargée. - Groupe de données législatives (LDG) : Par défaut, la requête extrait les données de tous les LDG. Si vous gérez plusieurs pays, vous pouvez ajouter le filtre
AND ppa.LEGISLATIVE_DATA_GROUP_ID = [Your_LDG_ID]pour répartir les données. - Performances : La requête interroge des tables volumineuses (
PAY_RUN_RESULTS,PAY_ASSIGNMENT_ACTIONS). Limitez la plage de dates, par exemple à moins d’un an, pour éviter les délais d’expiration dans BI Publisher. - Sécurité : L’utilisateur qui exécute le rapport doit disposer des autorisations Data Access Set pour les définitions de paie concernées.
a Exemple de requête sql
SELECT
TO_CHAR(papf.PERSON_NUMBER) || '-' || ptp.PERIOD_NAME AS PayrollRecord,
'Time Card Submitted' AS ActivityName,
peef.CREATION_DATE AS EventTimestamp,
'Oracle HCM' AS SourceSystem,
peef.LAST_UPDATE_DATE AS LastDataUpdate,
pld.NAME AS LegislativeDataGroup,
org.NAME AS DepartmentName,
peef.LAST_UPDATED_BY AS ProcessingUser,
NULL AS GrossPayAmount,
ptp.PERIOD_NAME AS PayrollPeriodName,
NULL AS SlaProcessingDeadline,
'N' AS IsManualCorrection,
pg.PAYROLL_NAME AS PayGroup,
NULL AS ProcessDurationDays
FROM PAY_ELEMENT_ENTRIES_F peef
JOIN PER_ALL_ASSIGNMENTS_M paam ON peef.ASSIGNMENT_ID = paam.ASSIGNMENT_ID
AND peef.EFFECTIVE_START_DATE BETWEEN paam.EFFECTIVE_START_DATE AND paam.EFFECTIVE_END_DATE
JOIN PER_ALL_PEOPLE_F papf ON paam.PERSON_ID = papf.PERSON_ID
AND peef.EFFECTIVE_START_DATE BETWEEN papf.EFFECTIVE_START_DATE AND papf.EFFECTIVE_END_DATE
JOIN PAY_PAY_RELATIONSHIPS_DN pprd ON paam.PAYROLL_RELATIONSHIP_ID = pprd.PAYROLL_RELATIONSHIP_ID
JOIN PER_TIME_PERIODS ptp ON pprd.PAYROLL_ID = ptp.PAYROLL_ID
AND peef.EFFECTIVE_START_DATE BETWEEN ptp.START_DATE AND ptp.END_DATE
LEFT JOIN PER_LEGISLATIVE_DATA_GROUPS_VL pld ON pprd.LEGISLATIVE_DATA_GROUP_ID = pld.LEGISLATIVE_DATA_GROUP_ID
LEFT JOIN HR_ORGANIZATION_UNITS_F_TL org ON paam.ORGANIZATION_ID = org.ORGANIZATION_ID AND org.LANGUAGE = USERENV('LANG')
LEFT JOIN PAY_ALL_PAYROLLS_F pg ON pprd.PAYROLL_ID = pg.PAYROLL_ID
WHERE peef.CREATOR_TYPE = 'H'
AND peef.CREATION_DATE BETWEEN :p_start_date AND :p_end_date
UNION ALL
SELECT
TO_CHAR(papf.PERSON_NUMBER) || '-' || ptp.PERIOD_NAME AS PayrollRecord,
'Time Card Approved' AS ActivityName,
peef.EFFECTIVE_START_DATE AS EventTimestamp,
'Oracle HCM' AS SourceSystem,
peef.LAST_UPDATE_DATE AS LastDataUpdate,
pld.NAME,
org.NAME,
peef.LAST_UPDATED_BY,
NULL,
ptp.PERIOD_NAME,
NULL,
'N',
pg.PAYROLL_NAME,
NULL
FROM PAY_ELEMENT_ENTRIES_F peef
JOIN PER_ALL_ASSIGNMENTS_M paam ON peef.ASSIGNMENT_ID = paam.ASSIGNMENT_ID
AND peef.EFFECTIVE_START_DATE BETWEEN paam.EFFECTIVE_START_DATE AND paam.EFFECTIVE_END_DATE
JOIN PER_ALL_PEOPLE_F papf ON paam.PERSON_ID = papf.PERSON_ID
AND peef.EFFECTIVE_START_DATE BETWEEN papf.EFFECTIVE_START_DATE AND papf.EFFECTIVE_END_DATE
JOIN PAY_PAY_RELATIONSHIPS_DN pprd ON paam.PAYROLL_RELATIONSHIP_ID = pprd.PAYROLL_RELATIONSHIP_ID
JOIN PER_TIME_PERIODS ptp ON pprd.PAYROLL_ID = ptp.PAYROLL_ID
AND peef.EFFECTIVE_START_DATE BETWEEN ptp.START_DATE AND ptp.END_DATE
LEFT JOIN PER_LEGISLATIVE_DATA_GROUPS_VL pld ON pprd.LEGISLATIVE_DATA_GROUP_ID = pld.LEGISLATIVE_DATA_GROUP_ID
LEFT JOIN HR_ORGANIZATION_UNITS_F_TL org ON paam.ORGANIZATION_ID = org.ORGANIZATION_ID AND org.LANGUAGE = USERENV('LANG')
LEFT JOIN PAY_ALL_PAYROLLS_F pg ON pprd.PAYROLL_ID = pg.PAYROLL_ID
WHERE peef.CREATOR_TYPE = 'H'
AND peef.EFFECTIVE_START_DATE BETWEEN :p_start_date AND :p_end_date
UNION ALL
SELECT
TO_CHAR(papf.PERSON_NUMBER) || '-' || ptp.PERIOD_NAME AS PayrollRecord,
'Incentive Data Imported' AS ActivityName,
peef.CREATION_DATE AS EventTimestamp,
'Oracle HCM' AS SourceSystem,
peef.LAST_UPDATE_DATE AS LastDataUpdate,
pld.NAME,
org.NAME,
peef.LAST_UPDATED_BY,
NULL,
ptp.PERIOD_NAME,
NULL,
'N',
pg.PAYROLL_NAME,
NULL
FROM PAY_ELEMENT_ENTRIES_F peef
JOIN PER_ALL_ASSIGNMENTS_M paam ON peef.ASSIGNMENT_ID = paam.ASSIGNMENT_ID
AND peef.EFFECTIVE_START_DATE BETWEEN paam.EFFECTIVE_START_DATE AND paam.EFFECTIVE_END_DATE
JOIN PER_ALL_PEOPLE_F papf ON paam.PERSON_ID = papf.PERSON_ID
AND peef.EFFECTIVE_START_DATE BETWEEN papf.EFFECTIVE_START_DATE AND papf.EFFECTIVE_END_DATE
JOIN PAY_PAY_RELATIONSHIPS_DN pprd ON paam.PAYROLL_RELATIONSHIP_ID = pprd.PAYROLL_RELATIONSHIP_ID
JOIN PER_TIME_PERIODS ptp ON pprd.PAYROLL_ID = ptp.PAYROLL_ID
AND peef.EFFECTIVE_START_DATE BETWEEN ptp.START_DATE AND ptp.END_DATE
LEFT JOIN PER_LEGISLATIVE_DATA_GROUPS_VL pld ON pprd.LEGISLATIVE_DATA_GROUP_ID = pld.LEGISLATIVE_DATA_GROUP_ID
LEFT JOIN HR_ORGANIZATION_UNITS_F_TL org ON paam.ORGANIZATION_ID = org.ORGANIZATION_ID AND org.LANGUAGE = USERENV('LANG')
LEFT JOIN PAY_ALL_PAYROLLS_F pg ON pprd.PAYROLL_ID = pg.PAYROLL_ID
WHERE peef.CREATOR_TYPE IN ('B', 'F')
AND peef.CREATION_DATE BETWEEN :p_start_date AND :p_end_date
UNION ALL
SELECT
TO_CHAR(papf.PERSON_NUMBER) || '-' || ptp.PERIOD_NAME AS PayrollRecord,
CASE
WHEN ppa.ACTION_TYPE = 'R' AND paa.ACTION_STATUS = 'C' THEN 'Payroll Calculation Executed'
WHEN ppa.ACTION_TYPE = 'R' THEN 'Payroll Calculation Started'
WHEN ppa.ACTION_TYPE = 'Q' THEN 'QuickPay Executed'
WHEN ppa.ACTION_TYPE IN ('P', 'U') THEN 'Prepayments Calculated'
WHEN ppa.ACTION_TYPE = 'X' THEN 'Archive Results Generated'
WHEN ppa.ACTION_TYPE = 'M' THEN 'Bank Transfer Generated'
WHEN ppa.ACTION_TYPE IN ('Z', 'E') THEN 'Payment Executed'
WHEN ppa.ACTION_TYPE = 'T' THEN 'Costing Transferred'
ELSE 'Payroll Process Action'
END AS ActivityName,
ppa.CREATION_DATE AS EventTimestamp,
'Oracle HCM' AS SourceSystem,
paa.LAST_UPDATE_DATE AS LastDataUpdate,
pld.NAME,
org.NAME,
ppa.LAST_UPDATED_BY,
NULL,
ptp.PERIOD_NAME,
ptp.REGULAR_PAYMENT_DATE AS SlaProcessingDeadline,
'N',
pg.PAYROLL_NAME,
NULL
FROM PAY_PAYROLL_ACTIONS ppa
JOIN PAY_ASSIGNMENT_ACTIONS paa ON ppa.PAYROLL_ACTION_ID = paa.PAYROLL_ACTION_ID
JOIN PER_ALL_ASSIGNMENTS_M paam ON paa.ASSIGNMENT_ID = paam.ASSIGNMENT_ID
AND ppa.EFFECTIVE_DATE BETWEEN paam.EFFECTIVE_START_DATE AND paam.EFFECTIVE_END_DATE
JOIN PER_ALL_PEOPLE_F papf ON paam.PERSON_ID = papf.PERSON_ID
AND ppa.EFFECTIVE_DATE BETWEEN papf.EFFECTIVE_START_DATE AND papf.EFFECTIVE_END_DATE
JOIN PER_TIME_PERIODS ptp ON ppa.PAYROLL_ID = ptp.PAYROLL_ID
AND ppa.DATE_EARNED BETWEEN ptp.START_DATE AND ptp.END_DATE
LEFT JOIN PER_LEGISLATIVE_DATA_GROUPS_VL pld ON ppa.LEGISLATIVE_DATA_GROUP_ID = pld.LEGISLATIVE_DATA_GROUP_ID
LEFT JOIN HR_ORGANIZATION_UNITS_F_TL org ON paam.ORGANIZATION_ID = org.ORGANIZATION_ID AND org.LANGUAGE = USERENV('LANG')
LEFT JOIN PAY_ALL_PAYROLLS_F pg ON ppa.PAYROLL_ID = pg.PAYROLL_ID
WHERE ppa.ACTION_TYPE IN ('R', 'Q', 'P', 'U', 'X', 'M', 'Z', 'E', 'T')
AND ppa.EFFECTIVE_DATE BETWEEN :p_start_date AND :p_end_date
UNION ALL
SELECT
TO_CHAR(papf.PERSON_NUMBER) || '-' || ptp.PERIOD_NAME AS PayrollRecord,
'Audit Exception Flagged' AS ActivityName,
pml.CREATION_DATE AS EventTimestamp,
'Oracle HCM' AS SourceSystem,
pml.LAST_UPDATE_DATE AS LastDataUpdate,
pld.NAME,
org.NAME,
pml.LAST_UPDATED_BY,
NULL,
ptp.PERIOD_NAME,
NULL,
'Y',
pg.PAYROLL_NAME,
NULL
FROM PAY_MESSAGE_LINES pml
JOIN PAY_PAYROLL_ACTIONS ppa ON pml.PAYROLL_ACTION_ID = ppa.PAYROLL_ACTION_ID
LEFT JOIN PAY_ASSIGNMENT_ACTIONS paa ON ppa.PAYROLL_ACTION_ID = paa.PAYROLL_ACTION_ID
JOIN PER_ALL_ASSIGNMENTS_M paam ON paa.ASSIGNMENT_ID = paam.ASSIGNMENT_ID
AND ppa.EFFECTIVE_DATE BETWEEN paam.EFFECTIVE_START_DATE AND paam.EFFECTIVE_END_DATE
JOIN PER_ALL_PEOPLE_F papf ON paam.PERSON_ID = papf.PERSON_ID
AND ppa.EFFECTIVE_DATE BETWEEN papf.EFFECTIVE_START_DATE AND papf.EFFECTIVE_END_DATE
JOIN PER_TIME_PERIODS ptp ON ppa.PAYROLL_ID = ptp.PAYROLL_ID
AND ppa.DATE_EARNED BETWEEN ptp.START_DATE AND ptp.END_DATE
LEFT JOIN PER_LEGISLATIVE_DATA_GROUPS_VL pld ON ppa.LEGISLATIVE_DATA_GROUP_ID = pld.LEGISLATIVE_DATA_GROUP_ID
LEFT JOIN HR_ORGANIZATION_UNITS_F_TL org ON paam.ORGANIZATION_ID = org.ORGANIZATION_ID AND org.LANGUAGE = USERENV('LANG')
LEFT JOIN PAY_ALL_PAYROLLS_F pg ON ppa.PAYROLL_ID = pg.PAYROLL_ID
WHERE pml.MESSAGE_LEVEL IN ('E', 'W')
AND pml.CREATION_DATE BETWEEN :p_start_date AND :p_end_date
UNION ALL
SELECT
TO_CHAR(papf.PERSON_NUMBER) || '-' || ptp.PERIOD_NAME AS PayrollRecord,
'Payroll Record Corrected' AS ActivityName,
peef.LAST_UPDATE_DATE AS EventTimestamp,
'Oracle HCM' AS SourceSystem,
peef.LAST_UPDATE_DATE AS LastDataUpdate,
pld.NAME,
org.NAME,
peef.LAST_UPDATED_BY,
NULL,
ptp.PERIOD_NAME,
NULL,
'Y',
pg.PAYROLL_NAME,
NULL
FROM PAY_ELEMENT_ENTRIES_F peef
JOIN PER_ALL_ASSIGNMENTS_M paam ON peef.ASSIGNMENT_ID = paam.ASSIGNMENT_ID
AND peef.EFFECTIVE_START_DATE BETWEEN paam.EFFECTIVE_START_DATE AND paam.EFFECTIVE_END_DATE
JOIN PER_ALL_PEOPLE_F papf ON paam.PERSON_ID = papf.PERSON_ID
AND peef.EFFECTIVE_START_DATE BETWEEN papf.EFFECTIVE_START_DATE AND papf.EFFECTIVE_END_DATE
JOIN PAY_PAY_RELATIONSHIPS_DN pprd ON paam.PAYROLL_RELATIONSHIP_ID = pprd.PAYROLL_RELATIONSHIP_ID
JOIN PER_TIME_PERIODS ptp ON pprd.PAYROLL_ID = ptp.PAYROLL_ID
AND peef.EFFECTIVE_START_DATE BETWEEN ptp.START_DATE AND ptp.END_DATE
LEFT JOIN PER_LEGISLATIVE_DATA_GROUPS_VL pld ON pprd.LEGISLATIVE_DATA_GROUP_ID = pld.LEGISLATIVE_DATA_GROUP_ID
LEFT JOIN HR_ORGANIZATION_UNITS_F_TL org ON paam.ORGANIZATION_ID = org.ORGANIZATION_ID AND org.LANGUAGE = USERENV('LANG')
LEFT JOIN PAY_ALL_PAYROLLS_F pg ON pprd.PAYROLL_ID = pg.PAYROLL_ID
WHERE peef.LAST_UPDATE_DATE > peef.CREATION_DATE
AND peef.LAST_UPDATE_DATE BETWEEN :p_start_date AND :p_end_date
UNION ALL
SELECT
TO_CHAR(papf.PERSON_NUMBER) || '-' || ptp.PERIOD_NAME AS PayrollRecord,
'Payroll Run Approved' AS ActivityName,
ppa.LAST_UPDATE_DATE AS EventTimestamp,
'Oracle HCM' AS SourceSystem,
ppa.LAST_UPDATE_DATE AS LastDataUpdate,
pld.NAME,
org.NAME,
ppa.LAST_UPDATED_BY,
NULL,
ptp.PERIOD_NAME,
NULL,
'N',
pg.PAYROLL_NAME,
NULL
FROM PAY_PAYROLL_ACTIONS ppa
JOIN PAY_ASSIGNMENT_ACTIONS paa ON ppa.PAYROLL_ACTION_ID = paa.PAYROLL_ACTION_ID
JOIN PER_ALL_ASSIGNMENTS_M paam ON paa.ASSIGNMENT_ID = paam.ASSIGNMENT_ID
AND ppa.EFFECTIVE_DATE BETWEEN paam.EFFECTIVE_START_DATE AND paam.EFFECTIVE_END_DATE
JOIN PER_ALL_PEOPLE_F papf ON paam.PERSON_ID = papf.PERSON_ID
AND ppa.EFFECTIVE_DATE BETWEEN papf.EFFECTIVE_START_DATE AND papf.EFFECTIVE_END_DATE
JOIN PER_TIME_PERIODS ptp ON ppa.PAYROLL_ID = ptp.PAYROLL_ID
AND ppa.DATE_EARNED BETWEEN ptp.START_DATE AND ptp.END_DATE
LEFT JOIN PER_LEGISLATIVE_DATA_GROUPS_VL pld ON ppa.LEGISLATIVE_DATA_GROUP_ID = pld.LEGISLATIVE_DATA_GROUP_ID
LEFT JOIN HR_ORGANIZATION_UNITS_F_TL org ON paam.ORGANIZATION_ID = org.ORGANIZATION_ID AND org.LANGUAGE = USERENV('LANG')
LEFT JOIN PAY_ALL_PAYROLLS_F pg ON ppa.PAYROLL_ID = pg.PAYROLL_ID
WHERE ppa.ACTION_TYPE = 'R'
AND paa.ACTION_STATUS = 'C'
AND ppa.EFFECTIVE_DATE BETWEEN :p_start_date AND :p_end_date
UNION ALL
SELECT
TO_CHAR(papf.PERSON_NUMBER) || '-' || ptp.PERIOD_NAME AS PayrollRecord,
'Pay Slip Published' AS ActivityName,
(ppa.CREATION_DATE + 1) AS EventTimestamp,
'Oracle HCM' AS SourceSystem,
ppa.LAST_UPDATE_DATE AS LastDataUpdate,
pld.NAME,
org.NAME,
ppa.LAST_UPDATED_BY,
NULL,
ptp.PERIOD_NAME,
NULL,
'N',
pg.PAYROLL_NAME,
NULL
FROM PAY_PAYROLL_ACTIONS ppa
JOIN PAY_ASSIGNMENT_ACTIONS paa ON ppa.PAYROLL_ACTION_ID = paa.PAYROLL_ACTION_ID
JOIN PER_ALL_ASSIGNMENTS_M paam ON paa.ASSIGNMENT_ID = paam.ASSIGNMENT_ID
AND ppa.EFFECTIVE_DATE BETWEEN paam.EFFECTIVE_START_DATE AND paam.EFFECTIVE_END_DATE
JOIN PER_ALL_PEOPLE_F papf ON paam.PERSON_ID = papf.PERSON_ID
AND ppa.EFFECTIVE_DATE BETWEEN papf.EFFECTIVE_START_DATE AND papf.EFFECTIVE_END_DATE
JOIN PER_TIME_PERIODS ptp ON ppa.PAYROLL_ID = ptp.PAYROLL_ID
AND ppa.DATE_EARNED BETWEEN ptp.START_DATE AND ptp.END_DATE
LEFT JOIN PER_LEGISLATIVE_DATA_GROUPS_VL pld ON ppa.LEGISLATIVE_DATA_GROUP_ID = pld.LEGISLATIVE_DATA_GROUP_ID
LEFT JOIN HR_ORGANIZATION_UNITS_F_TL org ON paam.ORGANIZATION_ID = org.ORGANIZATION_ID AND org.LANGUAGE = USERENV('LANG')
LEFT JOIN PAY_ALL_PAYROLLS_F pg ON ppa.PAYROLL_ID = pg.PAYROLL_ID
WHERE ppa.ACTION_TYPE = 'X'
AND ppa.EFFECTIVE_DATE BETWEEN :p_start_date AND :p_end_date
UNION ALL
SELECT
TO_CHAR(papf.PERSON_NUMBER) || '-' || ptp.PERIOD_NAME AS PayrollRecord,
'Tax Filing Completed' AS ActivityName,
ppa.CREATION_DATE AS EventTimestamp,
'Oracle HCM' AS SourceSystem,
ppa.LAST_UPDATE_DATE AS LastDataUpdate,
pld.NAME,
org.NAME,
ppa.LAST_UPDATED_BY,
NULL,
ptp.PERIOD_NAME,
NULL,
'N',
pg.PAYROLL_NAME,
NULL
FROM PAY_PAYROLL_ACTIONS ppa
JOIN PAY_ASSIGNMENT_ACTIONS paa ON ppa.PAYROLL_ACTION_ID = paa.PAYROLL_ACTION_ID
JOIN PER_ALL_ASSIGNMENTS_M paam ON paa.ASSIGNMENT_ID = paam.ASSIGNMENT_ID
AND ppa.EFFECTIVE_DATE BETWEEN paam.EFFECTIVE_START_DATE AND paam.EFFECTIVE_END_DATE
JOIN PER_ALL_PEOPLE_F papf ON paam.PERSON_ID = papf.PERSON_ID
AND ppa.EFFECTIVE_DATE BETWEEN papf.EFFECTIVE_START_DATE AND papf.EFFECTIVE_END_DATE
JOIN PER_TIME_PERIODS ptp ON ppa.PAYROLL_ID = ptp.PAYROLL_ID
AND ppa.DATE_EARNED BETWEEN ptp.START_DATE AND ptp.END_DATE
LEFT JOIN PER_LEGISLATIVE_DATA_GROUPS_VL pld ON ppa.LEGISLATIVE_DATA_GROUP_ID = pld.LEGISLATIVE_DATA_GROUP_ID
LEFT JOIN HR_ORGANIZATION_UNITS_F_TL org ON paam.ORGANIZATION_ID = org.ORGANIZATION_ID AND org.LANGUAGE = USERENV('LANG')
LEFT JOIN PAY_ALL_PAYROLLS_F pg ON ppa.PAYROLL_ID = pg.PAYROLL_ID
WHERE ppa.ACTION_TYPE = 'Z'
AND ppa.CREATION_DATE BETWEEN :p_start_date AND :p_end_datePrêt à commencer ?
Transformez vos opérations de paie en utilisant ce modèle de données pour mieux comprendre vos cycles. Commencez dès aujourd’hui à améliorer l’efficacité et la précision de vos rapports.
Optimisez dès aujourd’hui le traitement de la paie dans Oracle HCM
Réduisez de 30 % le temps de cycle de la paie et éliminez les goulots d’étranglement.
Aucune carte bancaire requise. Configuration en quelques minutes.