Código Z y material de 40 caracteres: las cuatro fallas típicas
Pérdida de datos, conflictos de tipo, comparaciones y concatenaciones: los cuatro patrones que rompen integraciones cuando el código Z no se adaptó.
Un desarrollador ABAP que abra hoy un programa Z escrito antes de la conversión no va a encontrar una línea que diga «aquí se rompe el material». Va a encontrar declaraciones, firmas, condiciones y cadenas que fueron correctas en su momento y que ahora conviven con un tipo estándar más largo. Esta pieza le entrega un mapa: qué cuatro patrones de código buscar, cómo se manifiesta cada uno y cuáles se delatan solos y cuáles se esconden.
El inventario no es nuestro. Proviene de la lista de posibles problemas que aparecen cuando campos de material desarrollados a 18 caracteres entran en contacto con el nuevo MATNR de 40 (KTern, 2023). Lo que aportamos es la lectura práctica para quien tiene que revisar el código de una utility o de una operadora de oil & gas.
Antes de empezar: no todas las fallas hacen ruido
Conviene ordenar la revisión por la forma en que cada falla se deja ver, no por su número. Un conflicto de tipos en una firma tiende a aparecer pronto, en la activación o en las pruebas, porque el programa deja de aceptar lo que recibe. Un valor recortado o una comparación que cambia de resultado, en cambio, no detienen nada: el proceso termina, el documento se emite y el error se descubre después, en otra área.
De esa diferencia sale la prioridad. Las fallas ruidosas llegan solas a la mesa de soporte, porque alguien las reporta. Las silenciosas exigen búsqueda activa en el código y, cuando por fin aparecen, se confunden con un problema de calidad de datos.
Falla 1: el valor que se recorta al asignarlo
Es la silenciosa por excelencia. El patrón documentado es la pérdida de datos cuando una variable de un programa custom está referida a un MATNR de 18 caracteres (KTern, 2023).
Lo que la vuelve difícil de rastrear es la distancia entre causa y efecto: la línea que altera el valor y la rutina donde el error se nota suelen ser distintas. Por eso la revisión no puede partir del síntoma. Tiene que partir de las declaraciones y seguir el valor hasta donde se usa.
Falla 2: la firma que ya no acepta el argumento
Es la ruidosa. El patrón son los conflictos de tipo durante el paso de parámetros en métodos ABAP (KTern, 2023): una clase o una función Z declaró su parámetro de material con un tipo propio de 18, y ahora recibe un campo estándar de otro tipo.
Lo costoso no es encontrarla, sino su alcance. Una rutina utilitaria de material suele estar llamada desde muchos programas, y corregir la firma obliga a revisar a todos los que la invocan. Cada uno de ellos, a su vez, puede esconder una variable intermedia de la falla 1.
Qué buscar: parámetros IMPORTING, EXPORTING y CHANGING tipados con elementos propios para el material, y la lista de usos de cada rutina afectada antes de cambiarla.
Falla 3: la condición que cambia de respuesta
Vuelve a ser silenciosa. El patrón son los conflictos de longitud al comparar una variable custom con el campo estándar MATNR (KTern, 2023).
En facturación, el riesgo está en que ninguna alarma acompaña el cambio de rama: el documento se emite como cualquier otro. Por eso esta revisión debe empezar por las reglas de negocio que deciden cobros, exclusiones y cargos, no por los programas que fallan en las pruebas.
Falla 4: la cadena que corre los campos del receptor
La última combina las dos naturalezas. El patrón son los conflictos de longitud al concatenar con el campo estándar MATNR (KTern, 2023), típicos del código que arma claves compuestas o registros de archivo plano para otro sistema.
Su particularidad es que la revisión no termina en el programa que escribe la cadena. Cuando el receptor la interpreta por posiciones, el lado que lee también entra en el alcance, aunque nadie haya tocado su código.
Un quinto lugar donde mirar: la asignación al campo equivocado
Hay un caso que queda fuera de las cuatro fallas, porque el destino no es una variable propia sino un campo de una estructura estándar: el código escribe el material en el campo de longitud antigua cuando ya existe uno largo. En un caso real documentado, la corrección consistió en reemplazar, línea por línea, la asignación al campo de material original por la asignación al campo MATERIAL_LONG (IBM, 2019). Para el revisor es una búsqueda simple: asignaciones a campos de material en estructuras de llamada que tengan una versión larga disponible.
El orden de revisión que proponemos
La corrección de fondo es la misma para los cuatro patrones: adaptar los números de material custom al nuevo tipo estándar de SAP (KTern, 2023). Lo que cambia el resultado es el orden. En AGT lo derivamos de la diferencia entre fallas ruidosas y silenciosas: primero lo que nadie va a reportar, y al final las firmas, que conviene corregir cuando el inventario de llamadas ya está completo.
Lo que viene: encontrarlas sin leer programa por programa
Este mapa le dice al equipo qué buscar, pero no cómo hacerlo a escala en todo el código Z. La siguiente pieza de esta serie muestra el chequeo de ATC que detecta este riesgo antes de que llegue a producción.
Lecturas relacionadas
Estas piezas del blog de AGT complementan la revisión del código Z, desde el síntoma en producción hasta el alcance real de la remediación.
Fuentes
- KTern (2023). Why is Custom Code Adaptation required for S/4HANA Conversion Project? https://ktern.com/article/importance-custom-code-adaptation-s4hana-conversion/
- IBM (2019). Configuring Maximo Enterprise Adapter for SAP to use the material number field length extension in SAP S/4HANA. https://www.ibm.com/support/pages/node/1098081
Artículo de Edward Camacho Guerra, elaborado con apoyo de herramientas de inteligencia artificial y revisado y aprobado por el autor.
¿Este análisis describe un mercado donde ya opera o que está evaluando?
Revisamos su caso, mapeamos los riesgos que aplican y le decimos con franqueza si es una oportunidad para usted —sin presentación comercial, solo una conversación técnica y estratégica.
