5. Coherencia de unidades, dominio y datos necesarios

Un cálculo solo es confiable cuando sus datos son completos, válidos y compatibles con el modelo financiero elegido.

5.1 Una cuenta correcta puede responder mal

Una calculadora puede ejecutar cada operación aritmética sin errores y aun así producir una respuesta financieramente incorrecta. Esto ocurre cuando recibe una tasa en una escala distinta de la esperada, mezcla meses con días, omite el régimen o combina capitales expresados en monedas diferentes.

Antes de aplicar una fórmula debemos verificar qué representa cada dato. La validación financiera no consiste solamente en comprobar que una entrada sea numérica.

Idea central: validar significa comprobar tres niveles: que no falten datos, que cada valor pertenezca al dominio permitido y que todos los datos sean coherentes entre sí.

5.2 Completitud, validez y coherencia

1

Completitud

Están presentes el capital, la tasa, las fechas, el período, la moneda y el régimen necesarios.

2

Validez

Cada dato tiene el tipo, formato y rango admitidos por el modelo.

3

Coherencia

Las unidades, fechas, escalas y convenciones pueden utilizarse conjuntamente.

Una tasa de 5 % puede ser numéricamente válida, pero el conjunto de datos está incompleto si no conocemos su período. Dos capitales positivos pueden ser válidos por separado, pero resultan incompatibles para una resta directa si uno está expresado en pesos y otro en dólares.

5.3 Datos mínimos de una operación

El conjunto necesario depende de la pregunta, pero una operación elemental entre dos fechas suele requerir:

  • Capital: importe y moneda.
  • Posición temporal: fecha inicial, fecha final o duración total.
  • Tasa: valor, escala de entrada y período al que corresponde.
  • Régimen: regla que determina cómo cambia el capital a través del tiempo.
  • Convención temporal: forma de medir períodos y fracciones.
  • Dirección del cálculo: capitalizar hacia el futuro o actualizar hacia el pasado.

También puede ser necesario conocer reglas de redondeo, tratamiento de períodos incompletos y procedencia de los datos. Si una decisión modifica el resultado, no debería permanecer implícita.

5.4 Coherencia de escala

Una interfaz suele recibir porcentajes porque son fáciles de leer, mientras que las fórmulas esperan tantos por uno. La conversión debe realizarse exactamente una vez:

entrada del usuario: 3 %
valor normalizado: 3 / 100 = 0,03
factor del período: 1 + 0,03 = 1,03

Si la aplicación interpreta el número 3 como tasa decimal, utilizará 300 %. Si lo divide dos veces por 100, utilizará 0,03 %. Conviene identificar la escala en el nombre del campo o conservarla como metadato.

5.5 Coherencia temporal

La duración de la operación y el período de la tasa deben expresarse sobre una base compatible. Si la operación dura 90 días y la tasa corresponde a períodos de 30 días, podemos obtener:

n = 90 días / 30 días por período = 3 períodos

En cambio, una duración de tres meses calendario no puede tratarse automáticamente como 90 días. La aplicación debe saber si trabaja con fechas reales, meses calendario o períodos convencionales de duración fija.

Una cantidad fraccionaria de períodos tampoco es inválida por sí misma. Por ejemplo, 75 días contienen 2,5 períodos de 30 días. Lo que puede faltar es la regla que indique cómo tratar esa fracción.

5.6 Dominio matemático y dominio financiero

El dominio matemático describe los valores para los cuales una expresión puede calcularse. El dominio financiero agrega las restricciones necesarias para que el resultado tenga sentido dentro del modelo.

Restricciones habituales en un modelo elemental de capitales positivos.
DatoCondiciónMotivo
Capital inicialFinito y mayor que ceroActúa como importe de referencia y puede aparecer como divisor.
Tasa del períodoFinita y mayor que −100 %El factor 1 + i debe permanecer positivo.
DuraciónFinita y no negativaLa fecha final no precede a la inicial en el recorrido planteado.
Duración del períodoFinita y mayor que ceroNo se puede dividir por un período nulo.
MonedaDefinida y compatibleLos importes no se combinan directamente entre monedas distintas.

Estas condiciones pertenecen al modelo utilizado en el curso. Otros problemas pueden admitir flujos con signo, pero deben diferenciarse de las magnitudes positivas empleadas como base de una tasa.

5.7 Magnitudes y flujos con signo

En una línea de tiempo, un cobro puede representarse con signo positivo y un pago con signo negativo. Esa convención ayuda a construir ecuaciones de valor, pero no convierte un capital inicial negativo en una base válida para calcular una tasa relativa.

  • Magnitud del capital: importe no negativo utilizado para medir crecimiento o disminución.
  • Signo del flujo: indica si el dinero entra o sale desde el punto de vista elegido.

Separar ambos conceptos evita validaciones contradictorias. Un pago puede almacenarse como flujo -100000, mientras su magnitud es 100000.

5.8 Orden recomendado de validación

01Comprobar presencia y tipos
02Normalizar escalas y unidades
03Validar rangos y relaciones
04Aplicar el modelo financiero

Normalizar no significa corregir silenciosamente cualquier entrada. La cadena "3" puede convertirse deliberadamente a número, pero una tasa sin período no debería recibir uno por defecto si esa decisión cambia el significado.

