Salario moneda período: cómo indicarlo

Un dato de salario moneda período es la única forma de que una retribución sea interpretable: la cifra aislada no dice nada. Anotar una cantidad sin decir en qué unidad monetaria está expresada y a qué tramo de tiempo corresponde equivale a escribir un número sin unidad, y cualquier comparación que se construya sobre él será errónea. Este artículo repasa por qué el periodo y la moneda son parte del dato, en qué se diferencian el paquete total y el salario base y qué información necesita una conversión para poder auditarse después.

¿Por qué hay que indicar la moneda y el periodo?

Porque una retribución se define por tres elementos y no por uno. El importe es la magnitud, la moneda es la unidad y el periodo es el tramo de tiempo al que esa magnitud corresponde. Suprimir cualquiera de los tres deja el dato incompleto.

El periodo es el que se omite con más frecuencia, y es el que produce los errores más grandes. Una misma cantidad puede referirse a un año de trabajo, a un mes o a una jornada, y las diferencias entre esas lecturas son de órdenes de magnitud distintos. Cuando el periodo no consta, el sistema no puede comparar dos ofertas, no puede calcular totales y no puede mostrar una cifra en la unidad que la persona espera.

La moneda cumple una función parecida. Sin ella, el importe es un número huérfano: no se puede convertir, no se puede sumar con otros y no se puede presentar con el formato correcto. Y hay una razón adicional para exigirla: en un sistema que maneja perfiles de varios países, la misma cifra sin unidad puede proceder de contextos completamente distintos.

La conclusión de diseño es que los tres elementos formen una sola estructura. Un importe que pueda guardarse sin moneda o sin periodo acabará guardándose así, y el problema aparecerá más tarde, cuando ya haya datos que no se pueden reparar.

¿En qué se diferencian el paquete total y el salario base?

En que no miden lo mismo. El salario base es la cantidad fija comprometida por el puesto, sin componentes variables. El paquete total es la suma estimada de todo lo que la persona recibe: base, complementos, retribución variable, dietas y, en algunos casos, componentes diferidos o en especie.

La diferencia entre ambos no es de precisión, sino de definición. Un sistema que guarda un único campo llamado retribución obliga a quien lo rellena a elegir cuál de los dos está anotando, sin decirlo. Después, cualquier informe que sume esos valores estará mezclando magnitudes que no son comparables.

Hay tres consecuencias que conviene anticipar. La primera es que el componente variable suele depender de condiciones que se cumplen o no, de modo que el paquete total es una estimación y no un hecho. La segunda es que el paquete total suele incluir elementos que no se perciben de forma periódica, lo que complica cualquier comparación con una cifra mensual. La tercera es que, sin declarar qué se está anotando, el mismo campo puede contener respuestas a preguntas distintas según quién lo haya rellenado.

La práctica razonable es tener campos separados para cada componente que interese y un campo adicional que declare explícitamente de qué cifra se trata. La etiqueta es tan importante como el número.

Por qué conviene usar el código de moneda y no el símbolo

Porque los símbolos son ambiguos. El mismo signo se usa para designar unidades monetarias diferentes en distintos territorios, y quien lee no tiene forma de saber a cuál se refiere salvo por el contexto. En una pantalla que muestra perfiles de varios países, ese contexto se pierde.

Los códigos normalizados de tres letras resuelven el problema porque identifican una unidad monetaria concreta sin ambigüedad. Son estables, se escriben igual en todas partes y no dependen de la configuración regional de quien consulta el sistema.

Lo ideal es guardar el código y usar el símbolo solo en la presentación, cuando el contexto ya es conocido. Así el dato conserva su precisión y la interfaz conserva su comodidad.

Qué tiene que registrar una conversión

Una conversión entre monedas no es un cálculo único, sino el resultado de aplicar un tipo de cambio que corresponde a un momento determinado. Como esos tipos varían continuamente, el resultado de la operación depende de cuándo se hizo.

Eso obliga a que cualquier conversión almacenada conserve al menos tres cosas: la moneda de origen, la moneda de destino y la fecha a la que correspondía el tipo aplicado. Sin la fecha, el valor convertido no se puede reproducir ni explicar, y con el tiempo se convierte en una cifra que nadie sabe de dónde salió.

