Un código de producto puede representar varias realidades
La referencia que se muestra al usuario no siempre coincide con la clave que utiliza el sistema. Puede haber variantes, presentaciones y códigos de terceros. Antes de convertir archivos o publicar una API, identificamos esas relaciones y su ámbito de validez.
En una consultoría para Castellón revisamos cómo se crea y modifica el catálogo. También preguntamos qué ocurre cuando una referencia deja de usarse pero sigue apareciendo en documentos antiguos.
Las unidades no se corrigen cambiando una etiqueta
Una cantidad puede expresarse en unidades, paquetes o una medida continua. Si el programa convierte entre ellas, hay que conocer el factor y el momento en que se aplica. Cambiar el tipo de dato sin esa regla puede alterar disponibilidades y precios.
El diagnóstico identifica conversiones reversibles y aquellas que necesitan redondeo. Se revisa qué hacer cuando una conversión produce una fracción no admisible para la operación siguiente. La decisión corresponde al proceso del cliente, no a una convención supuesta.
Un modelo de datos de destino que explique el catálogo
En C# y .NET podemos separar referencia, variante y presentación cuando esa distinción exista en el negocio. Antes se comprueba cómo se relacionarán con las claves COBOL que deben seguir funcionando. No se renumeran identificadores sin estudiar sus consumidores.
El piloto puede consistir en una consulta de catálogo o en un intercambio con otra aplicación. Se conservan ejemplos para comparar medidas, descripciones y estados, además del número total de registros.
IA para localizar transformaciones dispersas
Claude de Anthropic o herramientas de OpenAI pueden ayudar a encontrar cálculos de conversión en distintos programas. Las coincidencias se revisan porque una fórmula parecida puede utilizar escalas diferentes. No se unifican funciones solo por similitud textual.
Las pruebas propuestas por IA deben incluir referencias antiguas, factores ausentes y cambios de presentación. El equipo contrasta las salidas con la aplicación y con el responsable del catálogo.
Mantener compatibilidad durante la transición
Si el destino incorpora un modelo más explícito, se define cómo traducirlo para los consumidores que siguen esperando el formato anterior. Esa adaptación se prueba con operaciones reales del circuito, usando datos autorizados o sintéticos.
Por ejemplo, un nuevo visor podría presentar variantes sin cambiar todavía los pedidos COBOL. El proyecto comprobaría que cada selección corresponde a la referencia esperada. Es una situación ilustrativa, no un caso local acreditado ni una garantía de conversión inmediata.