Peso y dólar en la misma base de datos sin descuadres

Resumen:

• Cada importe necesita moneda y tipo de cambio aplicado, guardados junto al valor.
• Las diferencias cambiarias son un resultado, no un error: hay que identificarlas.
• Redondear dos veces en momentos distintos es el origen de casi todos los descuadres pequeños.
• Cambiar el modelo de moneda en producción es de las migraciones más caras que existen.

Una comercializadora de Tijuana compraba en dólares, vendía en ambas monedas y llevaba la contabilidad en pesos. Su sistema guardaba todos los importes convertidos a pesos al tipo de cambio del día.

Funcionaba en el día a día. Fallaba en el cierre: los saldos de clientes en dólares no coincidían con lo que esos clientes decían deber, y cada mes alguien dedicaba dos días a reconciliar.

El origen del problema

Cuando una factura de mil dólares se guarda como su equivalente en pesos, la factura pierde su naturaleza. Si el cliente paga tres meses después con otro tipo de cambio, el pago en pesos no coincide con el saldo en pesos, y el sistema muestra una diferencia que parece un error de captura.

No es un error. Es una diferencia cambiaria, que es un concepto contable legítimo. Pero un sistema que no distingue entre «esto es una diferencia cambiaria» y «esto está mal capturado» convierte cada cierre en una investigación.

El modelo correcto

Tres datos por cada importe, en lugar de uno.

Con esos tres, cualquier reporte se puede generar en cualquier moneda y siempre da el mismo resultado, que es la propiedad que hacía falta.

Qué tipo de cambio usar y cuándo

Esta es la parte que hay que decidir con quien lleva la contabilidad, no con el equipo técnico.

• Al registrar una operación: el tipo del día de la operación.
• Al valorar saldos para el cierre: el tipo de cierre del periodo.
• Cuando el contrato fija uno: el pactado, que prevalece sobre cualquier otro.
• Para reportes de gestión comparables: un tipo presupuestado fijo durante todo el año, para que las variaciones reflejen operación y no fluctuación.

Ese último punto sorprende a los equipos técnicos y es habitual en dirección financiera: para comparar el desempeño de dos meses conviene neutralizar el efecto cambiario.

El redondeo

Casi todos los descuadres de céntimos vienen del mismo sitio: convertir y redondear en dos momentos distintos del proceso.

La regla que aplicamos es una sola: la conversión ocurre en un único punto del código, el resultado redondeado se guarda, y a partir de ahí nadie vuelve a calcular. Cualquier pantalla que necesite el importe convertido lo lee, no lo recalcula.

Suena excesivo para unos céntimos. Esos céntimos, multiplicados por miles de líneas, son lo que impide que un balance cuadre.

Preguntas frecuentes

¿Qué tipo de cambio hay que usar?

Depende del uso y hay que declarar cuál se aplica en cada caso: el de la fecha de la operación para registrar, el de cierre para valorar saldos, y el pactado si el contrato fija uno. Lo que no funciona es usar el que esté disponible en el momento del cálculo.

¿Dónde aparecen las diferencias cambiarias?

Entre el momento en que se registra una operación y el momento en que se cobra o se paga. Si el tipo de cambio se movió, hay una diferencia que es un resultado contable, no un error, y el sistema tiene que poder identificarla como tal.

¿Cómo se maneja el redondeo?

Con una regla única aplicada en un solo punto del código, y con el importe redondeado guardado, no recalculado. La mayoría de los descuadres pequeños vienen de redondear dos veces en momentos distintos.

¿El cliente debe ver precios en su moneda?

Es lo deseable comercialmente y obliga a decidir si el precio en la otra moneda es fijo o se convierte. Un precio convertido cambia cada día y confunde; un precio fijo por moneda protege el margen y exige revisarlo periódicamente.

¿Se puede cambiar el modelo de moneda una vez en producción?

Se puede y es caro. Implica migrar cada tabla con importes, recalcular históricos con información que a veces ya no existe y revalidar todos los reportes. Es de las decisiones que más conviene acertar al principio.

La migración del histórico

La parte incómoda de este proyecto fue el pasado. Cuatro años de operaciones guardadas solo en pesos, sin el importe original ni el tipo aplicado.

Para las facturas se pudo recuperar el dato desde los documentos emitidos. Para los movimientos internos no había forma: la información original no existía en ninguna parte.

La decisión fue no inventarla. Se marcó todo el histórico anterior a la migración como «moneda única, tipo no disponible» y se aceptó que los reportes multi-moneda solo aplican desde la fecha de corte.

Es menos satisfactorio que un histórico completo y es honesto, que en información contable importa más.

Cómo se prueba que el modelo está bien

Hay una prueba sencilla que revela casi cualquier defecto en el manejo de doble moneda.

Se toma una operación completa —factura en dólares, cobro parcial en pesos, cobro final en dólares meses después— y se pide al sistema el reporte de esa operación en las dos monedas, a fecha de hoy y a fecha del cierre del mes en que ocurrió.

Los cuatro resultados deben ser explicables y reproducibles. Si alguno cambia al volver a ejecutarlo, o si la diferencia entre dos de ellos no se puede atribuir a un concepto concreto, hay un defecto en el modelo.

El error de usar el tipo de cambio del sistema operativo

Un detalle técnico con consecuencias contables: el tipo de cambio no debe tomarse de una consulta en línea en el momento del cálculo.

Debe existir una tabla de tipos por fecha, cargada de forma controlada, con la fuente y la hora de obtención registradas. Consultar un servicio externo cada vez produce resultados irreproducibles y depende de que ese servicio esté disponible en el momento de cerrar el mes.