

Redondear es reemplazar un número por otro más corto que se le parece lo suficiente.
Se hace porque los decimales largos resultan incómodos de leer, de comunicar y de pagar.
El punto que casi siempre se pasa por alto es que redondear altera la cantidad, aunque sea por poco.
Esa alteración es aceptable cuando ocurre una vez, y deja de serlo cuando se repite cientos de veces.
Hay cuatro formas habituales de decidir a qué número se va, y conviene distinguirlas bien.
El error frecuente consiste en llamar por defecto y por exceso a las dos ramas del redondeo simétrico, cuando en realidad son criterios distintos entre sí.
Tomando 17,345 y llevándolo a dos decimales, el simétrico da 17,35 y el redondeo al par da 17,34.
El redondeo por exceso da 17,35 y el redondeo por defecto da 17,34, sin importar cuál sea el tercer decimal.
Con 17,341 los criterios se separan: simétrico y al par dan 17,34, el de exceso da 17,35 y el de defecto da 17,34.
El problema no es redondear, sino redondear muchas veces seguidas.
Si cada línea de una factura se redondea antes de sumar, el total puede diferir del que sale de sumar primero y redondear al final.
Esa diferencia de uno o dos centavos es la causa típica de que un comprobante no cierre contra su propio detalle.
La regla práctica es clara: calcular con toda la precisión disponible y redondear lo más tarde posible.
Un impuesto calculado sobre una base ya redondeada da distinto que el mismo impuesto calculado sobre la base exacta.
Por eso muchas normativas fijan en qué momento exacto se redondea y con cuántos decimales, y esas reglas cambian de un país a otro.
Cuando el importe del impuesto se declara período tras período, el criterio elegido tiene que mantenerse siempre igual.
En los países donde desaparecieron las monedas chicas, el pago en efectivo se ajusta a la denominación mínima disponible.
Eso no cambia el importe de la factura, porque afecta solamente a lo que se entrega en mano.
Confundir los dos redondeos genera diferencias de caja que después nadie sabe explicar.
Truncar es cortar los decimales sobrantes sin evaluarlos, y en los números positivos empuja siempre hacia abajo.
Es más rápido de calcular, pero introduce un sesgo sistemático que se nota apenas hay volumen.
Por eso conviene reservarlo para los casos donde la normativa lo exige, en lugar de usarlo como atajo general.
El hub de Contabilidad empresarial ubica este concepto dentro de un proceso empresarial.
En Nota de Crédito y Nota de Débito: cuándo usar cada una, con Ejemplos reales vemos cómo se aplica a decisiones y tareas concretas.
EGA Futura Conta muestra cómo se refleja dentro de la Plataforma.
Y EGA Futura TAX lo muestra desde otra parte del sistema.
El ERP de EGA Futura guarda los importes en campos de moneda con dos decimales.
Eso vale igual para el Total de una Factura, para el costo de adquisición de un Activo fijo y para el total de una Orden de devolución.
Fijar la precisión en el propio campo evita que cada pantalla muestre una cantidad distinta de decimales.
En la línea de una venta, el Precio unitario y el Descuento % son campos que se cargan, y el Total de línea es un campo calculado.
Que el total sea una fórmula y no un número tipeado tiene una consecuencia directa: siempre se recalcula desde los mismos datos.
Así el resultado deja de depender de quién lo cargó y de con cuántos decimales lo hizo.
La Plataforma trabaja con más de una moneda activa y guarda el tipo de cambio de cada una.
Cada registro lleva su propia moneda, así que un importe en una divisa y otro en otra conviven sin mezclarse.
La conversión entre monedas es el segundo lugar donde aparece el redondeo, porque multiplicar por un tipo de cambio casi nunca da un número exacto de dos decimales.
La Configuración de la empresa define una Cuenta de Diferencias de cambio, que apunta a una Cuenta contable concreta.
Ahí se imputa la diferencia entre lo que se registró al momento de la operación y lo que finalmente se cobró o se pagó.
Tener esa cuenta definida de antemano es lo que evita que las diferencias queden repartidas al azar entre otras cuentas.
La misma Configuración guarda la Cuenta Crédito Fiscal IVA y la Cuenta Débito Fiscal IVA.
A eso se suman las cuentas de retenciones y percepciones, efectuadas y sufridas, cada una con su imputación propia.
Separar cada concepto en su cuenta es lo que permite ver dónde se generó una diferencia, en lugar de descubrir un descuadre global sin origen.
Un Informe que suma importes de muchos registros es el lugar donde una diferencia de centavos se vuelve visible.
Como los importes se guardan con dos decimales, la suma del Informe coincide con la suma manual de las líneas.
Cuando aparece una diferencia, el origen habitual es una conversión de moneda y no el cálculo de la línea.
Son las dudas que aparecen cuando los importes no cierran por centavos: en qué momento del cálculo redondear, por qué la suma de las líneas difiere del total y qué pasa con el efectivo.
No, y confundirlos es el error más común.
El redondeo por defecto baja siempre, mire lo que mire, mientras que el redondeo simétrico baja solo cuando el primer dígito descartado es menor que 5.
Lo más tarde posible.
Calcular con toda la precisión disponible y redondear recién al final evita que el error se acumule línea por línea.
Porque cada línea se redondeó antes de sumarse, y esos ajustes chicos se suman entre sí.
Sumar primero con la precisión completa y redondear el resultado hace desaparecer la diferencia.
No. El comprobante conserva su importe exacto y lo que se ajusta es lo que se entrega en mano, según la denominación mínima disponible.
Esa diferencia se registra aparte, y mezclarla con el importe facturado genera descuadres de caja.

Los importes del ERP se modelan con campos de tipo Currency(16, 2), o sea 16 dígitos con 2 decimales.
Aparecen así EGAFutura__Invoice__c.EGAFutura__Total__c, EGAFutura__Return_Order__c.EGAFutura__Total__c, EGAFutura__Activo_fijo__c.EGAFutura__AcquisitionCost__c y EGAFutura__Activo_fijo__c.EGAFutura__ResidualValue__c.
En EGAFutura__SalesOrderLine__c, el precio está en EGAFutura__UnitPrice__c (Currency 16, 2) y el descuento en EGAFutura__DiscountPercent__c (Percent 5, 2).
El resultado está en EGAFutura__LineTotal__c, que es una fórmula de tipo Currency y por lo tanto de solo lectura.
La cantidad, en EGAFutura__Quantity__c, es un Number(18, 0) sin decimales.
La org tiene habilitada la gestión de varias monedas, con los objetos CurrencyType y DatedConversionRate disponibles.
Cada registro lleva su propio CurrencyIsoCode, presente entre otros en Factura, Macro y las líneas de venta.
La conversión la resuelve la Plataforma, así que conviene no recalcularla por código salvo que el caso exija un criterio distinto del estándar.
En EGAFutura__Configuration__c están EGAFutura__Cuenta_Diferencias_cambio__c, EGAFutura__Cuenta_Credito_Fiscal_IVA__c y EGAFutura__Cuenta_Debito_Fiscal_IVA__c.
Todas son búsquedas hacia EGAFutura__Cuenta_contable__c.
En Apex conviene usar Decimal y no Double para cualquier cálculo de importes, porque Double arrastra error binario.
El método setScale permite elegir explícitamente el modo de redondeo en lugar de dejarlo al valor por defecto.
Ventas, compras, inventario, finanzas y equipo, con la información al día y disponible desde cualquier dispositivo. Funciona en la nube, así que no hay servidores que mantener.
Quiero llevar mi Empresa a la Nube