La devise et la période de salaire constituent la plus petite unité d’un dossier de rémunération, et elle est presque toujours enregistrée de façon incomplète. Un nombre est écrit, la devise est laissée au contexte, et la période est supposée être ce que le lecteur attend.
Chacune de ces omissions est invisible au point de saisie et coûteuse plus tard. Cet article couvre pourquoi le montant seul n’a pas de sens, ce qu’est réellement la différence entre un package total et un montant de base, pourquoi la devise devrait être stockée comme un code plutôt qu’un symbole, et ce qu’une conversion doit enregistrer pour être honnête.
Pourquoi un nombre sans devise ni période est-il inutile ?
Parce qu’il peut être lu de plus de manières qu’il ne peut être écrit. Un chiffre de cinquante peut signifier un montant mensuel dans une devise, un montant annuel dans une autre et un taux journalier dans une troisième, et les trois lectures sont cohérentes avec les données telles qu’elles sont stockées.
La période est la partie la plus souvent abandonnée, parce que le contexte la fournit silencieusement. La rémunération se discute annuellement sur certains marchés, mensuellement sur d’autres et horairement sur d’autres encore, et chacune de ces conventions se présuppose elle-même. Quand un dossier sort du contexte dans lequel il a été écrit — vers une comparaison, un filtre, un export — l’hypothèse le suit et n’est jamais remise en question.
Les deux moitiés échouent différemment. Une devise manquante rend le montant ininterprétable. Une période manquante le rend mal échelonné, et un montant mal échelonné est plus dangereux qu’un montant absent parce qu’il ressemble à un vrai chiffre et se trie au mauvais endroit. Un filtre qui traite un taux mensuel comme annuel exclura exactement les candidats qu’il était censé inclure, et il signalera un résultat plausible ce faisant.
Quelle est la différence entre le package total et le salaire de base ?
Ce sont des quantités différentes qui partagent un nom dans le langage courant.
Le salaire de base est le montant fixe échangé contre le travail, avant toute variable. Un package total est le salaire de base plus tout ce que l’arrangement inclut par ailleurs : composantes variables, indemnités, cotisations versées pour le compte du titulaire et avantages dont la valeur est réelle mais non monétaire. Les deux chiffres peuvent différer sensiblement, et la différence est une caractéristique de l’arrangement plutôt qu’une erreur.
L’ambiguïté compte parce que le même mot est utilisé pour les deux. Quand quelqu’un dit ce qu’il gagne, il peut citer l’un ou l’autre, et il peut ne pas savoir lequel. Un dossier qui stocke un seul montant sous une étiquette nue ne peut donc pas dire lequel des deux il représente, et une comparaison construite dessus compare deux quantités différentes sans le savoir.
Le correctif n’est pas de choisir une convention et de l’appliquer partout, car aucune n’est plus correcte. Il est d’étiqueter quelle quantité est enregistrée, et, là où un total est donné, de dire ce qu’il inclut. Une ventilation est plus utile qu’un nombre unique, et les composantes d’un package ne sont souvent pas additives de la manière qu’un lecteur supposera — certaines sont conditionnelles, d’autres plafonnées, et d’autres dépendent de facteurs entièrement extérieurs à l’arrangement.
Pourquoi utiliser un code de devise plutôt qu’un symbole ?
Parce que les symboles sont ambigus et que les codes ne le sont pas.
L’ambiguïté est bien connue et facile à sous-estimer. Le même symbole est utilisé par plusieurs devises, et un lecteur le résout grâce à un contexte que le dossier lui-même ne porte pas. Un symbole peut aussi avoir des significations conventionnelles différentes selon les régions, si bien que le même glyphe signale des choses différentes à deux lecteurs du même document. Et le symbole ne distingue généralement pas la devise en tant qu’unité de compte d’une variante locale de celle-ci, ce qui peut compter.
Un code identifie exactement une devise et le fait sans contexte. Stocker le code à côté de la forme d’affichage donne au lecteur le glyphe familier et donne au système quelque chose d’non ambigu avec quoi calculer et comparer. Là où la source a écrit un symbole, le dossier devrait le résoudre en un code au point de saisie, pendant que le contexte environnant est encore disponible pour rendre la résolution correcte — plus tard, ce contexte a disparu.
Il y a une distinction supplémentaire qu’il vaut la peine de préserver là où la source la fait : si le montant est la devise telle qu’écrite ou un équivalent converti. Ce sont des affirmations différentes, et les fusionner détruit la capacité de distinguer un chiffre cité d’un chiffre calculé.
Comment enregistrer une conversion ?
Avec la date à laquelle elle a été faite, la source du taux, et le chiffre d’origine conservé à côté du chiffre converti.
Une conversion est une opération, pas un fait sur le monde. Elle a pris deux montants qui étaient égaux à un moment précis et appliqué un taux qui existait à un moment précis. Sans le moment, le chiffre converti ne peut pas être recalculé, vérifié ni inversé. Sans la source du taux, un relecteur ne peut pas dire si une différence entre deux chiffres est une différence réelle ou une différence entre deux fournisseurs de taux.
Trois règles en découlent. Enregistrez la date à laquelle le taux s’appliquait, et non la date à laquelle la conversion a été effectuée. Conservez le montant et la devise d’origine dans le dossier même après conversion, car une conversion ne préserve jamais l’information. Et ne convertissez jamais pour le stockage en remplacement du stockage de la devise — la conversion sert à la comparaison, et un dossier qui ne conserve que la valeur convertie a jeté la chose même qu’il comparait.
Quiconque construit des fonctions de comparaison devrait aussi décider ce que signifie une comparaison. Comparer des montants convertis est une commodité assortie d’une marge d’erreur, et la traiter comme exacte produira des différences qui sont des artefacts du taux plutôt que de la rémunération.
Les informations de rémunération font-elles partie obligatoire d’un dossier ?
Elles ne devraient pas l’être. Dans la plupart des systèmes, la rémunération est facultative, et dans beaucoup elle est assez sensible pour que la traiter comme facultative soit une exigence plutôt qu’une préférence.
Il y a de bonnes raisons de la tenir à l’écart de tout flux de travail qui n’en a pas besoin. La rémunération est souvent le champ le plus sensible d’un dossier de carrière, c’est le champ le plus susceptible d’être omis délibérément, et un système qui l’exige collectera des valeurs inexactes plutôt que complètes. Exiger un champ que les gens refusent de remplir produit régulièrement des données de substitution, et des données de substitution dans un champ de rémunération sont pires qu’un champ vide parce qu’elles sont indiscernables d’une vraie réponse.
La conception pratique consiste à garder le champ facultatif, à le garder étiqueté avec ses deux moitiés de sens, et à garder petit le nombre d’endroits où il est affiché. Là où la rémunération est affichée, elle devrait l’être avec sa devise, sa période et, là où elle a été convertie, le fait qu’elle l’a été.
Pour les développeurs : champs de rémunération et valeurs par défaut sûres
Stockez le montant, le code de devise et la période comme trois champs sans valeur par défaut pour aucun d’eux. Une devise par défaut est pire que pas de devise, car elle est silencieusement correcte assez souvent pour qu’on lui fasse confiance et fausse exactement quand cela compte.
Quatre détails évitent la plupart des erreurs en aval. Faites de la période un ensemble énuméré de valeurs plutôt que du texte libre, puisqu’une période qui peut s’écrire de six manières ne peut pas être comparée à elle-même. Gardez l’étiquette qui distingue un montant de base d’un package total, et refusez d’accepter un total sans savoir ce qu’il contient. Gardez les montants d’origine et converti séparés, avec les métadonnées du taux attachées à la conversion plutôt qu’au montant. Et traitez tout le groupe comme facultatif, afin qu’un dossier sans information de rémunération soit un dossier complet.
Pour les données de test, les cas qui valent la peine d’être générés sont ceux qui attrapent une comparaison négligente : le même montant dans deux devises, un chiffre mensuel à côté d’un chiffre annuel, une valeur convertie dont l’original a été conservé, et un dossier où la section paie est totalement absente.
Les cas qui valent la peine d’être générés pour les données de test :
- le même montant dans deux devises
- un chiffre mensuel à côté d’un chiffre annuel
- une valeur convertie dont l’original a été conservé
- un dossier où la section paie est totalement absente Tous les montants, devises et périodes apparaissant dans les dossiers d’exemple sur ce site sont des valeurs de démonstration choisies pour exercer ces cas, et ils ne décrivent aucun arrangement réel.
Étapes suivantes
Auditez une comparaison dans votre produit et comptez combien des montants qu’elle compare ont à la fois un code de devise et une période enregistrés. Le nombre est habituellement plus bas que prévu. Les branches de formulaire où un champ de rémunération apparaît sont couvertes dans les cas de test de formulaire de recrutement, et la question plus large de la manière dont un dossier de carrière est assemblé est exposée dans les données de test de profil de carrière. L’outil de profil de carrière génère des dossiers dont les champs de rémunération peuvent être laissés vides, ce qui est le cas que la plupart des systèmes ne testent jamais.