Quelles données sont nécessaires pour intégrer l'accès au salaire déjà gagné avec la gestion du temps, la paie et l'ERP ?

Quelles données sont nécessaires pour intégrer l'accès au salaire déjà gagné avec la gestion du temps, la paie et l'ERP ?

Pour intégrer l'accès au salaire déjà gagné avec la gestion du temps, la paie et l'ERP, une entreprise a besoin d'au moins cinq groupes de données : dossiers des employés, heures approuvées, périodes et règles de paie, ajustements ou déductions, et transactions de paiement anticipé. Toutes ces données doivent utiliser un identifiant d'employé unique, avoir un statut, un moment de mise à jour, une version des données et un journal de suivi. Une bonne architecture ne doit pas seulement transmettre les données rapidement, mais aussi empêcher les paiements en double, gérer les données corrigées tardivement et réconcilier chaque transaction.

> Remarque : Cet article présente une architecture de référence pour un système d'accès au salaire déjà gagné (EWA). Les noms de champs, statuts, flux d'approbation et méthodes comptables réelles doivent être confirmés par Nhan Kiet et l'entreprise lors de la phase d'étude d'intégration.

> Explication des termes : EWA (accès au salaire déjà gagné) · HRIS/HRM (système d'information des ressources humaines) · ERP (système de planification des ressources d'entreprise) · paie (gestion de la paie) · API (interface de programmation d'application) · batch (traitement par lots) · SFTP (protocole de transfert de fichiers sécurisé) · idempotence (anti-duplication : envoyer plusieurs fois ne crée qu'un seul résultat) · UAT (tests d'acceptation utilisateur) · mise en production (go-live) · retour en arrière (rollback) · webhook/callback (notification automatique entre systèmes) · jeton (token) · dictionnaire de données (data dictionary) · système d'enregistrement (system of record) · réessai (retry) · expiration (timeout).

Pourquoi l'accès au salaire déjà gagné doit-il se connecter simultanément à la gestion du temps, la paie et l'ERP ?

L'accès au salaire déjà gagné doit répondre à trois questions avant de permettre à un travailleur de recevoir de l'argent :

1. Cette personne travaille-t-elle actuellement et fait-elle partie du programme ?

2. Jusqu'à présent, combien de salaire éligible a-t-elle généré ?

3. Après les transactions précédentes et les montants à retenir, combien reste-t-il à recevoir ?

Le système de ressources humaines vérifie généralement l'identité et le statut de l'emploi. Le système de gestion du temps enregistre les heures ou les jours travaillés. La paie gère les règles de paie, les périodes de paie et les ajustements. L'ERP ou le système comptable sert à enregistrer, réconcilier et finaliser les comptes. Le système de paiement fournit l'état final du transfert d'argent.

Si l'on ne se connecte qu'à une seule source, l'accès au salaire déjà gagné peut voir le travailleur mais ne pas connaître les heures approuvées ; ou voir les heures mais ne pas savoir si la période de paie est verrouillée ; ou avoir transféré de l'argent mais la paie n'a pas encore reçu la transaction pour réconciliation. Ainsi, le point le plus important n'est pas simplement de "connecter une API", mais d'établir une chaîne de données cohérente allant des heures travaillées aux transactions finalisées.

1. Architecture globale des données

Une architecture de référence peut être organisée comme suit :

flowchart TD
    A["HRIS : employés"] --> D["Couche d'intégration"]
    B["Gestion du temps : heures approuvées"] --> D
    C["Paie : périodes et règles"] --> D
    D --> E["Moteur de calcul des limites EWA"]
    E --> F["Application EWA"]
    F --> G["Système de paiement"]
    G --> H["Réconciliation paie, ERP et comptabilité"]
    H --> E

Chaque domaine de données devrait avoir une source de données de référence (système d'enregistrement). Il ne faut pas que le HRIS, la paie et l'EWA modifient un attribut de trois manières différentes.

2. Liste minimale des données des employés

Il ne faut pas synchroniser l'ensemble des dossiers des ressources humaines simplement parce que "cela pourrait être nécessaire". Le principe approprié est de collecter et transmettre uniquement les données nécessaires à l'objectif défini.

Les numéros de compte complets ne devraient exister que dans le domaine réellement nécessaire pour le paiement, avec des droits d'accès et une protection appropriés. L'environnement de test devrait utiliser des données fictives ou masquées, sans copier les données de production.

3. Données de gestion du temps et statut d'approbation

L'accès au salaire déjà gagné ne devrait pas seulement recevoir un chiffre "total des heures du mois". Le système a besoin d'informations suffisantes pour savoir quelles données ont été confirmées et lesquelles peuvent encore changer.

Les champs généralement nécessaires incluent :

• employee_id : identifiant d'employé unique ;

• work_date : date de travail ;

• shift_id : identifiant de quart, si l'entreprise gère par quart ;

• regularhours, overtimehours : heures normales et heures supplémentaires ;

• attendance_status : présent, en congé, absent ou statut équivalent ;

• approval_status : en attente d'approbation, approuvé, refusé, ajusté ou verrouillé ;

• approvedby, approvedat : personne et moment de l'approbation si la politique l'exige ;

• sourceupdatedat, record_version : moment et version de l'enregistrement ;

• source_system : système générateur des données.

Pourquoi le statut "approuvé" est-il important ?

Un passage de carte ne garantit pas une heure valide. Un employé peut oublier de pointer la sortie, enregistrer un mauvais quart ou faire des ajustements après l'approbation du gestionnaire. L'entreprise doit clairement définir quel statut est pris en compte pour le calcul de l'accès au salaire déjà gagné (voir Qu'est-ce qu'une heure approuvée ?).

Exemple d'un enregistrement illustratif :

{
  "employee_id": "EMP-000123",
  "work_date": "2026-08-18",
  "shift_id": "SHIFT-A",
  "regular_hours": 8,
  "overtime_hours": 0,
  "approval_status": "APPROVED",
  "source_updated_at": "2026-08-19T02:15:30Z",
  "record_version": 3
}

Ceci est un exemple de données sécurisées à des fins d'illustration, et non une spécification API officielle de l'accès au salaire déjà gagné.

4. Données de paie et ajustements

Les données de paie aident à transformer les "heures approuvées" en "montant de salaire éligible". Le jeu de données comprend généralement :

• identifiant de période de paie payperiodid et dates de début et de fin ;

• groupe de paie et cycle de paiement ;

• base de calcul des salaires ou taux nécessaires pour la formule convenue ;

• code de revenu earning_code ;

• ajustements, retenues ou déductions pertinents ;

• date de clôture des heures et moment de verrouillage de la paie ;

• statut de la période de paie : ouverte, en cours de traitement, verrouillée ou finalisée ;

• devise et règles d'arrondi ;

• version de la formule/politique appliquée.

Tous les éléments de la fiche de paie ne sont pas pris en compte pour le calcul de l'accès au salaire déjà gagné. Le salaire de base, les allocations, les heures supplémentaires, les primes ou les commissions ont des niveaux de certitude et des moments d'approbation différents. L'entreprise doit établir un tableau de règles précisant quels éléments sont pris en compte, à partir de quel statut et avec quelles limites.

Quelles colonnes un tableau de règles devrait-il avoir ?

Les valeurs réelles dans ce tableau doivent être confirmées par l'entreprise et l'entité de mise en œuvre. Il ne faut pas supposer à partir du nom de l'élément de paie.

5. Données de transaction de paiement anticipé

Chaque demande de paiement anticipé doit être une transaction traçable de manière indépendante.

Un cycle de vie de transaction de référence comprend : CREATED → VALIDATING → PROCESSING → SUCCEEDED ou FAILED. Si le résultat du paiement n'est pas encore déterminé, la transaction doit être en statut UNKNOWN ou équivalent pour enquête ; elle ne doit pas être automatiquement considérée comme échouée puis transférée à nouveau. Le système doit également avoir des statuts de remboursement et de réconciliation lorsque des opérations se produisent.

6. Choisir API, fichier batch ou synchronisation manuelle ?

Il n'existe pas de méthode unique adaptée à toutes les entreprises. Il est possible de combiner plusieurs méthodes selon la maturité de chaque système.

Si vous utilisez une API HTTP, l'entreprise peut décrire le contrat d'intégration avec la spécification OpenAPI pour convenir des points de terminaison, de la structure des données et des réponses. OpenAPI est une norme pour décrire les API HTTP ; c'est un choix technique utile, mais pas une condition obligatoire pour déployer l'accès au salaire déjà gagné.

7. Identification et prévention des doublons de données

Une mauvaise identification est l'un des risques les plus dangereux. L'email, le numéro de téléphone ou le numéro de compte peuvent changer, ils ne conviennent donc pas comme clé principale d'employé.

Recommandations :

• utiliser un employee_id immuable dans le cadre d'une entreprise ;

• combiner avec employerid ou legalentity_id si la plateforme dessert plusieurs entités ;

• ne pas réutiliser le code d'une personne ayant quitté pour une nouvelle personne ;

• maintenir un tableau de correspondance lorsque le HRIS et la paie utilisent deux ensembles de codes différents ;

• enregistrer la date d'effet pour les changements de groupe de paie, d'unité et de statut d'emploi ;

• vérifier les doublons selon la clé métier, pas seulement selon le contenu identique.

Avec un fichier batch, chaque fichier doit avoir un code de lot, un moment de création, un nombre total d'enregistrements et un checksum. Avec une API, chaque demande de création de transaction doit avoir une idempotency_key.

8. Idempotence et réconciliation : deux niveaux de protection différents

L'idempotence permet qu'une demande envoyée plusieurs fois ne crée qu'un seul résultat métier. Par exemple, l'application expire après avoir envoyé une commande de transfert d'argent. Lors de l'envoi à nouveau avec la même idempotency_key, le système doit renvoyer l'ancienne transaction ou son statut, au lieu de créer un nouveau paiement.

La réconciliation vérifie si les systèmes enregistrent la même transaction (associée au processus d'accès au salaire déjà gagné de la gestion du temps à la réconciliation). Un modèle approprié est la réconciliation à trois voies :

1. transaction dans la plateforme EWA ;

2. résultat de la banque ou de l'entité de paiement ;

3. données de paie/ERP ou dossier de finalisation approuvé.

Le rapport de réconciliation doit indiquer au moins :

• transactions entièrement correspondantes ;

• présentes dans l'EWA mais sans résultat de paiement ;

• résultat de paiement mais absent de la paie/ERP ;

• écart de montant, de frais, de bénéficiaire ou de période de paie ;

• transaction remboursée mais non mise à jour ;

• enregistrement en double ou mise à jour dans le mauvais ordre.

Chaque écart doit avoir un responsable, un statut de traitement et une preuve de clôture de l'erreur.

9. Gestion des erreurs, réessai et alertes

Toutes les erreurs ne doivent pas être automatiquement réessayées.

Chaque demande doit avoir un correlation_id pour le suivi à travers les systèmes. Les alertes doivent contenir l'identifiant de la transaction, le type d'erreur, le moment, le système source et l'étape suivante, mais ne doivent pas inclure de mot de passe, de clé API ou de données sensibles complètes dans le journal.

10. Exemple de demande API illustratif

{
  "idempotency_key": "ewa-demo-20260818-0001",
  "employee_id": "EMP-000123",
  "pay_period_id": "2026-08",
  "requested_amount": 1000000,
  "currency": "VND",
  "source_data_version": "attendance-v18_payroll-v6",
  "requested_at": "2026-08-18T09:20:00+07:00"
}

La réponse doit indiquer si la demande est acceptée, refusée ou nécessite un traitement supplémentaire ; en même temps, renvoyer transactionid, statut, code de raison et correlationid. Il ne faut pas renvoyer de données de compte complètes ou d'informations non nécessaires.

La spécification API doit clairement définir :

• méthode d'authentification et de droits d'accès ;

• version de l'API et politique de changement ;

• format de date et heure, fuseau horaire et devise ;

• précision des montants et règles d'arrondi ;

• catalogue des codes d'erreur ;

• expiration et politique de réessai ;

• signature/vérification de callback ou webhook ;

• limites de charge ;

• règles d'idempotence ;

• durée de conservation des statuts et journaux.

11. Sécurité et protection des données dès la conception

Les données des employés, les salaires, les comptes bénéficiaires et l'historique des transactions ont un niveau de sensibilité élevé. La conception de l'intégration doit inclure :

• droits d'accès par rôle et principe du moindre privilège ;

• chiffrement des données en transit et au repos ;

• gestion centralisée des secrets, sans clés d'accès dans le code source ou le journal ;

• séparation des environnements de développement, de test et de production ;

• données de test simulées ou masquées ;

• journal des accès et des modifications de configuration ;

• durée de conservation, processus de suppression et gestion des demandes des sujets de données ;

• évaluation des fournisseurs et portée du partage des données ;

• plan de réponse, notification et enquête en cas d'incident.

Au Vietnam, la conception et l'exploitation doivent être examinées par le département juridique conformément à la Loi sur la protection des données personnelles n° 91/2025/QH15 et au Décret 356/2025/NĐ-CP, tous deux en vigueur à partir du 1er janvier 2026. Les dossiers, messages et documents électroniques doivent également être examinés dans le cadre de la Loi sur les transactions électroniques 2023 et des réglementations sectorielles pertinentes.

12. Liste de contrôle UAT avant la mise en production

L'UAT ne doit pas seulement vérifier "réception du fichier" ou "API renvoie 200" (intégrer dans le plan pilote de 90 jours pour l'accès au salaire déjà gagné). Il faut tester suffisamment de scénarios métier et d'erreurs opérationnelles.

Employés et conditions de participation

• [ ] Employé en activité et éligible.

• [ ] Nouvel employé avant la date d'effet.

• [ ] Employé en congé ou ayant quitté.

• [ ] Employé changeant d'entité légale, de groupe de paie ou d'identifiant.

• [ ] Changement de compte bénéficiaire selon le processus de vérification.

Gestion du temps et limites

• [ ] Heures en attente d'approbation non comptabilisées si la politique exige des heures approuvées.

• [ ] Heures approuvées modifiant correctement la limite.

• [ ] Heures modifiées ou retirées après approbation recalculées correctement.

• [ ] Données anciennes arrivant après les nouvelles ne remplaçant pas incorrectement la version.

• [ ] Date de clôture des heures, fuseau horaire et quarts de nuit traités correctement.

Transactions et paiements

• [ ] Envoi répété avec idempotency_key ne créant pas deux transactions.

• [ ] Limite insuffisante renvoyant la raison exacte.

• [ ] Expiration du système de paiement et résultat incertain ne causant pas de double paiement.

• [ ] Transactions échouées, remboursées et inversées mises à jour correctement.

• [ ] Limite avant et après transaction correspondant au registre des transactions.

Fichier batch et API

• [ ] Fichier en double, fichier dans le mauvais ordre et enregistrement en double détectés.

• [ ] Certains enregistrements erronés ne perdant pas la trace des enregistrements traités.

• [ ] API expirant l'authentification, manquant de droits et dépassant les limites de charge renvoyant les erreurs correctes.

• [ ] Callback falsifié ou signature incorrecte rejeté.

• [ ] Réessai respectant les limites et conservant la clé anti-duplication.

Paie, ERP et réconciliation

• [ ] Période de paie ouverte, verrouillée et finalisée traitée correctement.

• [ ] Transaction EWA incluse dans le dossier de réconciliation de la période de paie selon le processus approuvé.

• [ ] Trois sources EWA – paiement – paie/ERP correspondant en montant et statut.

• [ ] Écart générant une alerte et ayant un processus de traitement jusqu'à clôture.

• [ ] Rapport traçable de l'écriture comptable à la transaction et aux données sources.

Sécurité et exploitation

• [ ] Personne sans droits ne pouvant voir ou modifier les données.

• [ ] Journal ne contenant pas de secrets ou de données sensibles complètes.

• [ ] Clés d'accès pouvant être tournées sans interruption prolongée.

• [ ] Personnel de garde, canal d'alerte et processus de gestion des incidents en place.

• [ ] Plan de retour en arrière si la mise en production rencontre des erreurs graves.

13. Dossier technique à finaliser avant le déploiement

Un dossier d'intégration minimal devrait inclure :

1. schéma d'architecture et limites des responsabilités ;

2. dictionnaire de données pour chaque champ ;

3. tableau de correspondance des identifiants d'employés, périodes de paie, unités et codes d'éléments ;

4. spécification API ou spécification de fichier ;

5. catalogue des statuts et codes d'erreur ;

6. règles de calcul des limites approuvées ;

7. règles anti-duplication, réessai et gestion des données arrivant tardivement ;

8. flux de réconciliation et modèle de rapport d'écart ;

9. matrice des droits d'accès et exigences de sécurité ;

10. plan UAT, transition, retour en arrière et support après mise en production.

Les parties doivent également effectuer des tests de contrat de données. Lorsqu'un système change le nom d'un champ, le type de données, le catalogue des statuts ou la signification métier, le pipeline doit alerter avant que le changement ne provoque une erreur de limite en dehors de l'environnement de production.
## 14. Données que Nhan Kiet doit compléter avant de publier la version finale

Pour que l'article reflète correctement les capacités réelles de l'accès au salaire déjà gagné, l'équipe Product/IT doit confirmer :

• les systèmes de gestion du temps, de paie ou ERP actuellement pris en charge ;

• méthodes d'intégration disponibles : API, SFTP, modèle de fichier ou autre méthode ;

• cycle de synchronisation et engagements de service réels ;

• liste des points de terminaison, champs de données, statuts et codes d'erreur pouvant être publiés ;

• mécanismes d'authentification, d'idempotence, de webhook et de réconciliation utilisés ;

• flux de traitement des transactions à résultat incertain, échouées et remboursées ;

• règles de calcul des limites et éléments de paie éligibles ;

• modèle de rapport technique sans données personnelles ;

• responsabilités de Nhan Kiet, de l'entreprise et du partenaire de paiement ;

• point de contact pour la documentation d'intégration et le support UAT.

Ne pas publier le nom des partenaires, le temps de traitement, le SLA ou les fonctionnalités techniques sans confirmation par documentation.

-->

Foire aux questions

L'accès au salaire déjà gagné doit-il obligatoirement être intégré en temps réel ?

Non. Une entreprise peut utiliser une API en temps quasi réel, un fichier batch selon un calendrier ou un processus manuel contrôlé lors du pilote. La fréquence doit être adaptée à la méthode de calcul des limites, à la vitesse de changement des données et à la capacité opérationnelle des systèmes sources.

Les seules données de gestion du temps suffisent-elles pour calculer la limite de l'accès au salaire déjà gagné ?

En général, ce n'est pas suffisant. Il faut également le statut des employés, les périodes de paie, les règles de calcul des salaires, les ajustements pertinents et l'historique des transactions EWA. Les heures enregistrées doivent également avoir un statut d'approbation clair.

Pourquoi utiliser le même identifiant d'employé ?

Un identifiant unique aide à éviter d'attribuer les heures, salaires ou transactions d'une personne à une autre. Si les systèmes utilisent actuellement des codes différents, l'entreprise doit avoir un tableau de correspondance contrôlé et une date d'effet.

L'idempotence est-elle la même chose que la vérification des transactions en double ?

Elles sont liées mais pas complètement identiques. L'idempotence garantit que l'envoi répété de la même demande ne crée pas un nouveau résultat métier. La vérification des doublons peut également utiliser d'autres clés métier pour détecter deux demandes avec des codes différents mais qui sont en réalité une seule transaction.

Lorsque la commande de transfert d'argent expire, faut-il la renvoyer immédiatement ?

Il ne faut pas envoyer une nouvelle commande de paiement tant que le résultat de l'ancienne n'est pas déterminé. Le système doit conserver le statut incertain, interroger selon le code de référence et ne traiter que selon le processus défini pour éviter un double paiement.

Qui est responsable de la réconciliation de l'accès au salaire déjà gagné ?

La responsabilité doit être définie dans la matrice opérationnelle. En général, elle implique l'unité opérationnelle de l'EWA, la paie, la comptabilité/finance, l'IT et le partenaire de paiement. Chaque type d'écart doit avoir un propriétaire spécifique.

Conclusion

L'intégration de l'accès au salaire déjà gagné ne consiste pas simplement à extraire un fichier de gestion du temps puis à calculer un pourcentage. Un système fiable nécessite des données d'employés, des heures approuvées, des règles de paie et des transactions liées par un identifiant unique ; ainsi que des versions de données, l'idempotence, le statut de paiement, la réconciliation et un processus de gestion des erreurs.

Si votre entreprise évalue la possibilité de connecter l'accès au salaire déjà gagné avec votre système de gestion du temps, de paie ou ERP existant, préparez un schéma système, un dictionnaire de données masqué des données personnelles et les scénarios métier à prendre en charge, puis explorez l'accès au salaire déjà gagné pour les entreprises pour discuter de la documentation d'intégration technique et de l'étendue du pilote approprié.

Sources

• OpenAPI Initiative – OpenAPI Specification

• OpenAPI Specification sur GitHub

• Loi sur la protection des données personnelles n° 91/2025/QH15

• Décret 356/2025/NĐ-CP guidant la Loi sur la protection des données personnelles

• Loi sur les transactions électroniques n° 20/2023/QH15

---

Auteur : Ngô Nhã Kỳ— Éditeur , Nhan Kiet Manpower Supply Co., Ltd.

Conseil en solutions d'accès au salaire déjà gagné pour les entreprises : Hotline 0937.022.655 · Email info@nhankiet.vn · Accès au salaire déjà gagné pour les entreprises