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
Completitud
Están presentes el capital, la tasa, las fechas, el período, la moneda y el régimen necesarios.
Validez
Cada dato tiene el tipo, formato y rango admitidos por el modelo.
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:
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:
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.
| Dato | Condición | Motivo |
|---|---|---|
| Capital inicial | Finito y mayor que cero | Actúa como importe de referencia y puede aparecer como divisor. |
| Tasa del período | Finita y mayor que −100 % | El factor 1 + i debe permanecer positivo. |
| Duración | Finita y no negativa | La fecha final no precede a la inicial en el recorrido planteado. |
| Duración del período | Finita y mayor que cero | No se puede dividir por un período nulo. |
| Moneda | Definida y compatible | Los 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
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.
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:NaNtiene tiponumber; conviene usarNumber.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”.
- Identificá el capital, la moneda, la tasa, su escala, su período, el plazo y el régimen.
- Normalizá la tasa como tanto por uno.
- Calculá la cantidad de períodos.
- Indicá qué decisión adicional podría ser necesaria.
- 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.
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.