Exportar datos de IBM i para preparar el DeCA

Empieza por el proceso, la biblioteca y el formato real

IBM i puede alojar aplicaciones con décadas de evolución, archivos físicos, archivos lógicos, programas RPG o COBOL, colas, interfaces y nombres de campo internos. Dos empresas con la misma versión del sistema operativo pueden tener modelos de datos completamente distintos. Antes de extraer nada, documenta qué programa prepara la expedición, qué biblioteca contiene los registros, qué vista lógica reúne los datos y en qué momento una operación está lista para salir.

No conviene copiar tablas completas de producción para descubrir el modelo fuera del sistema. El equipo que mantiene IBM i debe proponer una consulta, vista o archivo de salida con los campos necesarios y una clave estable. Esa capa reduce el riesgo de depender de estructuras internas, interpretar valores codificados de forma incorrecta o exponer datos ajenos al documento. También permite revisar rendimiento y ejecutar la extracción en una ventana controlada.

Producto y versión de IBM i, aplicación, biblioteca y entorno de prueba.
Archivo físico o lógico que representa la expedición y sus relaciones.
Estado que confirma que los datos están listos para documentar.
Clave estable, fecha de actualización y volumen previsto por ejecución.

Crear una salida con CPYTOIMPF o un proceso equivalente

IBM documenta el mandato Copy to Import File, CPYTOIMPF, para leer un archivo de origen y escribir un archivo de importación. El destino puede ser, entre otros, un stream file del Integrated File System, y el resultado puede tener campos delimitados o formato fijo. El origen admite distintos tipos de archivos físicos y un archivo lógico de formato único. Esto permite preparar una salida explícita sin dar acceso general a la base de datos.

La elección entre delimitado y fijo debe quedar en un contrato de archivo. Para CSV o similar, define separador de campos, delimitador de texto, tratamiento de comillas, carácter decimal, representación de fechas, valores nulos y final de línea. Para formato fijo, documenta posición, longitud, tipo y relleno de cada campo. Usa una cabecera o manifiesto con versión del esquema, fecha de generación, número de registros y lote para detectar archivos incompletos o antiguos.

Exporta desde una vista preparada y no desde todas las columnas de la aplicación.
Fija codificación, separadores, fechas, decimales y valores vacíos.
Incluye una versión de esquema y un identificador de lote.
Genera primero en prueba con datos sintéticos y un volumen reducido.

Controlar CCSID, decimales y valores codificados

Un archivo técnicamente generado puede seguir siendo inutilizable si la codificación o las convenciones no coinciden con el receptor. Verifica el CCSID del origen y del stream file, y prueba nombres, direcciones y mercancías con acentos, eñes y símbolos permitidos. No intentes reparar caracteres sustituidos después de importar: la conversión debe estar definida en el punto de salida y validada con valores conocidos.

Los campos numéricos necesitan la misma precisión que la aplicación. Peso, cantidades y códigos con ceros iniciales no deben convertirse sin una regla. Una fecha compacta, un indicador de estado o una matrícula almacenada en varios campos requiere transformación documentada. Conserva el valor original junto al normalizado cuando sea útil para auditoría y rechaza el registro si una transformación pierde información esencial.

Prueba caracteres españoles y textos de longitud máxima.
Mantén precisión y unidad para pesos y cantidades.
Distingue cero, vacío, nulo y código desconocido.
No elimines ceros significativos de referencias, NIF o matrículas.

Mapear la expedición a los campos del DeCA

La Orden FOM/2861/2012 exige identificar al cargador contractual con nombre o razón social, NIF y domicilio, y al transportista efectivo con nombre o razón social y NIF. También recoge origen, destino, naturaleza y peso, fecha, matrículas y autorización especial cuando corresponda. Los nombres de cliente, agencia, transportista o almacén en la aplicación no demuestran por sí solos qué figura contractual representan; el responsable funcional debe aprobar esa equivalencia.

El mapa debe indicar archivo y campo de origen, conversión, obligatoriedad y responsable. El cargador contractual responde de la exactitud de partes, origen, destino, naturaleza y peso; el transportista efectivo, de autorización especial, fecha y matrículas. Si IBM i no conoce aún el vehículo, DecaGestion puede solicitarlo en una etapa controlada antes de emitir. Ningún valor obligatorio debe completarse con una dirección, un peso o un código anterior por defecto.

Partes: identidad y papel contractual, no solo código de cliente o proveedor.
Trayecto: lugares reales de carga y descarga.
Mercancía: descripción legible, peso, unidad y regla de agregación.
Transporte: fecha, tractor, remolque y autorización especial cuando proceda.
Control: referencia IBM i, lote, versión de esquema y usuario que valida.