Hay una tentación frecuente que conviene evitar: guardar solo el resultado convertido y descartar el valor original. Cuando eso ocurre, se pierde la información primaria y, con ella, la posibilidad de rehacer la operación con un criterio distinto. La conversión es un dato derivado y debe poder recalcularse siempre a partir del original.

También conviene decidir de antemano qué se hace con las diferencias de redondeo. Una cifra convertida y vuelta a convertir no tiene por qué coincidir con la inicial, y un sistema que exige esa coincidencia produce errores que parecen de cálculo y son de expectativa.

El límite de privacidad de este campo

La retribución es uno de los datos más sensibles de un perfil profesional. Revela el nivel jerárquico, la antigüedad aproximada y la valoración que una organización hace de una persona, y por eso muchas legislaciones y muchas prácticas internas le dan un tratamiento aparte.

Desde el punto de vista del diseño, la consecuencia es que la retribución debería ser un campo opcional y con controles de visibilidad propios. No todo el mundo que puede ver un perfil debería poder ver su retribución, y esa distinción no puede depender de la pantalla desde la que se consulte.

Existe además una razón práctica para no usar cifras reales en entornos de prueba: una retribución auténtica identifica a la persona que la percibe con bastante precisión cuando se combina con el puesto y la organización. El material de prueba debería llevar importes que se reconozcan como ejemplos desde el primer vistazo.

En el generador de este sitio

El generador de currículums y datos de empleo falsos incorpora la retribución como campo opcional, siempre acompañada de su moneda y de su periodo, de modo que los datos de ejemplo nunca aparecen como una cifra suelta. El perfil puede generarse también sin retribución, que es el caso que conviene probar cuando el sistema trata el campo como reservado.

Todo lo que produce es material sintético para pruebas de software, demostraciones y carga de entornos. Los importes son valores de ejemplo y no corresponden a la retribución de nadie.

Si el problema que tienes delante es cómo se rellena este campo en una solicitud, la guía sobre casos de prueba de formularios de selección trata el flujo completo de la solicitud. Y para la estructura general del perfil, el artículo sobre datos de currículum para pruebas describe el resto de los campos.

Para quien programa

• Guarda el importe, la moneda y el periodo como una unidad. Si el modelo permite un importe sin moneda o sin periodo, ese estado acabará existiendo en producción. Un tipo que exige los tres valores desde el principio evita la mayor parte de los problemas posteriores.
• Usa un tipo decimal con precisión declarada. Los números en coma flotante introducen diferencias que aparecen al sumar muchas cifras. La escala de la magnitud retributiva es limitada y se puede fijar de antemano.
• Separa el componente fijo del variable. Son magnitudes distintas y con condiciones distintas. Un campo único obliga a mezclarlas y hace que los informes agregados pierdan sentido.
• Conserva el valor original de una conversión. El resultado convertido es un dato derivado; el importe original, con su moneda y su periodo, es el dato. Descartar el segundo para quedarse con el primero destruye la trazabilidad.
• Declara la fecha del tipo aplicado. Sin ella la conversión no se puede reproducir, y con el tiempo se convierte en una cifra sin explicación. La fecha es parte del dato, no un detalle del proceso.

Un recordatorio de proceso: documenta en qué unidad se muestran las cifras en cada pantalla. La diferencia entre un importe anual y uno mensual pasa desapercibida con mucha facilidad, y es la fuente más común de malentendidos en este campo.

Siguientes pasos

Si vas a probar pantallas que muestran retribuciones, prepara perfiles con varias monedas y varios periodos, además de alguno sin retribución declarada, y comprueba qué ocurre al ordenar y al sumar. El generador de perfiles profesionales te da esos conjuntos sin usar información de personas reales.

Para un problema de la misma clase, el artículo sobre los desajustes entre direcciones y códigos postales describe cómo se comportan los sistemas cuando un valor se interpreta sin una parte del contexto que le da sentido, algo que aquí sucede cada vez que un importe aparece sin su periodo.

Y una precisión que conviene mantener presente: las cantidades, monedas y periodos que se ven en los ejemplos son valores de demostración. Son datos sintéticos para pruebas y carga de formularios, no la retribución real de ninguna persona.