Hoy voy a contar un nuevo episodio en mi vida como desarrollador contra-corriente. Como ya conté en mi artículo sobre los colectores de basuras, llevo tiempo trabajando en un megaprograma de gestión de clientes, pedidos, facturas, análisis, seguimiento y más cosas. También dije que hay varias cosas de este proyecto con las que no estoy de acuerdo y de las que me he quejado en repetidas ocasiones, empezando por que la planificación no fue suficiente en su momento. Precisamente esta falta de planificación ha sido la causante de un problema que reventó hace pocos días.
Hace tiempo, al principio, sugerí que íbamos a tener problemas con el redondeo. Este no es un problema trivial, porque si no se hace bien aparecerán discrepancias y luego no hay forma de cuadrar las cuentas. Ya entonces propuse una forma de evitarlo que usé con éxito hace años en un Terminal Punto de Venta que desarrollé cuando trabajaba en la empresa Asintec Gestión. En aquel programa, en lugar de almacenar el valor real de los productos guardábamos un valor ficticio y lo guardábamos como un número entero. Para obtener el valor real se dividía este número ficticio por un factor que dependía de la divisa; así para los euros dividíamos por 100.000, mientras que para obtenerlo en pesetas dividíamos por 601. Con este método nos quitamos dos problemas: la conversión entre divisas (importante, porque se hizo para un hotel, y además coincidió con el paso de la peseta al euro) y teníamos una precisión de hasta la milésima de céntimo de euro, más de lo necesario. Además, los ordenadores son pésimos con el cálculo fraccionario, siendo mucho más precisos si calcula con números enteros.
Con la aplicación que estoy desarrollando ahora, sin embargo, tampoco en esto se me hizo caso y se me obligó a almacenar y realizar todos los cálculos con euros “reales”. Y no sólo eso, sino que la precisión se limitó a dos decimales, esto es, a un céntimo: ni siquiera una fracción de céntimos, sino a céntimos enteros. Esto ya es un problema con el cálculo de impuestos. La cosa empeoró cuando en Julio entró en vigor el nuevo IVA1. El cliente quiso que los precios finales se mantuvieran invariables aun con el cambio de IVA, sin embargo al hacer el cálculo siempre faltaban o sobraban uno o dos céntimos en cada producto. Canté aquello de “os lo dije” con toda la sutileza de la que fui capaz y volví a sugerir la solución que he explicado antes, pero de nuevo no me hicieron caso y la solución impuesta fue aumentar en un decimal la precisión (es decir, hasta la décima de céntimo) porque así ya no faltaban ni sobraban céntimos al sumar el nuevo impuesto y se solucionaba el problema.
Hasta que se demostró que no era así. Hace unos días, un cliente se quejó porque hizo un pedido por un importe aproximado de 1.500€, pero la factura que le enviaron había una diferencia de 21 céntimos a favor de la empresa. Por más que revisé los cálculos, todos eran correctos, tanto en el albarán de pedido como en la factura, sin embargo la discrepancia permanecía. Yo sabía que era un problema de redondeo, pero no lograba descubrir dónde se producía la diferencia. Al final lo descubrí por casualidad.
Resulta que del cambio en la base de datos se encargó mi jefe, y lo realizó sólo en la tabla que almacena la información de los productos en venta. Sin embargo, en nuestro programa el precio de los productos se almacena también en cada factura, de forma que aunque cambie el precio de los productos este no varía también en las facturas, y en la tabla donde se almacena el precio en factura no se hizo el cambio. Es decir, que el precio del producto se guarda con tres decimales, mientras que el precio en factura se guarda con dos. ¿Y dónde está el problema? Pues sencillo: en unos productos el precio es de tantos euros, tantos céntimos y menos de medio céntimo, lo que al redondear a dos decimales no afecta al precio salvo si son muchas unidades (por ejemplo, si el precio es de 10'652 al redondear queda 10'65), pero en otros es de tantos euros, tantos céntimos y más de medio céntimo, por lo que al redondear a dos decimales ese “más de medio céntimo” hace que el precio suba al céntimo siguiente (por ejemplo, de 10'656 queda 10'66). Es decir, el mismo problema que existía al calcular el nuevo valor neto para ajustarlo a los nuevos IVA y Recargo de Equivalencia; era una bomba de relojería.
Todavía no sé si está arreglado, ya que conseguí cargarle el mochuelo a quien realmente tuvo la culpa. Me gustaría pensar que en el próximo proyecto me harán más caso pero, visto lo visto, me temo que voy a tener que sufrir estas cosas durante mucho tiempo, todavía.
1 Lo del IVA fue otra buena, porque se puso "en duro", es decir, que para añadir los nuevos IVAs tuve que cambiar varias fórmulas matemáticas y comprobaciones en un buen número de archivos. Evidentemente también rechazaron mi propuesta de guardar los impuestos en la base de datos para poder añadirlos y eliminarlos a gusto sin tener que cambiar ninguna fórmula; recuerdo perfectamente que me dijo que no porque, total, era muy poco probable que cambiaran los impuestos.
Rss