Proteger el archivo en el Integrated File System

El stream file puede guardarse en un directorio dedicado del Integrated File System, pero su ruta no debe convertirse en una carpeta pública. IBM explica que las autoridades de los objetos del IFS combinan permisos de lectura, escritura y ejecución con el modelo de autoridades de IBM i, y que los objetos nuevos heredan características del directorio padre. Por eso la seguridad debe prepararse antes de generar el primer lote.

Utiliza un perfil técnico exclusivo para escribir o leer la salida, limita el acceso público y concede solo las autoridades necesarias sobre directorio y archivo. Separa las rutas de prueba y producción. El proceso de transferencia debe cifrar el canal, registrar resultado y eliminar o archivar el archivo conforme a la política acordada. No guardes contraseñas en programas CL, nombres de fichero, parámetros visibles o logs. Revisa además quién puede cambiar permisos o sustituir un lote.

Directorio dedicado con acceso público excluido y permisos mínimos.
Perfil técnico distinto de usuarios interactivos y administradores.
Transferencia cifrada, verificación de integridad y registro de recepción.
Retención temporal definida para los archivos de intercambio.

Evitar duplicados y detectar lotes incompletos

Cada fila debe incluir una clave de negocio estable y, si puede rectificarse, una fecha o versión. DecaGestion combina esa clave con la organización y el origen para aplicar idempotencia: recibir dos veces el mismo lote no emite dos documentos. Si cambia un campo, el sistema debe distinguir entre actualizar un borrador, crear una rectificación o rechazar una modificación que llega cuando el documento ya está cerrado.

El importador valida cabecera, número de columnas, tipos, longitud, duplicados y campos obligatorios antes de confirmar el lote. Si el archivo se está escribiendo mientras otro proceso lo lee, puede utilizarse una convención de nombre temporal y renombrado final o un manifiesto de cierre. Los errores deben quedar asociados a la referencia IBM i para corregir y reprocesar únicamente las filas afectadas, sin perder las ya aceptadas ni repetir cuotas o envíos.

Clave idempotente por empresa, origen y expedición.
Nombre temporal o señal de cierre antes de consumir el lote.
Resumen de aceptados, rechazados y motivos por fila.
Reintento controlado que no genera documentos ni mensajes duplicados.

Generar el PDF y probar el recorrido completo

La Resolución de 5 de junio de 2026 exige transformar los datos estructurados en el fichero antes del inicio efectivo del servicio y registrar fecha y hora de creación y modificación. El DeCA debe ser un PDF nativo digital, legible y de hasta 5 MB, con un QR que contenga la URL única del documento. La dirección HTTPS debe producir la descarga directa durante una inspección, sin credenciales ni pasos manuales adicionales.

Prueba con expediciones sintéticas que incluyan caracteres especiales, varias líneas, remolque, un peso decimal, un campo ausente, duplicado y cambio de matrícula. Genera el PDF, escanea el QR desde otra red, descarga el fichero y simula la rectificación conservando el original. Comprueba también una caída durante la transferencia. El piloto valida el esquema y la aplicación concreta; los programas propios, formatos multirregistro o cambios en IBM i pueden requerir desarrollo y presupuesto separado.

Compara cada dato del PDF con el registro de origen y la validación de tráfico.
Ensaya codificación, errores, duplicados, interrupciones y rectificaciones.
Entrega al conductor una copia electrónica o impresa con QR.
Documenta operación, soporte y recuperación antes de pasar a producción.

Preguntas frecuentes

¿Hay que modificar la aplicación IBM i?

No siempre. Puede prepararse una vista o archivo de salida estable y usar CPYTOIMPF o un proceso equivalente. Los formatos complejos o campos que no existen pueden requerir un desarrollo acotado.

¿AS400 e IBM i significan lo mismo?

AS/400 es una denominación histórica que muchas empresas siguen usando. IBM i es el sistema operativo actual de la plataforma; para integrar hay que conocer la versión y la aplicación concreta, no basarse solo en el nombre coloquial.

¿Un CSV exportado ya es un DeCA?

No. El archivo sirve como fuente estructurada. Después deben validarse los campos, generarse el PDF nativo, asignarse una URL única y QR, conservarse versiones y facilitar el acceso exigido.

¿Cómo se evita procesar dos veces el mismo archivo?

Con una referencia estable por expedición, identificador de lote, validación del cierre e idempotencia en el servidor. Un reintento debe reutilizar el resultado o informar del estado, no emitir otro documento.

Fuentes oficiales y técnicas

Fuentes consultadas o verificadas el 19 de septiembre de 2026. Verifica siempre la versión consolidada y su aplicación a tu caso.