Datos de entrada/salida para los conversores
Datos de salida
En todos los casos, se indicará una DD, que es la lista de ficheros de salida que genera el conversor (no confundir con la lista de ficheros de entrada que ha podido crear el usuario y que incluso le podía llegar antes al A1P).
Esta lista de ficheros de salida, será la que debe estar en el paso A1P (además de apuntar la variable LF=S). Para ver el formato del ZTBGFCAR ver Tabla 1.
//ZTBGFCAR DD DSN= KI.PMED.&L0..R&R1..R&R2..A&AP..LISTFICX,DISP=SHREn el caso de posterior a recepción o JCL, esta lista contiene los DSNAME finales de los planos generados.
Por tanto, si el usuario hasta ahora indicaba al paso A1P una lista de ficheros, la misma se incluirá como dato de entrada al conversor, el conversor genera una lista de ficheros (distinta a la anterior), que será la que le llega al A1P.
También el conversor puede generar un ZTBXFSAL con el resultado de los ficheros pasados al conversor (ver tabla 3). Si no se quiere no incluir la ficha o poner SYSOUT *.
//ZTBXFSAL DD DSN= KI.PMED.&L0..R&R1..R&R2..A&AP..ZTBXFSAL,DISP=SHRSi el conversor se está utilizando integrado a Editran, con los procedimientos previos y posteriores se pueden obtener los mensajes en el LOG de Editran/G, incluyendo en el paso del conversor su ficha DD. Si no se quiere esta funcionalidad no incluir la ficha DD.
//ZTBGFLOG DD DSN=PUNTERO.INDRA.ZTBGFLOG,DISP=SHR Ejemplo LOG:
U ZTB0000 000099940 000099990 CARGAC 05/02/2014 15:29:29 KI0F6AEA 04203
ERROR LLAMANDO ZTBXBITS TRANSFORMACION FICH.
U ZTB0000 000099940 000099990 CARGAC 05/02/2014 15:29:30 KI0F6AEA 04203
Error en el marshaller del xml Tabla 3. Contenido del fichero ZTBXFSAL, fichero fijo de 252 de longitud, cuyo contenido son los ficheros que pasan por el conversor y el resultado de la conversión. El contenido es el siguiente:
Nivel
Nombre
Long.
Tipo
Descripción
1
Nombre físico entrada
44
Alfn.
Nombre físico del fichero de aplicación que entra al conversor
1
Filler
1
Alfn.
Guion de separación
1
Nombre físico salida
44
Alfn.
Nombre físico del fichero de aplicación que genera el conversor
1
Filler
1
Alfn.
Guion de separación
1
CGO resultado del conversor
4
Num
Resultado devuelto por el conversor
1
Filler
1
Alfn.
Guion de separación
1
Texto del Error
80
Alfn.
Texto del Mensaje del error devuelto por el conversor
1
resto registro
77
Alfn.
Área de reserva
Datos de entrada.
Para llamar a los conversores, se usan:
Datos mediante PARM
Datos introducidos en un fichero de usuario, (que puede ser siempre el mismo para todo ó si no vale, se puede construir con variables). Este fichero ZTBGFDAT, puede ser distinto para cada sesión. En ese caso, en el procedimiento, especificaremos un DSNAME con variables, por ejemplo, origen, remoto, aplicación, etc. Ejemplo:
Datos pasados al conversor mediante PARM.
Al conversor, es necesario pasarle los siguientes datos mediante PARM:
Origen. Rbe origen. En caso de JCL's no Editran, se pone el código de la entidad. En otro caso, se pasa la variable de entrada al procedimiento (&L1&L2).
Destino. Rbe destino. En caso de jcls no Editran, se pone el código de alguna entidad destino ejemplo. En otro caso, se pasa la variable de entrada al procedimiento (&R1&R2).
Aplicación. Aplicación Editran/G. En caso de JCL's no Editran, se pone el código de alguna aplicación/g ejemplo. En otro caso, se pasa la variable de entrada al procedimiento (&AP)
Función: (X)- Plano a XML, (P)- XML a plano
Tipo de fichero de entrada (en el caso de función X hace referencia al PLANO, en el caso de función P, hace referencia al XML).
(F) Fichero. El JCL o procedimiento, lleva un fichero de entrada con un DSNAME.
(L) Lista. El JCL o procedimiento, lleva una lista de ficheros de entrada.
En procedimientos previos a emisión (función X plano a XML). Si usted usa listas de ficheros en la carga, se recomienda utilizar esta opción.
En procedimientos posteriores a recepción (función P XML a plano). El procedimiento standard del producto, deja una lista de ficheros recibidos, por lo que se recomienda utilizar esta opción como dato de entrada al paso conversor XML a plano.
(P) Perfiles. El JCL o procedimiento, no lleva fichero ni lista de ficheros de entrada. Los ficheros de aplicación de emisión se sacan de lo que hubiera en perfiles de la aplicación.
En procedimientos previos a emisión. Si usted usa perfiles Editran en la carga, se recomienda utilizar esta opción.
En procedimientos posteriores a recepción (función P, XML a plano), esta opción no tiene sentido.
DSNAME del fichero de entrada (no puede ser un miembro de un particionado).
Si tipo de fichero de entrada es P, no se indicará nada.
Si tipo de fichero de entrada es F, se indicará aquí un nombre de fichero (directamente ó con variables).
Si tipo de fichero de entrada es L, se indicará aquí una lista cuyo contenido son los ficheros a transformar (ver Tabla 1). Si el usuario ya usaba lista de ficheros, se indicará aquí ese nombre.
Ejemplo de PARM, en un previo a emisión con lista de ficheros:
Le estamos indicando que la sesión es L1+L2 (origen), R1+R2 (destino), AP (aplicación), (FU)unción X (plano a XML), (TI)po:(L)ista de ficheros y FI (dsname de la lista es KI.EGDC.xxx.Ryyy.Ryyyyyy.Azzzzzz.LCAR) (donde xxx es el alias de entorno local, yyyyyyyyy es el código remoto, zzzzzz es la aplicación). Además, se le apunta la variable LF = S, porque el paso A1P lo requerirá así.
En cargas, en TODOS los casos (LISTA (L), FICHERO (F), PERFILES (P)) se debe indicar la DD ZTBGFCAR, que, a su vez, debe estar en el paso A1P. Además, se debe indicar que la borre anteriormente (ó posteriormente) y en los procedimientos se debe apuntar la variable LF=S. Esta ZTBGFCAR es la lista que contiene los XML que cargará la aplicación (no confundir con la la lista de ficheros que puede proporcionar el usuario al conversor) o la lista de ficheros TRANSFORMADOS (caso de lanzar JCL ó caso de posterior a recepción).
En descargas se recibe del paso A4P una lista de ficheros ZTBGFLFE (creada por la aplicación), por lo que habrá que indicar siempre .PL&&LFE. El paso del conversor, creará una nueva lista de ficheros transformados ZTBGFCAR en todos los casos.
Cuando este conversor se lanza por fuera de la aplicación, (en un jcl aparte), lo normal es usar Tipo de fichero de entrada F (&TI=F), pues se puede incluir un nombre de fichero directamente (&FI).
Cuando este conversor se lanza por dentro de la aplicación (embebido en los procedimientos previos a emisión y posteriores a recepción):
En previos a emisión (cargas):
Si el usuario ya está construyendo una lista de ficheros, por ejemplo KI.EGDC.xxx.Ryyy.Ryyyyyy.Azzzzzz.LCAR, debe continuar haciéndolo de la forma forma, indicando el nombre en la variable &FI e indicando &TI=L :
Si el usuario, tira de perfiles Editran para hacer las cargas, debe continuar haciéndolo normalmente, indicando &TI=P
Normalmente, no se usará la opción F, puesto que eso probablemente implique generar un procedimiento distinto para cada sesión de presentación.
El conversor, en todos los casos, genera una nueva lista de ficheros que se pasará al paso A1P, Esta lista de ficheros se genera con el nombre que hayamos puesto en la DD //ZTBGFCAR DD xxxxx
En posteriores a recepción (descargas):
El paso del conversor, creará una nueva lista de ficheros transformados ZTBGFCAR en todos los casos
Datos pasados al conversor mediante fichero de usuario (ZTBGFDAT).
En todos los casos, es necesario que el usuario cree un fichero (o n) con ciertos parámetros que normalmente serán siempre iguales. Este fichero se llama ZTBGFDAT y es un plano de LRECL de 86 y FB. El contenido de este fichero es el siguiente:
Nivel
Nombre
Tipo
Long
Pos
Uso
Descripción
1
Tipo de Registro
Num.
1
1
Obligatorio
Tipo de registro:
0-Datos de conexión del servidor java
1-Datos de la transformación para PLANO a XML
2-Datos de la transformación para XML a PLANO
3-Registro de confirmación-rechazo de adeudos y transferencias
*-Registro comentado
2
Registros de tipo 0
Datos de conexión al servidor java
3
Guion separador
Alfn
1
2
Opcional
Guion
3
IP ó DNS del servidor java
Alfn
1-64
3
Obligatorio
Ip xxx.xxx.xxx.xxx o dns del servidor java
Ajustado a la derecha.
3
Guion separador
Alfn
1
67
Opcional
Guion
3
Puerto del servidor java
Num
5
68
Obligatorio
Puerto de escucha del servidor java 00001 a 65536
3
Guion separador
Alfn
1
73
Opcional
Guion
3
Segundos de espera del servidor
Num
3
74
Obligatorio
Segundos máximos (001-999) en los que el cliente tcp espera respuesta del servidor java.
Si se indica 999, el cliente TCP espera sin tiempo determinado.
3
Guion separador
Alfn
1
77
Opcional
Guion
3
Información libre
Alfn
1
78
Opcional
Valor:
S incorporar valores en la zona libre del plano
N No incorporar valores
Valor por defecto N
3
Guion separador
Alfn
1
79
Opcional
Guion
3
Mantener F. salida
Alfn
1
80
Opcional
Mantener el fichero de salida si error
Valor:
S el fichero de salida no se borra
N el fichero de salida se borra
Defecto N
3
Guion separador
Alfn
1
81
Opcional
Guion
3
Quitar Validaciones SEPA España XML
Alfn
1
82
Opcional
Opcional. Si este campo no viene la opción por defecto N
Valor:
S Quita las validaciones de SEPA España
N Pone las validaciones de SEPA España
3
Guion separador
Alfn
1
83
Opcional
Guion
3
Validar XML
Alfn
1
84
Opcional
Opcional. Si este campo no viene la opción por defecto S
Valor:
X Valida el XML generado por el conversor
P Valida el XML que entra al conversor
S Valida el XML en ambos sentidos
N No valida XML en ningún caso
Atención: desactivando esta validación, los ficheros obtenidos podrían contener errores.
3
Guion separador
Alfn
1
85
Opcional
Guion
3
Cabecera TGSS
Alfn
1
86
Opcional
Opcional. Si este campo no viene la opción por defecto N
Valor:
T Es una conversión de la TGSS con FF
N Conversión normal SEPA (no TGSS)
Atención: activando este parámetro todos los 34.14 que entren al conversor se considerarán de la TGSS y tratará de poner la cabecera.
**No se generará confirmación automática aun estando indicado en este fichero reg tipo 3.
2
Registros de tipo 1
Datos de transformación de PLANO a XML
3
Guion separador
Alfn
1
2
Opcional
Guion
3
DSNAME de fichero salida (DNSMAME del XML)
Alfn
1-44
3
Obligatorio-opcional
Dsname del fichero transformado XML. En este caso, como puede haber varios ficheros transformados
1.-Se admite el uso de variables conocidas por Editran, por ejemplo, Origen, Destino, Aplicación, AÑO, MES, DIA, DSNAME ORIGEN, etc. (Ver Tabla 3)
2.-Se puede poner un nombre fijo
3.-Si no se indica nada (espacios), Editran crea ficheros de salida con el nombre: DSN-ENTRADA.XML. Esta es la opción recomendada, pues el conversor, creará una lista de ficheros de forma automática, que serán cargados por Editran, de forma que no hay que modificar perfiles.
3
Guion separador
Alfn
1
47
Opcional
Guion
3
Tabla de caracteres del fichero de aplicación origen
Alfn
18
48
Opcional
Nombre de la tabla de caracteres (encoding) en la que se encuentra el fichero origen. Si no se especifica nada, se coge por defecto la tabla del z/OS donde se esta ejecutando siempre y cuando no este parametrizado el param.alfabeto de Configuracion.properties. En el siguiente link, aparecen las tablas soportadas: https://docs.oracle.com/en/java/javase/11/intl/supported-encodings.html#GUID-D29CF3AD-FC0B-465F-8897-C38C0395AB02
⚠️ En caso de estar configurada la opción param.alfabeto de Configuracion.properties esta prevalecerá sobre este parámetro.
3
Guion separador
Alfn
1
66
Opcional
Guion
3
Tamaño del fichero de salida
Num
12
67
Opcional
Tamaño en bytes del fichero de salida.
Si no se especifica nada, Editran crea por defecto un fichero de salida de 99.999 bytes.
Si se especifica cualquier valor, Editran calcula el espacio a alocar el fichero de salida de la siguiente forma: coge el valor especificado en nº de bytes y la divide por la longitud de registro máxima de un variable (32752), en que quedará el XML.
3
Guion separador
Alfn
1
79
Opcional
Guion
3
Juntar XML
Num
1
80
Opcional
Valor:
S.- Siempre que sea posible (coinciden en todos, la fecha de creación, identificación ordenante/acreedor, etc.), unificar toda la información de cada lógico de entrada en un único fichero XML lógico y físico de salida.
N.- Obtener un fichero de salida con tantos documentos XML lógicos como como ficheros lógicos de formato plano tiene el original.
El valor por defecto es S.
3
Guion separador
Alfn
1
81
Opcional
Guion
3
Longitud de registro del XML de salida
Num
5
82
Opcional
Valor:
Tamaño del registro que queremos darle al fichero XML generado por el conversor.
Zeros, spaces o low-values como hasta ahora
Por defecto 27990
2
Registros de tipo 2
Datos de transformación XML a PLANO
3
Guion separador
Alfn
1
2
Opcional
Guion
3
DSNAME de fichero salida (DNSMAME del PLANO)
Alfn
1-44
3
Obligatorio-opcional
Dsname del fichero transformado PLANO. En este caso, como puede haber varios ficheros transformados:
1-Se admite el uso de variables conocidas por Editran, por ejemplo, Origen, Destino, Aplicación, AÑO, MES, DIA, DSNAME ORIGEN, etc. (Ver tabla 3)
2.-Se puede poner un nombre fijo
3.-Si no se indica nada (espacios) y el fichero de entrada se llama DSNAME.A.XML, se crea un plano de salida llamado DSNAME.A. En el caso de que usted esté habituado en Editran a poner el DSNAME.A, cámbielo por DSNAME.A.XML, porque el resultado final será el que tenía hasta ahora. . OPCION RECOMENDADA
4.-Si no se indica nada (espacios) y el fichero de entrada se llama DSNAME.XML, se crea por defecto el fichero DSNAME.PLN
3
Guion separador
Alfn
1
47
Opcional
Guion
3
Tabla de caracteres en que se transformará el fichero plano
Alfn
18
48
Opcional
Nombre de la tabla de caracteres en la que se desea transformar el plano. Si no se especifica nada, se coge por defecto la tabla del z/OS donde se esta ejecutando siempre y cuando no este parametrizado el param.alfabeto de Configuracion.properties. En el siguiente link, aparecen las tablas soportadas: https://docs.oracle.com/en/java/javase/11/intl/supported-encodings.html#GUID-D29CF3AD-FC0B-465F-8897-C38C0395AB02
⚠️ En caso de estar configurada la opción param.alfabeto de Configuracion.properties esta prevalecerá sobre este parámetro.
3
Guion separador
Alfn
1
66
Opcional
Guion
3
Tamaño del fichero de salida
Num
12
67
Opcional
Tamaño en bytes del fichero de salida.
Si no se especifica nada, Editran comprueba que se trata de una lista de ficheros (opción habitual al descargar, como OPCION DE FICHERO DE ENTRADA = L, VIA PARM). En la misma, vienen los bytes del fichero descargado
Si la opción de PARM tiene FICHERO DE ENTRADA=F (OPCION P no permitida para descargas), Editran crea por defecto un fichero de salida de 99.999 bytes
Si especifica algo, predomina esto.
3
Guion separador
Alfn
1
79
Opcional
Guion
3
Espacio reservado
Alfn
1
80
Opcional
2
Registros de tipo 3
Datos de generación de XML con aceptación o rechazo (adeudos-transferencias)
3
Guion separador
Alfn
1
2
Opcional
Guion
3
Crear XML CONF (Ace-Rech)
Alfn
1
3
Obligatorio-opcional
Crear XML CONF (S/N), de aceptación ó rechazo (adeudos y transferencias), en función del XML recibido.
Si se indica N, nunca se crea un fichero de confirmación:
Si se indica S, se crea un fichero de confirmación **
(ver DSNAME del XML ACE/RECH)
3
Guion separador
Alfn
1
4
Opcional
Guion
3
DSNAME de fichero salida (DNSMAME del XML ACE/RECH)
Alfn
1-44
5
Obligatorio-opcional
Dsname del fichero XML que contiene la aceptación ó el rechazo.
1.- Si se indica CREAR XML CONF = ‘N’, se ignora lo que hubiera en este campo
2.- Si se indica CREAR XML CONF = ‘S’
2.1- Si DSNAME del XML ACE/RECH = espacios, se crea un XML de confirmación, cuyo DSNAME = XML-entrada.CNF
2.2- Si DSNAME del XML ACE/RECH contiene un DSNAME, se crea un XML de confirmación, con dicho DSNAME
Si CREAR XML CONF=’S’.
El fichero de confirmación resultante será responsabilidad del usuario cargarlo y emitirlo:
Bien creando una lista de ficheros con el mismo (y que coincida con lo indicado aquí).
Bien indicándolo en el perfil de la sesión como fichero a emitir.
También es responsable de enlazar un procedimiento de carga si fuera el caso.
3
Guion separador
Alfn
1
49
Opcional
Guion
3
Crear XML CONF con NIF
Alfn
1
50
Opcional
Crear XML CONF con NIF (S/N), incluido en la etiqueta OrgnlMsgId.
Si se indica N, se generará el OrgnlMsgId estándar
Si se indica S, se crea un fichero de confirmación con OrgnlMsgId nif+ estándar
Ejemplo de contenido en ZTBGFDAT:
En el caso anterior:
Hay un registro de tipo 0 (datos de conexión del servidor java). La ip del servidor java (USS del zos) es 111.22.33.444, puerto 994. El cliente tcp espera como máximo 5 minutos (300 segundos), a que el servidor resuelva el proceso.
Incorpora valores en la zona libre del plano
Mantiene el fichero de salida si error
Quita las validaciones de SEPA España
Valida el XML en ambos sentidos
Es una conversión de la TGSS con FF (se recomienda crearse un ZTBGFDAT especial para la conversión de los 34.14 de la TGSS).
Hay un registro de tipo 0 (comentado) igual, pero en este caso, se usa un dns.
Hay un registro de tipo 1 (datos de la transformación para PLANO a XML. Nos indica (al no poner dsname de salida), que si por ejemplo el fichero plano se llama KI.PEPE, el fichero XML se llamará KI.PEPE.XML. Además, está en el lenguaje del sistema, por lo que no se indica tabla de caracteres. Indica también que la aplicación calcule el tamaño por defecto del fichero de salida.
Hay un registro de tipo 2 (datos de la transformación para XML a PLANO. Al no indicar nada en nombre de fichero transformado, si por ejemplo el XML se llama KI.PEPE.XML, el fichero plano de salida se llamará KI.PEPE (le quita .XML). Si el XML se llama KI.PEPE, el fichero plano de salida se llamará KI.PEPE.PLN.
También indica que valide el XML contra el Esquema ya que no se ha incluido valor en el campo Validar XML y el valor por defecto es S.
Además, está en el lenguaje del sistema, por lo que no se indica tabla de caracteres. Indica también (al no poner nada), que si llega TIPO=FICHERO, &TI=F, que la aplicación calcule el tamaño por defecto del fichero de salida.
Uso de la zona libre de los registros, en el ejemplo hace uso de esta funcionalidad ya que se indica ‘S’ en el parámetro Información libre.
Uso de tamaño de registro para el fichero XML generado por el conversor, en este caso será LRECL 3000.
Mantener el fichero de salida si error, en el ejemplo en caso de error en el conversor, no se borrará el fichero de salida generado.
Se generará un fichero de confirmación (aceptación o rechazo) automáticamente.
Si se pone un nombre que sigue la misma mecánica que el de los registros 1 y 2. En el fichero de confirmación se incluirá el NIF del presentador por delante en la etiqueta OrgnlMsgId.
Uso de la zona libre de los registros
Se ha acordado con ciertos clientes el uso de algunas posiciones de las zonas libres de ciertos registros de los ficheros en formato plano. La finalidad es leer (plano a XML) o escribir (XML a plano) en ellos cierta información que de otra manera se perdería por no estar definido un campo para ella en la norma correspondiente. Dicha información es tratada por las aplicaciones de cliente que sólo interpretan ficheros en formato plano y, habitualmente, se emplean para generar a partir de ellos los ficheros de confirmación directamente en formato XML.
Para hacer uso de esta funcionalidad hay que indicar ‘S’ en el parámetro Información libre del fichero ZTBGFDAT de la llamada al programa pues por defecto el conversor no la realiza.
XML a plano
A continuación se describen los valores trasladados desde el fichero en formato XML y los registros y posición donde se dejan en el fichero de formato plano. Todas aquellas posiciones de las zonas libres que no se utilicen con esta funcionalidad seguirán manteniéndose a blancos.
Emisión de transferencias y cheques:
Se traslada el contenido de:
<GrpHdr><MsgId> a la posición 290 del registro de cabecera del ordenante.
<PmtInf><DbtrAcct><Ccy> a la posición 325 del registro de cabecera del ordenante, siempre que el valor sea distinto de “EUR”.
<GrpHdr><InitgPty><Id><OrgId><Othr><Id> a la posición 328 del registro de cabecera del ordenante.
Se escribe “XML” en la posición 598 del registro de cabecera de ordenante.
<PmtInf><PmtInfId> a la posición 23 de los registros de cabecera de transferencias SEPA, de otras transferencias o de cheques, según el tipo de bloque de los tres del que proceda el dato.
El valor del atributo Ccy de <PmtInf><CdtTrfTxInf><Amt><InstdAmt Ccy="XXX"> o de <PmtInf><CdtTrfTxInf><Amt><EqvAmt><Amt Ccy="XXX">, siempre que sea distinto de “EUR”, en la posición 502 del primer registro obligatorio de beneficiario si el bloque de origen es de Transferencia SEPA o en la 333 del mismo registro si el bloque de origen es del tipo Otras Transferencias.
<PmtInf><CdtTrfTxInf><Amt><EqvAmt><CcyOfTrf> a la posición 505 del primer registro obligatorio de beneficiario si el bloque de origen es de Transferencia SEPA o en la 336 del mismo registro si el bloque de origen es del tipo Otras Transferencias.
<PmtInf><CdtTrfTxInf><XchgRateInf><XchRate> a la posición 508 del primer registro obligatorio de beneficiario si el bloque de origen es de Transferencia SEPA o en la 339 del mismo registro si el bloque de origen es del tipo Otras Transferencias.
<PmtInf><CdtTrfTxInf><XchgRateInf><RateTp> a la posición 521 del primer registro obligatorio de beneficiario si el bloque de origen es de Transferencia SEPA o en la 352 del mismo registro si el bloque de origen es del tipo Otras Transferencias.
<PmtInf><CdtTrfTxInf><XchgRateInf><CtrctId> a la posición 525 del primer registro obligatorio de beneficiario si el bloque de origen es de Transferencia SEPA o en la 356 del mismo registro si el bloque de origen es del tipo Otras Transferencias.
<GrpHdr><CtrlSum> a la posición 41 del [Registro total general] si contiene 18 cifras.
<GrpHdr><NbOfTxs> a la posición 59 del [Registro total general] si contiene más de 8 cifras.
<PmtInfId><CtrlSum> a la posición 41 del [Registro total de transferencias SEPA], [Registro total de Otras transferencias] o [Registro total de Cheques] según corresponda por tipo de bloque, cuando contenga 18 cifras.
<PmtInfId><NbOfTxs> a la posición 59 del [Registro total de transferencias SEPA], [Registro total de Otras transferencias] o [Registro total de Cheques] según corresponda por tipo de bloque, cuando más de 8 cifras.
<SchmeNm><Prtry> (tanto de persona jurídica como de persona física) al tramo 405-440 del [Registro tercero de beneficiario opcional].
Adeudos directos (esquemas básicos y B2B):
Se escribe “XML” en la posición 598 del registro de cabecera de presentador.
Presentaciones, se traslada el contenido de:
<GrpHdr><Authstn><Prtry> a la posición 167 del [Registro cabecera de presentador].
<PmtInf><PmtInfId> a la posición 300 del [Registro cabecera de acreedor por fecha de cobro].
<PmtInf><BtchBookg> a la posición 335 del [Registro cabecera de acreedor por fecha de cobro] según la siguiente conversión: si contiene true se escribe 0 y si contiene false se escribe 1.
Sólo esquema básico: <DrctDbtTxInf><PmtId><InstrId> a la posición 365 del [Registro segundo individual opcional].
Sólo esquema básico: <OrgnlDbtrAgt><FinInstnId><BIC> o <OrgnlDbtrAgt><FinInstnId><Othr><Id> al campo 10 junto con las 6 primeras posiciones del campo libre que le sigue del [Registro cuarto individual opcional].
<DrctDbtTxInf><MndtRltdInf><ElctrncSgntr> a dos nuevos registros individuales opcionales que se escriben a continuación del último registro individual opcional existente. El primero de ellos tiene como número de dato “507” y recoge las primeras 525 posiciones del valor de la etiqueta, terminando con 65 posiciones libres. El segundo de ellos tiene como número de dato “508” y recoge las siguientes 500 posiciones del valor de la etiqueta, terminando con 90 posiciones libres.
<PmtInf><CtrlSum> a la posición 81 del [Registro total de acreedor por fecha de cobro]. Se utilizará para recoger importes de 18 cifras en total (la norma de formato plano contempla hasta 17).
<PmtInf><NbOfTxs> a la posición 99, del [Registro total de acreedor por fecha de cobro]. Se utilizará para recoger números de registros individuales cuyo valor supere las 8 cifras que contempla el formato plano.
Rechazos, información del originador. Se trasladan 11 posiciones del contenido del primero de los siguientes tags que se encuentre en el fichero:
<OrgnlGrpInfAndSts><StsRsnInf><Orgtr> <Id><OrgId><BICorBEI> o de <OrgnlGrpInfAndSts><StsRsnInf><Orgtr><Nm> o de
<OrgnlPmtInfAndSts><StsRsnInf><Orgtr><Id><OrgId><BICorBEI> o de
<OrgnlPmtInfAndSts><StsRsnInf><Orgtr><Nm> o de
<OrgnlPmtInfAndSts><TxInfAndSts><StsRsnInf><Orgtr><Id><OrgId><BICorBEI> o de
<OrgnlPmtInfAndSts><TxInfAndSts><StsRsnInf><Orgtr><Nm> a la posición 586 de cada [Registro primero individual].
Retrocesiones, se traslada el contenido de:
<OrgnlPmtInfAndRvsl><OrgnlCtrlSum> a la posición 81 del [Registro total de acreedor por fecha de cobro]. Se utilizará para recoger importes de 18 cifras en total (la norma de formato plano contempla hasta 17).
<OrgnlPmtInfAndRvsl><OrgnlNbOfTx> a la posición 99 del [Registro total de acreedor por fecha de cobro]. Se utilizará para recoger números de registros individuales cuyo valor supere las 8 cifras que contempla el formato plano.
Presentaciones y retrocesiones, se traslada el contenido de:
<GrpHdr><CtrlSum> a la posición 38, del [Registro total general]. Se utilizará para recoger importes de 18 cifras en total (la norma de formato plano contempla hasta 17)
<GrpHdr><NbOfTxs> a la posición 56, del [Registro total general] si la cantidad supera las 8 cifras que contempla el formato plano.
Rechazos y devoluciones, se traslada el contenido de:
<OrgnlPmtInfAndSts><OrgnlCtrlSum> a la posición 81 del [Registro total de acreedor por fecha de cobro/devolucion]. Se utilizará para recoger importes de 18 cifras en total (la norma de formato plano contempla hasta 17).
<OrgnlPmtInfAndSts><OrgnlNbOfTx> a la posición 99 del [Registro total de acreedor por fecha de cobro/devolucion]. Se utilizará para recoger números de registros individuales cuyo valor supere las 8 cifras que contempla el formato plano.
<OrgnlGrpInfAndSts><OrgnlCtrlSum> a la posición 38 del [Registro total general]. Se utilizará para recoger importes de 18 cifras en total (la norma de formato plano contempla hasta 17).
<OrgnlGrpInfAndSts><OrgnlNbOfTxs> a la posición 56 del [Registro total general]. Se utilizará para recoger números de registros individuales cuyo valor supere las 8 cifras que contempla el formato plano.
Plano a XML
Por su parte, cuando sea el cliente quien genere los ficheros de formato plano, podrá hacer uso de ciertas zonas libres para alojar en ellas información que de otra manera sería imposible trasladar hasta el fichero XML que resulta en la conversión. Son las siguientes:
Emisión de transferencias y cheques:
Se trasladará el contenido de:
70 posiciones, comenzando en la 290, de la Cabecera de Ordenante a <InitgPty><Nm>. Esta funcionalidad se utiliza para poder transformar a un único XML varios ficheros lógicos planos que no coinciden en los nombres de ordenante.
4 posiciones, comenzando en la 360, de la Cabecera de Ordenante a tantos elementos <PmtInf><PmtInfId> como haya que construir en el fichero XML resultante. Este mapeo posibilita informar y conservar este concepto (que no está contemplado en ninguno de los dos formatos) para que pueda ser devuelto en los extractos bancarios enviados por La Caixa (AEB 43).
12 posiciones, comenzando en la 364, de la Cabecera de Ordenante a <InitgPty><Id><OrgId> o a <InitgPty><Id><PrvtId>, según corresponda. Esta funcionalidad se utiliza para poder convertir varios ficheros lógicos planos que no coinciden en los identificadores de ordenante en un único fichero XML, siendo éste el Id del Presentador que se informará.
Cuando en la posición 23 del [Registro de Cabecera de Transferencias SEPA] se encuentra el valor H, se completará <PmtInf><PmtTpInf><InstrPtry> con el código HIGH en el fichero XML resultante.
18 posiciones, comenzando en la 41 del [Registro total general], a <GrpHdr><CtrlSum>. Se utilizará para recoger importes de 18 cifras en total (la norma de formato plano contempla hasta 17).
15 posiciones, comenzando en la 59 del [Registro total general], a <GrpHdr><NbOfTxs>. Se utilizará para recoger números de registros individuales cuyo valor supere las 8 cifras que contempla el formato plano.
18 posiciones, comenzando en la 41 del [Registro total de transferencias SEPA], [Registro total de Otras transferencias] o [Registro total de Cheques] según corresponda por tipo de bloque, a <PmtInfId><CtrlSum>. Se utilizará para recoger importes de 18 cifras en total (la norma de formato plano contempla hasta 17).
15 posiciones, comenzando en la 59 del [Registro total de transferencias SEPA], [Registro total de Otras transferencias] o [Registro total de Cheques según corresponda por tipo de bloque, a <PmtInfId><NbOfTxs>. Se utilizará para recoger números de registros individuales cuyo valor supere las 8 cifras que contempla el formato plano.
Adeudos directos (esquemas básicos y B2B):
Presentaciones, se traslada el contenido de:
Sólo esquema básico: el contenido del campo 10 junto con las seis primeras posiciones del campo libre del [Registro cuarto individual opcional] a <OrgnlDbtrAgt>><FinInstnId><BIC> si se trata de un BIC o a <OrgnlDbtrAgt><FinInstnId><Othr><Id> en cualquier otro caso.
18 posiciones, comenzando en la 81, del [Registro total de acreedor por fecha de cobro] a <PmtInf><CtrlSum>. Se utilizará para recoger importes de 18 cifras en total (la norma de formato plano contempla hasta 17).
15 posiciones, comenzando en la 99, del [Registro total de acreedor por fecha de cobro] a <PmtInf><NbOfTxs>. Se utilizará para recoger números de registros individuales cuyo valor supere las 8 cifras que contempla el formato plano.
Rechazos, se traslada el contenido de:
11 posiciones, comenzando en la 167, del registro de [Cabecera de presentador] a <OrgnlGrpInfAndSts><StsRsnInf><Orgtr> <Id><OrgId><BICorBEI> si es un BIC, o a <OrgnlGrpInfAndSts><StsRsnInf><Orgtr><Nm> si no lo es.
4 posiciones, comenzando en la 178, del registro de [Cabecera de presentador] a <OrgnlGrpInfAndSts><StsRsnInf><Rsn><Cd>
11 posiciones, empezando en la 370, del registro de [Cabecera de acreedor por fecha de cobro], a <OrgnlPmtInfAndSts><StsRsnInf><Orgtr><Id><OrgId><BICorBEI> si es un BIC, si no lo es a <OrgnlPmtInfAndSts><StsRsnInf><Orgtr><Nm>
4 posiciones, empezando en la 381, del registro de [Cabecera de acrredor por fecha de cobro], a <OrgnlPmtInfAndSts><StsRsnInf><Rsn><Cd>
11 posiciones, comenzando en la 586, del [Registro primero individual] a <OrgnlPmtInfAndSts><TxInfAndSts><StsRsnInf><Orgtr><Id><OrgId><BICorBEI> si es un BIC, si no lo es a <OrgnlPmtInfAndSts><TxInfAndSts><StsRsnInf><Orgtr><Nm>
Retrocesiones, se traslada el contenido de:
18 posiciones, comenzando en la 81, del [Registro total de acreedor por fecha de cobro] a <OrgnlPmtInfAndRvsl><OrgnlNbOfTx>. Se utilizará para recoger importes de 18 cifras en total (la norma de formato plano contempla hasta 17).
15 posiciones, comenzando en la 99, del [Registro total de acreedor por fecha de cobro] a <OrgnlPmtInfAndRvsl><OrgnlNbOfTx>. Se utilizará para recoger números de registros individuales cuyo valor supere las 8 cifras que contempla el formato plano.
Presentaciones y retrocesiones, se traslada el contenido de:
18 posiciones, comenzando en la 38, del [Registro total general] a <GrpHdr><CtrlSum>. Se utilizará para recoger importes de 18 cifras en total (la norma de formato plano contempla hasta 17).
15 posiciones, comenzando en la 56, del [Registro total general] a <GrpHdr><NbOfTxs>. Se utilizará para recoger números de registros individuales cuyo valor supere las 8 cifras que contempla el formato plano.
Rechazos y devoluciones, se traslada el contenido de:
35 posiciones, comenzando en la 335, del registro de [Cabecera de acreedor por fecha de cobro] a <OrgnlPmtInfAndSts><OrgnlPmtInfId>.
18 posiciones, comenzando en la 81, del [Registro total de acreedor por fecha de cobro/devolución] a <OrgnlPmtInfAndSts><OrgnlNbOfTx>. Se utilizará para recoger importes de 18 cifras en total (la norma de formato plano contempla hasta 17).
15 posiciones, comenzando en la 99, del [Registro total de acreedor por fecha de cobro/devolución] a <OrgnlPmtInfAndSts><OrgnlNbOfTx>. Se utilizará para recoger números de registros individuales cuyo valor supere las 8 cifras que contempla el formato plano.
18 posiciones, comenzando en la 38, del [Registro total general] a <OrgnlGrpInfAndSts><OrgnlCtrlSum>. Se utilizará para recoger importes de 18 cifras en total (la norma de formato plano contempla hasta 17).
15 posiciones, comenzando en la 56, del [Registro total general] a <OrgnlGrpInfAndSts><OrgnlNbOfTxs>. Se utilizará para recoger números de registros individuales cuyo valor supere las 8 cifras que contempla el formato plano.
Devoluciones, se traslada el contenido de:
Se contempla un [Registro Segundo Individual Opcional] que comenzará por 2319143004. Este registro no existe en la norma pero es necesario para alojar la información que a continuación se detalla y que no es posible mapear al [Registro primero individual obligatorio], por carecer éste de espacio suficiente en el campo libre.
35 posiciones comenzando en la posición 11, del [Registro Segundo Individual Opcional] a la etiqueta <TxInfAndSts><StsId>
35 posiciones comenzando en la 46, del [Registro Segundo Individual Opcional], a la etiqueta <TxInfAndSts><OrgnlInstrId>
105 posiciones, comenzando en la 81, del [Registro total general] a <OrgnlGrpInfAndSts><StsRsnInf>< AddtlInf>.
El conversor buscará en primer lugar esta información en los campos libres. Si estuvieran vacíos, se efectuará el mapeo tal y como se hace habitualmente para cada uno de esos campos.
Registro de confirmación o rechazo de adeudos y transferencias:
§ Si el usuario lo indica, (registro de tipo 3), al descargar el xml, se genera en ciertos casos, un ´fichero de confirmación o de rechazo xml, que de forma automática se puede encadenar con un procedimiento Editran para generar la respuesta automática (conversiones Xml a Plano de las normas 3414 y 19 de tipo Presentaciones).
Si es posible descargar el xml, se genera un fichero de aceptación (aunque haya warning en la descarga xml)
Si no es posible descargar el xml, se genera un fichero de rechazo. Ejemplo:
PAIN002. Partiendo de los datos del fichero plano o xml registro 01 y 99, se generaría un xml
(ACCP - RECEPCION Y VALIDACION CORRECTA o RJCT – RECHAZADO) con ciertos datos que venían en el xml original:
La lista de variables conocidas por la aplicación es la siguiente (Tabla 3):
Variable
Significado
%O
DSN en origen
%E
Década
%Y
Último dígito del año
%A
Dos últimos dígitos del año (aa)
%M
Mes en dos dígitos (mm)
%X
Mes en un carácter (1,2,3,4,5,6,7,8,9,O,N,D)
%D
Día del mes (dd)
%H
Hora (hhmmss)
%C
Número de orden del fichero recibido (nn)
%K
Número de orden del fichero recibido (nnnn)
%R
Los 7 últimos caracteres del código del extremo remoto
%P
Código de aplicación
Si se informa el parámetro con NIF, el fichero de confirmación llevará la etiqueta OrgnlMsgId con el NIF en las primeras posiciones.
Ejemplo de contenido en ZTBGFDAT:
En el caso anterior:
Hay un registro de tipo 0 (datos de conexión del servidor java). La ip del servidor java (USS del zos) es 111.22.33.444, puerto 994. El cliente tcp espera como máximo 5 minutos (300 segundos), a que el servidor resuelva el proceso.
Hay un registro de tipo 0 (comentado) igual, pero en este caso, se usa un dns.
Hay un registro de tipo 1 (datos de la transformación para PLANO a XML. Nos indica (al no poner dsname de salida), que si por ejemplo el fichero plano se llama KI.PEPE, el fichero XML se llamará KI.PEPE.XML. Además, está en el lenguaje del sistema, por lo que no se indica tabla de caracteres. Indica también que la aplicación calcule el tamaño por defecto del fichero de salida.Hay un registro de tipo 2 (datos de la transformación para XML a PLANO. Al no indicar nada en nombre de fichero transformado, si por ejemplo el XML se llama KI.PEPE.XML, el fichero plano de salida se llamará KI.PEPE (le quita .XML). Si el XML se llama KI.PEPE, el fichero plano de salida se llamará KI.PEPE.PLN.
Tambien indica que valide el XML contra el Esquema ya que no se ha incluido valor en el campo Validar XML y el valor por defecto es S.
Además, está en el lenguaje del sistema, por lo que no se indica tabla de caracteres. Indica también (al no poner nada), que si llega TIPO=FICHERO, &TI=F, que la aplicación calcule el tamaño por defecto del fichero de salida.
Uso de la zona libre de los registros, en el ejemplo hace uso de esta funcionalidad ya que se indica ‘S’ en el parámetro Información libre.
Uso de tamaño de registro para el fichero XML generado por el conversor, en este caso será LRECL 3000.
Mantener el fichero de salida si error, en el ejemplo en caso de error en el conversor, no se borrará el fichero de salida generado.
Se generará un fichero de confirmación (aceptación o rechazo) automáticamente. Si se pone un nombre que sigue la misma mecánica que el de los registros 1 y 2.
Última actualización