Un céntimo de diferencia también necesita explicación
En una aplicación de gestión no basta con que los totales sean aproximadamente iguales. Un cálculo puede redondear cada línea, acumular primero y redondear después, o descartar determinadas posiciones decimales. Esas decisiones deben identificarse en el programa y en el resultado que utiliza el negocio.
Nuestra consultoría para empresas de Valencia puede comenzar por el recorrido de un importe: entrada, cálculo intermedio, almacenamiento y presentación. Así se distingue un cambio en el valor de un cambio en el formato mostrado. También revisamos si el fichero de salida conserva toda la precisión que maneja el proceso.
De los campos COBOL al modelo numérico de C#
Para migrar a .NET estudiamos el rango y la escala de cada dato, no solo su nombre. Que un campo se llame TOTAL no explica si admite negativos, qué representa cuando está vacío o cómo reacciona el programa ante un importe que no cabe.
El tipo decimal de C# puede formar parte del diseño, pero elegirlo no reproduce automáticamente todas las operaciones del origen. Definimos conversiones y momentos de redondeo de forma explícita. La documentación técnica de Microsoft y del compilador COBOL se utiliza para resolver detalles de representación y comportamiento.
Una batería de pruebas con sentido contable
Proponemos ejemplos alrededor de los límites: cantidades mínimas, descuentos encadenados, devoluciones parciales y operaciones con resultado negativo. Añadimos documentos con muchas líneas para detectar diferencias que no aparecen en una sola operación.
Cuando se comparan cierres, conviene conservar el detalle que explica cada agregado. Si solo se dispone del total final, dos errores pueden compensarse y pasar inadvertidos. El informe de comparación debe permitir localizar el documento y la regla que originan la discrepancia.
IA para ayudar a localizar reglas, no para decidirlas
Las herramientas de OpenAI y Claude, de Anthropic, pueden apoyar la lectura de las rutas de cálculo y sugerir pruebas. No les pedimos que elijan el criterio de redondeo que «parezca más correcto». Ese criterio se obtiene de la especificación aplicable al proceso y se valida con su responsable.
El código generado se revisa junto con las pruebas. Una función nueva más breve puede cambiar el orden de las operaciones o introducir conversiones implícitas. La aceptación requiere explicar esos cambios, no valorar únicamente la legibilidad de la propuesta.
Separar una corrección funcional de una migración
Si se descubre una regla antigua que la empresa desea cambiar, dejamos dos decisiones diferenciadas: reproducir el comportamiento actual y aprobar el comportamiento nuevo. Aplicar la corrección durante la conversión sin registrarla haría imposible saber qué diferencia procede de cada trabajo.
El alcance puede cubrir solo el motor de cálculo y mantener intactas las pantallas y la comunicación con otros sistemas. Este planteamiento permite probar con un conjunto controlado de documentos antes de abrir el uso general. No presupone que tu aplicación necesite ser reescrita por completo.