5.9 Representar una operación con JavaScript

Un objeto explícito conserva el valor junto con su contexto:

const operacion = {
  capital: {
    importe: 100000,
    moneda: "ARS"
  },
  plazo: {
    duracion: 90,
    unidad: "dia"
  },
  tasa: {
    valor: 3,
    escala: "porcentaje",
    periodo: 30,
    unidadPeriodo: "dia"
  },
  regimen: "compuesto",
  direccion: "capitalizar"
};

const tasaDecimal = operacion.tasa.valor / 100;
const cantidadPeriodos =
  operacion.plazo.duracion / operacion.tasa.periodo;

console.log({ tasaDecimal, cantidadPeriodos });

El objeto no intenta resolver todavía la operación. Primero hace visibles las decisiones que una función de cálculo necesitará.

5.10 Laboratorio: auditar los datos

Modificá las entradas para comprobar su dominio y coherencia. El laboratorio normaliza la tasa y mide el plazo, pero no calcula el monto.

Validador previo al cálculo

Todos los períodos de este ejemplo tienen una duración fija en días.

Tasa normalizada0,030000
Cantidad de períodos3,0000
Factor de un período1,030000

Datos completos y coherentes para una operación en ARS bajo régimen compuesto.

Interpretación: si el régimen queda sin especificar, los datos permiten medir el plazo, pero no elegir una fórmula para obtener el capital final.

5.11 Validar sin perder información

Una función puede devolver errores que impiden calcular y advertencias que requieren una decisión adicional:

function auditarOperacion(datos) {
  const errores = [];
  const advertencias = [];

  if (!Number.isFinite(datos.capital) || datos.capital <= 0) {
    errores.push("El capital debe ser mayor que cero");
  }
  if (!Number.isFinite(datos.tasaPorcentual) ||
      datos.tasaPorcentual <= -100) {
    errores.push("La tasa debe ser mayor que -100 %");
  }
  if (!Number.isFinite(datos.diasOperacion) ||
      datos.diasOperacion < 0) {
    errores.push("La duración no puede ser negativa");
  }
  if (!Number.isFinite(datos.diasPeriodo) ||
      datos.diasPeriodo <= 0) {
    errores.push("El período debe ser mayor que cero");
  }
  if (!datos.moneda) errores.push("Falta la moneda");
  if (!datos.regimen) advertencias.push("Falta indicar el régimen");

  return {
    esValida: errores.length === 0,
    errores,
    advertencias
  };
}

console.log(auditarOperacion({
  capital: 100000,
  tasaPorcentual: 3,
  diasOperacion: 90,
  diasPeriodo: 30,
  moneda: "ARS",
  regimen: "compuesto"
}));

Una advertencia no equivale a inventar el dato faltante. Permite explicar por qué ciertas partes del análisis pueden continuar y otras deben esperar.

5.12 Errores frecuentes

  • Validar solo con typeof: NaN tiene tipo number; conviene usar Number.isFinite.
  • Asignar valores predeterminados ocultos: completar moneda, período o régimen sin informarlo puede alterar el resultado.
  • Confundir ausencia con cero: una tasa cero es un dato válido; una tasa no ingresada es un dato faltante.
  • Mezclar porcentaje y tanto por uno: la escala debe conocerse antes de normalizar.
  • Rechazar todo período fraccionario: primero debe consultarse la regla del modelo o del acuerdo.
  • Mostrar un resultado sin sus unidades: capital, tasa y plazo deben conservar moneda, período y convención.

5.13 Ejercicio propuesto

Se recibe la siguiente descripción: “Capital de $200.000 ARS, tasa de 4,5 % cada 30 días, plazo de 75 días, régimen compuesto”.

  1. Identificá el capital, la moneda, la tasa, su escala, su período, el plazo y el régimen.
  2. Normalizá la tasa como tanto por uno.
  3. Calculá la cantidad de períodos.
  4. Indicá qué decisión adicional podría ser necesaria.
  5. Representá los datos mediante un objeto JavaScript.
Ver solución

La tasa normalizada es 0,045 y el plazo contiene 2,5 períodos. Los datos principales están presentes, pero conviene confirmar cómo debe tratarse el medio período antes de calcular un monto.

i = 4,5 / 100 = 0,045
n = 75 días / 30 días por período = 2,5 períodos
const datos = {
  capital: 200000,
  moneda: "ARS",
  tasa: {
    valor: 0.045,
    escala: "tantoPorUno",
    diasPorPeriodo: 30
  },
  diasOperacion: 75,
  regimen: "compuesto",
  tratamientoFraccion: null
};

const periodos = datos.diasOperacion / datos.tasa.diasPorPeriodo;

console.log({ periodos, requiereDefinirFraccion: !Number.isInteger(periodos) });

5.14 Ideas para recordar

  • Una operación debe superar controles de completitud, validez y coherencia.
  • La tasa necesita valor, escala, período y régimen.
  • El capital necesita importe, moneda y posición temporal.
  • Las unidades se normalizan antes de aplicar la fórmula.
  • El dominio financiero puede ser más restrictivo que el matemático.
  • Los errores impiden calcular; las advertencias señalan decisiones pendientes.

En el próximo tema estudiaremos la tasa en interés simple y su proporcionalidad con el tiempo, aplicando estas validaciones a un régimen concreto.