Conversor de planos formato moderno a XML y viceversa...

EDITRAN/XML SEPA 5.X

Conversor de planos formato moderno a XML y viceversa

CICS-IMS

Manual de usuario

INDRA 20 de septiembre de 2018

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario ÍNDICE

INDRA. Todos los derechos reservados. EDITRAN/XML SEPA 5.X

1. INTRODUCCION ................................................................................................................................... 1-1

2. REQUISITOS E INSTALACIÓN.............................................................................................................. 2-1

2.1. Requisitos. ..................................................................................................................................................... 2-1

2.2. Fichero de licencia ......................................................................................................................................... 2-1

2.3. Normativa y restricciones. ............................................................................................................................ 2-1

A tener cuenta ............................................................................................................................................................. 2-2

2.4. Instalación: ..................................................................................................................................................... 2-6 2.4.1. CICS............................................................................................................................................................................................................................................... 2-6 2.4.2. ZOS IMS. ..................................................................................................................................................................................................................................... 2-6 2.4.3. ZOS COMUN (FICHERO DE USUARIO) ............................................................................................................................................................................ 2-6 2.4.4. ZOS COMUN (JAVA) ................................................................................................................................................................................................................ 2-7 2.4.5. Descarga de software. ......................................................................................................................................................................................................... 2-7 2.4.6. Inserción del paquete en los servicios UNIX del zos. ............................................................................................................................................. 2-7 2.4.7. Instalación del paquete. ...................................................................................................................................................................................................... 2-8

3. DESCRIPCIÓN DE LA FUNCIONALIDAD. ............................................................................................. 3-1

3.1. Uso de listas de ficheros por EDITRAN. ....................................................................................................... 3-1

3.2. Parametrización EDITRAN. ............................................................................................................................ 3-2

3.3. Casos de uso de los conversores. ................................................................................................................. 3-4

3.4. Datos de entrada-salida para los conversores. .......................................................................................... 3-4 3.4.1. Datos pasados al conversor mediante PARM. ........................................................................................................................................................... 3-6 3.4.2. Datos pasados al conversor mediante fichero de usuario (ZTBGFDAT). ....................................................................................................... 3-8

XML a plano ................................................................................................................................................................ 3-13

Plano a XML ............................................................................................................................................................... 3-15

4. ADAPTACIÓN PARA PAGOS TELEMÁTICOS DE LA TGSS ................................................................. 4-20

4.1. Recepción de los ficheros ........................................................................................................................... 4-20

4.2. Envío de la confirmación ............................................................................................................................. 4-21

5. JCLS Y PROCEDIMIENTOS. ................................................................................................................ 5-23 5.1.1. JCLS. ........................................................................................................................................................................................................................................... 5-23 5.1.2. Procedimientos. ................................................................................................................................................................................................................... 5-25

5.1.2.1. Previo a emisión..................................................................................................................................................................................................... 5-25 5.1.2.2. Posterior a recepción. .......................................................................................................................................................................................... 5-27

6. OTROS. ................................................................................................................................................. 6-1

6.1. Llamada a java en modo comando. .............................................................................................................. 6-1

7. ANEXO. ................................................................................................................................................ 7-1

7.1. Transformación con Warnings. ..................................................................................................................... 7-1

7.2. Códigos de resultado del servidor. ............................................................................................................... 7-1

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 1.INTRODUCCION

INDRA. Todos los derechos reservados. EDITRAN/XML SEPA 5.X Pág. 1-1

1. INTRODUCCION

La normativa SEPA exige intercambiar las siguientes normas en formato XML:

Adeudos Directos SEPA en fichero electrónico – Esquema Básico (19.14)

Adeudos Directos SEPA en fichero electrónico – Esquema B2B (19.44)

Órdenes en fichero para emisión de transferencias y cheques en euros (34.14)

Se han desarrollado unos conversores que permiten:

o Transforman los ficheros formato plano moderno (longitud de registro 600) a XML

o Transforman XML a ficheros formato plano moderno (longitud de registro 600)

o Generar xml de confirmación o rechazo a partir de un xml recibido (SCT y SDD)

o Tratar una nueva versión del CustomerDirectDebitInitiationV02 (pain.008.001.02) y

generar una versión del C19.14+ que ha publicado CECA.

o SEPARADOR XML

o SEPARADOR ficheros planos

Estos conversores, podrán llamarse:

En el previo a emisión, con un nuevo procedimiento (ZTBGP1CX) que lleva un nuevo

paso, previo al paso A1P

En el posterior a recepción, con un nuevo procedimiento (ZTBGP4CX) que lleva un nuevo

paso, posterior al paso A4P y ZTBGLFE.

En un jcl que se proporciona al efecto: ZTBGJXML (válido para clientes que deseen lanzar

el conversor para ficheros no enviados/recibidos por EDITRAN)

Los conversores (programa ZTBXBXML), llaman a un programa cliente TCP (ZTBXBITS), que

se conecta contra el servidor java, residente en los servicios UNIX del zos. Le indican:

1. Datos para conexión al servidor

a. IP y puerto del servidor java

b. Tiempo de espera de respuestas del servidor java

2. Datos de la petición

a. Función (X) plano a xml, (P) xml a plano

b. Dsname de fichero de entrada

c. Dsname de fichero de salida

d. Tabla de traducción (sólo en caso necesario)

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 2.Requisitos e instalación.


2. Requisitos e instalación.

2.1. Requisitos.

1. El usuario, debe crear un fichero (ó n), con ciertos parámetros para pasar al conversor

(detallado en este documento).

2. Disponer de versión EDITRAN 5.0.2 ó superior

3. Licencia. Haber contratado el producto EDITRAN/XML para SEPA.

4. JAVA.

a. Se debe tener instalado, al menos, IBM 31-bit SDK for z/OS, Java Technology

Edition, V6 y tener acceso al JZOS para el acceso a ficheros de MVS, los ficheros

para ello se encuentran en $JAVA_HOME/lib/ext.

b. Un servidor TCP java de los servicios UNIX, el cual debe disponer de una

dirección y un puerto en el que escuchar las peticiones realizadas desde el

EDITRAN en MVS.

c. Acceso a los servicios UNIX del ZOS

EDITRAN, no realiza una validación de los ficheros de aplicación, sólo hace la

conversión de plano a XML ó de XML a plano.

2.2. Fichero de licencia

El programa EDITRAN/SEPA necesita para funcionar un fichero de licencia llamado

licenciaSEPA.dat que debe estar situado en la carpeta raíz SEPA.

Este fichero de licencia se debe pedir al Soporte de EDITRAN indicando el hostid y el

sistema operativo de la máquina, que se obtiene por dos formas distintas:

Ejecutando el fichero checkLic.bat/checkLic.sh que hay en la carpeta SEPA/scripts

de su Sistema Operativo. Debe ejecutar este fichero de comandos desde la

carpeta donde está situado y por pantalla debe devolver el resultado de

comprobar la licencia.

Si se intenta ejecutar el programa EDITRAN/SEPA sin licencia el programa fallará

por licencia incorrecta quedando en el log el hostid y el sistema operativo de la

máquina.

2.3. Normativa y restricciones.

Según sea su formato, plano o XML, los ficheros tratados por EDITRAN/SEPA (tanto el que

tiene los datos de origen como el fichero resultado de la transformación) cumplirán una de las

siguientes normas:

Ficheros planos: SEPA – 14 (nuevo formato con registros de longitud 600)

Documento “Órdenes en fichero para emisión de transferencias y cheques en

euros”. Serie normas y procedimientos bancarios Nº 34-14, versión Noviembre

2012



Documento “Adeudos directos SEPA en formato electrónico - Esquema Básico”,

Serie normas y procedimientos bancarios Nº 19-14, versión Noviembre 2012

Documento “Adeudos directos SEPA en formato electrónico - Esquema B2B”,

Serie normas y procedimientos bancarios Nº 19-44, versión Noviembre 2012

Ficheros XML: órdenes en formato ISO 20022

Documento Órdenes en formato ISO 20022 para emisión de transferencias y

cheques en euros. Serie normas y procedimientos bancarios. Guía de

Implantación v1.0, Noviembre 2012. Sigue el esquema pain.001.001.03.xsd

Documento Órdenes en formato ISO 20022 para emisión de adeudos directos

SEPA – Esquema Básico. Serie normas y procedimientos bancarios. Guía de

Implantación, Noviembre 2012. Contiene cuatro mensajes distintos:

Presentación de adeudos, sigue el esquema pain.008.001.02

Rechazo de la operación, sigue el esquema, pain.002.001.03

Devolución, también sigue el esquema pain.002.001.03

Retrocesión para reintegro, sigue el esquema pain.007.001.02

Documento Órdenes en formato ISO 20022 para emisión de adeudos

directos SEPA – Esquema B2B. Serie normas y procedimientos bancarios.

Guía de Implantación, Noviembre 2012. Contiene los mismos cuatro

mensajes que el anterior y siguen los mismos esquemas.

A tener cuenta

Cuando el usuario utilice EDITRAN/SEPA debe saber:

Tanto en el caso de los ficheros planos como en el de los ficheros XML el

programa no realiza ninguna validación respecto a la coherencia de su

contenido (suma de totales de los importes, etc.). Por el contrario sí valida el

formato en ambos casos: secuencia de registros correcta en el formato plano y

validación contra el esquema correspondiente en el formato XML.

En cuanto al contenido, las definiciones de las nuevas normas planas no son

completamente simétricas respecto a las normas XML, por eso habrá conceptos,

campos, que se perderán al realizar las conversiones en uno y otro sentido. Esta

particularidad no debe entenderse como una limitación o defecto de

EDITRAN/SEPA, sino que es una característica de las propias normas. En

cualquier caso dicha “pérdida de datos” en ningún caso se refiere a conceptos

esenciales u obligatorios sino a informaciones extra que sí se contemplan en

las normas XML.

Dentro de esta asimetría entre los formatos, EDITRAN/SEPA siempre busca

conservar el máximo de información al trasladar los datos de uno a otro

formato. Por ejemplo, si en el formato XML cierto campo es opcional, siempre

que dicha información esté contenida en el formato plano de origen, el

conversor lo incluirá en el destino.

Algunas entidades han definido particularidades a la hora de generar sus

ficheros, tanto los planos como los XML. Siempre que dichas restricciones se

refieran al contenido y no incumplan factores propios del formato (estructura,

longitudes, etc) no tendrán impacto alguno en el uso del conversor.



En el formato XML existe un mensaje para la información del estado del pago

(según esquema pain.002.001.03) para el que SEPA no ha definido norma en

formato plano, por tanto EDITRAN/SEPA no podrá transformar dicho mensaje.

Todavía hay entidades que continúan enviando los formatos de los antiguos

cuadernos AEB, con longitudes 72 (AEB 34) y 162 (AEB 19). Podrán hacerlo

hasta febrero de 2014, si bien estos ficheros no serán tratados por

EDITRAN/SEPA.

EDITRAN, a modo de ejemplo, transmitirá:

o pain.008.001.02 Inicio Adeudo Directo (recibido por EDITRAN desde aplicaciones de

negocio)

o pain.002.001.03 Comunicación de Estado

En el formato pain.002.001.03 Comunicación de Estado Transferencia (enviado a

aplicaciones de negocio), no existe norma plana, por lo que EDITRAN no transformará

este contenido.

o pain.007.001.02 Solicitud de Cancelación

o pain.002.001.03 Comunicación de Devoluciones (enviado a aplicaciones de negocio)

o pain.001.001.03 Inicio Transferencia (recibido por EDITRAN desde aplicaciones de

negocio)

o AMPLIACIÓN versión del C19.14+ que ha publicado CECA.

consiste en adaptar el conversor de los xml de adeudos Sepa para incluir nuevas

etiquetas que permitan informar conceptos ampliados (hasta 640 caracteres) para

generar un nuevo cuaderno C19.14+ que se diferencia del actual en que incorpora

un nuevo tipo de registro para incluir los conceptos con más de los 140 caracteres

que se permiten actualmente.

Por ello existirá un conversor (licenciado) capaz de tratar una nueva versión del

CustomerDirectDebitInitiationV02 (pain.008.001.02) y generar una versión del

C19.14+ que ha publicado CECA.

o SEPARADOR XML**

Esta funcionalidad es un añadido a EDITRAN/SEPA, por tanto, esta funcionalidad

también requiere una licencia adicional para poder usarse. En el caso de no tener esta

licencia adicional si está interesado se debe poner en contacto con el Soporte de

EDITRAN.

Los archivos Xml no están pensados para ir anidados dentro de un solo fichero, ya que el

fichero resultante no es un fichero válido. En respuesta a algunos clientes, se ha añadido

una nueva funcionalidad que convierte esos ficheros con varios Xml anidados en un

fichero con sus correspondientes planos anidados.

o SEPARADOR PLANOS**

De manera análoga a la funcionalidad anterior,el conversor puede tratar ficheros de

entrada de formato plano que incluyan varios ficheros lógicos. En esta caso, el resultado



de la conversión será un fichero cuyo contenido podrá ser un único fichero XML lógico o

varios, dependiendo de cómo se haya configurado el parámetro param.juntar.xml

descrito en el apartado 2.4.7 o en el fichero de parámetros ZTBGFDAT 3.4.2.

Primero mira el fichero de parámetros ZTBGFDAT, si éste no está informado mira en

Configuracion.properties, si tampoco aparece hace el defecto.

Para utilizar estas funcionalidades de los separadores, que requieren licencias

específicas, en vez de iniciar EDITRAN/SEPA usando los scripts start.sh y stop.sh, se

deben usar los scripts alternativos incluidos en la carpeta /scripts; startSeparador.sh y

stopSeparador.sh. Estos scripts sustituyen a los anteriores.

Antes de poder usar estos scripts, se debe configurarlos primero. La forma de

configurarlos es exactamente la misma que en los scripts para EDITRAN/SEPA (apartado

2.4.7 paso d) y e) ).

**Estas 2 funcionalidades necesitan generar unos ficheros auxiliares temporales en la

parte UNIX que se borran al acabar el proceso, el nombre de los auxiliares lo crea siempre

con el nombre de entrada seguido de timestamp.

En cuanto al directorio temporal, si no se dice nada, cogerá el directorio /tmp por defecto

de la máquina. Si se necesita que sea otro se le pasa con la variable java.io.tmpdir en la

llamada a JAVA( en el start o por comando).

o Mensaje de respuesta automático

este campo sirve para generar mensajes de respuesta cuando se reciben ciertas normas

SEPA, aunque sólo se puede usar para conversiones XML a Plano de las normas 3414 y 19 de

tipo Presentaciones, en las que se genera este fichero. El código devuelto en <StsRsnInf>

informa de si se ha podido realizar la conversión (ACCP), o no (RJCT). El valor de este campo es

el nombre del fichero de respuesta automático. Por defecto no se crea el fichero de respuesta

EDITRAN, no convierte tampoco la norma 57 (cobros en ventanilla bancaria)

EDITRAN, con los conversores, trata siempre planos en formato “moderno”, con longitudes

de registro 600. Todavía hay entidades que usan el formato antiguo, con longitud 72 ó 162, y

estos ficheros no son tratados en los conversores descritos.

Algunas entidades, introducen “particularidades” en los ficheros XML ó planos. En principio,

habría que valorar técnicamente esas adaptaciones, ver si son posibles con el software

distribuido, y si no fuera el caso valorarlas económicamente.

Si las mismas se refieren al contenido de los ficheros xml, a los datos, pero no afectan a la

estructura que exige el esquema, longitudes de los campos, etc., en principio, el conversor

podría servir tal cual está son las entidades, las que siguen su propio reglamento a la hora de

confeccionar los ficheros, si bien hay que tener en cuenta ciertos aspectos:

Uno es que hay que ser conscientes de que la información que recoge el xml es

un poco más extensa que la que puede alojar el fichero plano, por lo que esos

datos (pocos), se pierden cuando la transformación es en ese sentido o no

aparecen cuando son en el sentido contrario.

Otro aspecto es el contrario, por ejemplo, puede que alguna normativa indique

que no se va a utilizar la etiqueta <CtrlSum> en la cabecera del fichero xml. Dicha

etiqueta recoge la suma de los importes de todas las operaciones del fichero y

efectivamente según el esquema no es obligatorio rellenarla, sin embargo



nuestro conversor siempre la añade puesto que en el fichero plano ese dato sí es

obligatorio y la pauta que estamos siguiendo, por el momento, es la de que

se pierda el mínimo de información posible en ambos sentidos.

Otro ejemplo. La prioridad de la instrucción no está en el plano, por tanto, los xml

que generamos no incluyen ese dato, por lo que se supone el defecto que es

prioridad normal, y por tanto si el xml que tratamos lo lleva, en el plano se pierde.

En general el fichero en formato xml está preparado para recoger más

información que la especificada en las normas planas, por ejemplo en la norma

xml de la norma 34 hay un identificador de mensaje que se pierde al llevarlo a

plano, también en el xml se recogen la fecha y la hora de creación mientras que

en el plano sólo es posible almacenar la fecha, en la norma plana 34-14 no se

recoge la figura de presentador sobre la que en cambio sí se puede dar

información en la norma xml, la clase de pago que se recoge en el registro de

balanza de pagos de la norma plana 34-14 no se puede trasladar a la norma xml,

en la norma plana no existe campo donde informar del BIC de la entidad del

ordenante, dato que sí se refleja en la norma xml.

Ampliación de la funcionalidad:

Generar una versión del c19.14+ que ha publicado CECA.

Permite convertir los ficheros planos de formato SEPA longitud de registro 600) a

XML ISO 20022 y viceversa.

Esta ampliación consiste en adaptar el conversor de los xml de adeudos Sepa para

incluir nuevas etiquetas que permitan informar conceptos ampliados (hasta 640

caracteres) para generar un nuevo cuaderno C19.14+ que se diferencia del actual

en que incorpora un nuevo tipo de registro para incluir los conceptos con más de

los 140 caracteres que se permiten actualmente.

Por ello existirá un conversor capaz de tratar una nueva versión del

CustomerDirectDebitInitiationV02 (pain.008.001.02) y generar una versión del

C19.14+ que ha publicado CECA.

Separador XML

Esta funcionalidad es una ampliación a EDITRAN/SEPA que convierte ficheros con

varios Xml anidados en un fichero con sus correspondientes planos anidados.

Separador planos


varios planos anidados en un fichero con sus correspondientes XML anidados

Adaptaciones para los ficheros firmados de TGSS


las particularidades de la Tesorería de la Seguridad Social.



2.4. Instalación:

2.4.1. CICS.

Si licencia EDITRAN/CICS se recibe:

Licencia (si se contrata esta funcionalidad). Para instalarla debe pasar el jcl ZTBLJG02.

Ejecutables CICS: ZTBPOIF5

Ejecutables Batch: ZTBXBXML, ZTBXBITS, ZTBGBGPG y ZTBLBLLI

Procedimientos: ZTBGP1CX y ZTBGP4CX

Jcls: ZTBGJXML

2.4.2. ZOS IMS.

Si licencia EDITRAN/IMS se recibe.

Licencia (si se contrata esta funcionalidad). Para instalarla debe pasar el jcl ZTBLJG02.

Ejecutables Batch: ZTBXBXML, ZTBXBITS y ZTBGBGPG

Procedimientos: ZTBGP1X y ZTBGP4X

Jcls: ZTBGJXML

2.4.3. ZOS COMUN (FICHERO DE USUARIO)

El usuario, debe crear un fichero (ó n), ZTBGFDAT, con ciertos parámetros para pasar al

conversor (detallado en este documento).



2.4.4. ZOS COMUN (JAVA)

Para la instalación, se realizarán las siguientes actuaciones:

2.4.5. Descarga de software.

Entrar en la página web http://EDITRAN.indra.es/ y seleccionar SOFTWARE

Usuario indra, psw EDITRAN

Seleccionar zos y descargar el software XML

2.4.6. Inserción del paquete en los servicios UNIX del zos.

Enviar, en modo binario, al USS el paquete EDITRANSepaXml.rar. Puede usar cualquier

utilidad de transferencia de ficheros, como el ftp

Ejemplo de subirlo:.

1- Lo metemos en USS mediante los comandos (ejemplo de subir EDITRANSepaXml.rar):

a. cmd

b. ftp ip destino (pedirá usuario tso y password)

c. cd /u/EDITRANxsepa (directorio destino donde subiremos la aplicación).

d. binary (ftp en binario)

e. lcd c:\ (directorio origen donde se encuentra el .rar)

f. put EDITRANSepaXml.rar quit (salir)

3.- Vemos que queda en el directorio USS.

/u/ EDITRANxsepa: >ls -l total 23638

-rw-r-----+ 1 KI10139 KISNCE 12084937 Jun 25 17:07 EDITRANSepaXml.jar

http://editran.indra.es/



2.4.7. Instalación del paquete.

a) Descomprimir el archivo EDITRANSepaXml.tar en la carpeta de instalación creada para este fin p.ej. / EDITRANxsepa quedando la siguiente estructura de directorios a partir de esta:

|SEPA

|--conf

|--doc

|--lib

|--logs

|--scripts

b) Los scripts de EDITRAN/SEPA están situados en la carpeta scripts/zOS. Primero

deberíamos comprobar que los ficheros checkLic.sh, start.sh y stop.sh tienen permisos de ejecución.

c) Se ejecuta el programa checkLic.sh desde el directorio donde está situado este fichero. Nos dice si tenemos fichero de licencia, si es correcto y si no tenemos fichero nos indica el hostId y el nombre del SO con el que debemos pedir una licencia al soporte de EDITRAN. Una vez que se reciba el fichero de licencia hay que enviarla, en modo binario, al USS.

d) A continuación se edita el fichero start.sh y se da valor a las siguientes variables:

PWD=/ EDITRANsepaxml (ruta de instalación, donde se ha descomprimido)

IP="0.0.0.0" (IP en la que arranca el servidor)

PORT="7774" (PUERTO en el que está escuchando el servidor)

JAVA_HOME="/QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit" (ruta de

instalación de java) e) Posteriormente se edita el fichero stop.sh dando valor a las siguientes variables

PWD=/ EDITRANsepaxml (ruta de instalación, donde se ha descomprimido) f) Una vez hecho esto ya es posible arrancar la aplicación ejecutando el comando:

./start.sh g) Para comprobar que el Servidor ha arrancado correctamente una vez ejecutado el

comando editamos el archivo logs/out.log, y debería tener las siguientes trazas (en el puerto y la IP deberán aparecer las que hayamos configurado en el fichero):

17/04/2012 11:16:40,013 8530 INFO [main]

servers.ThreadPooledServer main - Starting Server

17/04/2012 11:16:40,031 8548 INFO [Thread-3]

servers.ThreadPooledServer openServerSocket - Port:7774

17/04/2012 11:16:40,033 8550 INFO [Thread-3]

servers.ThreadPooledServer openServerSocket -

LocalSocketAddress:/192.168.172.88:7775

17/04/2012 11:16:40,035 8552 INFO [Thread-3]

servers.ThreadPooledServer openServerSocket -

InetAddress:/192.168.172.88 h) Para parar el proceso:

./stop.sh i) Existen los ficheros Z/OS: EDITRANSepaXml.tar, para probar una posible instalación

desde cero.

j) Existe un fichero de logs del servidor en el que se puede ver la evolución de las peticiones errores etc..(logs/out.log).

k) Existen 3 ficheros en el directorio conf:



Configuracion.properties (Opcional) define ciertos parámetros opcionales del programa EDITRAN/SEPA. En z/OS este fichero no se usa porque son parámetros del JCL. Si se llama directamente al JAVA habría que informar al menos el lenguaje de la máquina.

Los distintos parámetros que se pueden configurar son:

Lenguaje de la máquina: Puede ser ‘A’ (ASCII) o ‘E’ (EBCDIC), por defecto debe

estar desactivado y que el conversor EDITRAN/SEPA lo calcule automáticamente.

Alfabeto: Es el alfabeto con el que está escrito o que se va a escribir el fichero

plano de la conversión. Los posibles valores son aquellos charset que permita Java

(por ejemplo para Java 1.6 los encodings permitidos vienen en su página web).Por

defecto usa el alfabeto de la máquina donde se ejecuta.

Validar Xml: sirve para indicar si se desea validar el XML contra su esquema,

siendo sus posibles valores S (Siempre se valida), P (se valida sólo en conversiones

de XML a Plano), X (se valida sólo de Plano a XML) o N (Nunca se valida). El valor

por defecto es S.

Atención: desactivando esta validación, los ficheros obtenidos podrían contener

errores.

Información en el campo libre: En una conversión Xml a Plano hay ciertos

campos no convertibles y este campo sirve para incluir esta información en la zona

libre del fichero plano. La información que escribe en la zona libre se explica en

otra sección del manual. Su valor puede ser ‘S’ (Sí) o ‘N’ (No), por defecto no

escribiendo en el campo libre.

Mantener fichero de salida en caso de error: En una conversión incorrecta el

fichero de salida no se crea ya que su valor es inválido. Este campo indica su

queremos conservar el fichero de salida aunque la conversión haya sido incorrecta,

siendo sus posibles valores "S" para conservarlo y "N" para borrarlo. Por defecto se

borra el fichero de salida.

Mensaje de respuesta automático: Este campo sirve para generar mensajes de

respuesta cuando se reciben ciertas normas SEPA, aunque sólo se puede usar para

conversiones Xml a Plano de las normas 3414 y 19 de tipo Presentaciones, en las

que se genera este fichero. El valor de este campo es el nombre del fichero de

respuesta automático. Por defecto no se crea el fichero de respuesta.

Quitar validaciones: Para usar este parámetro se debe tener licencia para ello, ya

que es un campo desarrollado especialmente a petición. Sirve para ignorar

validaciones obligatorias del Xml que no están impuestas por el esquema XSD, sino

por la norma SEPA España. El campo puede valer "S" para ignorar las validaciones

obligatorias por SEPA España del Xml y "N" para validar la norma SEPA España. Por

defecto no las ignora.

param.juntar.xml (Juntar XML): este parámetro permite definir el

comportamiento del conversor en transformaciones de ficheros de entrada de

formato plano que incluyan más de un fichero lógico. Existen dos posibilidades: a)

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. Para esta opción se configurará el

valor S. b) obtener un fichero de salida con tantos documentos XML lógicos como

como ficheros lógicos de formato plano tiene el original. Para esta opción se

indicará el valor N. El valor por defecto es S. Atención: para configurar el

http://docs.oracle.com/javase/6/docs/technotes/guides/intl/encoding.doc.html



parámetro con el valor N es imprescindible disponer de la licencia correspondiente

(véase el apartado de este manual).

param.cabecera (Cabecera de Transmisión): para las conversiones de XML a

plano de la norma 34-14, este parámetro indica si se desea incluir una cabecera

adicional al principio del fichero resultante. Los valores posibles del parámetro son

T para escribir la cabecera de la Tesorería General de la Seguridad Social (véase

apartado 10 de este manual) y N para no hacerlo, siendo éste el valor por defecto.

Cuando este parámetro tiene el valor T, el conversor ignora el parámetro

param.resp.auto para los ficheros XML 34-14. Entidades.properties(opcional) es la Plantilla de entidades.

El uso de este fichero es opcional y configura una fuente de datos extra necesaria para que la conversión del formato plano a XML sea completa y correcta. Cuando este fichero no esté definido, o los datos que se busquen no se encuentren, las etiquetas correspondientes de los formatos XML quedarán vacías o con el literal “NOTPROVIDED” según permite la norma en cada caso.

En concreto permite informar el BIC de la entidad del ordenante de la norma ISO de

transferencias así como el BIC de la entidad del acreedor de la norma ISO de adeudos. Pueden apuntarse en la lista tantas entidades como sean necesarias.

El fichero contendrá exclusivamente relaciones entre códigos BIC y la pareja de números

“entidad + oficina” con los que se corresponden. Para entidades españolas el número “entidad + oficina” indicado se buscará en las posiciones desde la 4 a la 11, empezando a contar por 0, de las cuentas IBAN (comienzan por "ES") correspondientes a la figura de la que se desea informar del BIC (acreedor para adeudos y ordenante para transferencias) en los registros correspondientes del fichero en formato plano.

Ejemplo de localización: ES0001234567000000000000 Contenido inicial del fichero: #Ejemplo #bic.0=ABCDEFGHXXX #entyof.0=01234567 bic.1= entyof.1= bic.2= entyof.2=

Se pueden sustituir las cuatro cifras de la oficina por la máscara ‘*’ para asociar todas las

oficinas de una entidad a un mismo BIC.

#entyof.0=01234567 -- EntidadOficina

O

#entyof.0=0123* -- Entidad*

Así mismo, el fichero se puede utilizar también con cuentas portuguesas.



log4j.properties es la información de las características del log. Por defecto el log está

configurado de la forma en que para cada conversión de ficheros se generen dos informaciones de log situadas en la carpeta logs, uno en el log general de EDITRAN/SEPA llamado out.log y otro particular propio para cada fichero con nombre igual a su fichero de entrada.

Este fichero es editable para poder ajustarse a lo que pueda pedir el cliente. Por

ejemplo, en el caso de que queramos hacer las siguientes operaciones:

- Desactivar algún log: Eliminar su nombre (EDISEPAGENERAL o

EDISEPAFICHERO) de las propiedades del log (log4j.logger, log4j.logger.iaik,

log4j.logger.javax, log4j.logger.com.indra.mmdd o

log4j.logger.com.indra.mmdd.EDITRAN.parser).

- Editar el log general: Podemos modificar desde el nombre del log

(log4j.appender.EDISEPAGENERAL.File), su tamaño máximo

(log4j.appender.EDISEPAGENERAL.MaxFileSize) o el número de ficheros históricos

q se guardan (log4j.appender.EDISEPAGENERAL.MaxBackupIndex).

- Añadir algún log más: Si quiere realizar esta tarea debe seguir la

configuración de logs de log4j bajo su criterio. Contenido inicial del fichero: #Para desactivar cualquiera de los logs debe eliminar su nombre (EDISEPAGENERAL o EDISEPAFICHERO) en las

propiedades del log log4j.logger, log4j.logger.iaik, log4j.logger.javax, log4j.logger.com.indra.mmdd o

#log4j.logger.com.indra.mmdd.EDITRAN.parser

log4j.logger = INFO, EDISEPAGENERAL

log4j.logger.iaik = INFO, EDISEPAGENERAL

log4j.logger.javax = INFO, EDISEPAGENERAL

log4j.logger.com.indra.mmdd = INFO, EDISEPAGENERAL

log4j.logger.com.indra.mmdd.EDITRAN.parser = INFO, EDISEPAFICHERO

log4j.additivity.com.indra.mmdd =false

#Log general del programa. Incluye todos las conversiones de ficheros. Si quiere modificar el tamaño de log

debe #modificar la propiedad log4j.appender.MaxFileSize. Si quiere modificar el numero de ficheros historicos

guardados #de log modificar la #propiedad log4j.appender.MaxBackupIndex

log4j.appender.EDISEPAGENERAL=org.apache.log4j.RollingFileAppender

log4j.appender.EDISEPAGENERAL.File=logs/out.log

log4j.appender.EDISEPAGENERAL.MaxFileSize=2000KB

log4j.appender.EDISEPAGENERAL.MaxBackupIndex=5

log4j.appender.EDISEPAGENERAL.Append=true

log4j.appender.EDISEPAGENERAL.layout=org.apache.log4j.PatternLayout

log4j.appender.EDISEPAGENERAL.layout.ConversionPattern=%d{dd/MM/yyyy HH:mm:ss,SSS} %5r %-5p [%t]

%c{2} %M - %m%n

#Log propio de la conversion de cada fichero. El nombre final es "nombreDeFicheroDeEntrada.log", situado en la

#carpeta logs

log4j.appender.EDISEPAFICHERO=org.apache.log4j.RollingFileAppender

log4j.appender.EDISEPAFICHERO.Append=false

log4j.appender.EDISEPAFICHERO.layout=org.apache.log4j.PatternLayout

log4j.appender.EDISEPAFICHERO.layout.ConversionPattern=%d{dd/MM/yyyy HH:mm:ss,SSS} %-5p - %m%n

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 3.Descripción de la funcionalidad.


3. Descripción de la funcionalidad.

3.1. Uso de listas de ficheros por EDITRAN.

EDITRAN permite la transmisión de varios ficheros por la misma sesión

Para emitir:

Algunos clientes, utilizan lista de ficheros (ZTBGFCAR, ver formato TABLA 1)

para realizar las cargas, pues sus ficheros tienen nombres distintos en cada

una de ellas. Por tanto, crean diariamente una lista de ficheros de cada

presentación a emitir. Esta lista, es pasada al paso previo a emisión.

Normalmente, para poder utilizar un único procedimiento con todos los

remotos, el dsname de la lista de ficheros está formada con variables

reconocibles por el procedimiento (origen, remoto y aplicación).

Otros clientes, utilizan siempre los mismos dsnames de ficheros a emitir (en

cada transmisión tienen distinto contenido), por lo que optan por indicar en los

propios perfiles del producto, el dsname de los ficheros a emitir.

Para recibir:

Si en los perfiles EDITRAN, no se indica nada, EDITRAN descarga los ficheros

recibidos con un nombre por defecto

Si en los perfiles EDITRAN, se indica algo, EDITRAN descarga los ficheros

recibidos con el nombre indicado

En todos los casos, el posterior a recepción, paso ZTBGLFE, proporciona un

fichero al usuario, que es una lista de ficheros recibidos y descargados

(ZTBGFLFE, ver formato TABLA 2)

Tabla 1. Contenido del fichero ZTBGFCAR, fichero fijo de 80 de longitud, cuyo

contenido son los ficheros de aplicación de emisión y las características de los mismos. El

contenido es el siguiente (un registro por fichero):

Nivel Nombre Long. Tipo Descripción

1 Nombre físico 44 Alfn. Nombre físico del fichero de aplicación

1 Filler 1 Alfn. Guión de separación

1 Formato de fichero 1 Alfn. Formato de fichero de aplicación:

‘R’: Registro, ‘M’: Modificado


1 Lenguaje datos

origen

1 Alfn. Lenguaje original de los datos:

‘A’: Ascii, ‘E’: Ebcdic, ‘B’:Binario


1 Traducir en emisión 1 Alfn. Lenguaje en el que se emiten los datos:

‘A’: Ascii, ‘E’: Ebcdic, ‘N’:Sin traducción


1 Compresión 1 Alfn. Compresión:

‘F’ Comprimido, ‘N’ Sin compresión

1 resto registro 28 Alfn. Area de reserva



Tabla 2. Contenido del fichero ZTBGFLFE (lista de ficheros recibidos, que deja

actualmente el procedimiento posterior a recepción), fijo de 130 de longitud. El contenido es

el siguiente (un registro por fichero):


1 Area de fichero 130 Alfn.

2 Nombre físico 44 Alfn. Nombre físico del fichero de aplicación

descargado


2 Fecha-fin-

presentación

14 Num. Fecha-Hora de fin de presentación en formato

AAAAMMDDHHMMSS

2 Tipo-Fichero cargado 4 Num. Tipo de fichero cargado ó de salida

‘FIJO’

‘VBLE’

‘VEXP’

‘BINA’

2 Lenguaje-datos

cargados

1 Alfn. Lenguaje de los datos cargados:

‘A’: Ascii, ‘E’: Ebcdic, ‘B’:Binario

2 Compresión 1 Alfn. Indica si el fichero fue cargado con compresión:

‘F’ Comprimido, ‘N’ Sin compresión

2 Filler 1 Alfn. Area de reserva

2 Nombre físico origen 44 Alfn. Nombre físico del fichero de aplicación en

origen

2 Bytes fich.aplic 12 Num Bytes fichero aplicación

2 Longitud de reg. 6 Num Lrecl.

2 Filler 1 Alfn. Area de reserva

3.2. Parametrización EDITRAN.

Cuando se transmiten ficheros SEPA (XML), estos ficheros van en UTF-8 y no se

pueden traducir, de ahí que en las sesiones EDITRAN que utilicen este tipo de ficheros, es

requisito indicar:

o Lenguaje original de los datos: Binario

o Traducir en emisión: No

o Traducir en Recepción: No

o Tabla de conversión de emisión: Espacios.

o Tabla de conversión de recepción: Espacios

o Previo a emisión (se proporciona un nuevo procedimiento)

o Posterior a recepción (se proporciona un nuevo procedimiento)

EDITRAN permite recibir varios ficheros y juntarlos en uno único. En este caso de

transformación SEPA, no es posible hacer esto, y por tanto, debe especificar Fichero único

en recepción NO (y adecuar el DSNAME de salida si lo hubiera).



Además, en los casos de recepciones, se recomienda actuar de la siguiente forma:

EDITRAN, permite recibir n ficheros en cada transmisión. El usuario dispone de varias

opciones para actuar sobre el campo NOMBRE FISICO FICHERO APLICACIÓN RECEPCION de

perfiles de EDITRAN/G:

1.- No indicar nada. En este caso, si se reciben n fichero, EDITRAN los descarga con un

nombre por defecto. Ejemplo de recibir 2 ficheros:

Prefijo.lll.Rxnnnnnn.Rnnx.Aaaaaaa.Rmmmmnn

Prefijo : Prefijo Instalación Ficheros (Entorno local General EDITRAN/G)

lll : Alias (Entorno Local General o Secundario de EDITRAN/P)

Rxnnnnnn : Una R y los 7 primeros caracteres del código del remoto.

Rnnx : Una R y los 3 últimos caracteres del código del remoto.

Aaaaaaa : Una A y el nombre de la Aplicación de presentación

Rmmmmnn : Una R y 4 dígitos del número de Sesión de Intercambio y dos dígitos del

número de orden del fichero de aplicación.

En este caso, se recomienda indicar en NOMBRE FISICO lo siguiente (para diferenciar varios ficheros en la

misma transmisión y para que los planos finales acaben quedando sin el último puntero, .XML:

Prefijo.lll.R%R.nnx.A%A.R%N%C.XML

2.- Que el usuario indique un dsname fijo (ojo a la limitación indicada anteriormente de que

se recibían varios ficheros y se descargaban sobre uno fijo). En este caso, se recomienda

indicar dsname-fijo.xml

3.- Que el usuario indique un dsname con variables. En este caso se recomienda indicar

dsname-con-variables.xml

Nótese que en todos los casos, se ha indicado el nombre recibido hasta ahora + .XML.

Tenga en cuenta que ahora, los ficheros descargados por EDITRAN son XML y el conversor los pasará a

fijos para que los trate su aplicación, por tanto, lo que intentaremos es dejar los mismos dsnames a su

aplicación que lo que recibía hasta ahora.

En el fichero ZTBGFDAT (explicado posteriormente), si no se indica nada en el DSNAME salida, indica que

el fichero descargado por EDITRAN se llamaba xx.XML y el transformado a plano se llamará xx, por lo que

la aplicación usuaria tratará los mismos ficheros que trataba hasta ahora (idénticos dsnames).



3.3. Casos de uso de los conversores.

Se plantean básicamente 3 casos de uso para llamar a los conversores:

1. En procedimientos previos a emisión (A1P). En este caso, se plantea utilizar el conversor

en un paso previo al A1P, de forma que con un único nuevo procedimiento (ZTBGP1X),

se pueda dar solución a todas las sesiones de presentación EDITRAN que requieran

emitir ficheros XML. Además, se da solución a que para el usuario sea transparente este

conversor con respecto a su funcionamiento anterior de carga (planos)

2. Procedimientos posteriores a recepción (A4P). En este caso, se plantea utilizar el

conversor en un paso posterior al paso A4P y al paso LFE, de forma que con un único

nuevo procedimiento (ZTBGP4X), se pueda dar solución a todas las sesiones de

presentación EDITRAN que requieran recibir ficheros XML y los quieran pasar a PLANOS.

Además, se da solución a que para el usuario sea transparente este conversor con

respecto a su funcionamiento anterior de descarga (planos)

3. JCL. En este caso, se puede usar un jcl específico ZTBGJXML, para pasar cualquier

fichero de la entidad a XML ó a PLANO.

En definitiva, los conversores de planos a XML y de XML a plano, se han desarrollado:

De forma que sirvan para ficheros transmitidos por EDITRAN. En este caso, lo más

común será utilizar 2 nuevos procedimientos standard del producto: un previo a emisión

(ZTBGP1CX) y un posterior a recepción (ZTBGP4CX).

De forma que sirvan para poder tratar de esta forma, cualquier otro fichero de la

instalación. En este caso, lo más común será utilizar un jcl suministrado ZTBGJXML

3.4. 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=SHR

En el caso de posterior a recepción ó 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=SHR

Si 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:


1 Nombre físico

entrada

44 Alfn. Nombre físico del fichero de aplicación que

entra al conversor


1 Nombre físico salida 44 Alfn. Nombre físico del fichero de aplicación que

genera el conversor


1 CGO resultado del

conversor

4 Num Resultado devuelto por el conversor


1 Texto del Error 80 Alfn. Texto del Mensaje del error devuelto por el

conversor

1 resto registro 77 Alfn. Area 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: //ZTBGFDAT DD DSN=KI.PEPE.&L0..R&R1..R&R2..A&AP..ZTBGFDAT,DISP=SHR

3.4.1. Datos pasados al conversor mediante PARM.

Al conversor, es necesario pasarle los siguientes datos mediante PARM:

a. Origen. Rbe origen. En caso de jcls no EDITRAN, se pone el código de la

entidad. En otro caso, se pasa la variable de entrada al procedimiento (&L1&L2).

b. 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).

c. Aplicación. Aplicación EDITRAN/G. En caso de jcls 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).

d. Función: (X)- Plano a XML, (P)- XML a plano

e. 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):

i. (F) Fichero. El jcl o procedimiento, lleva un fichero de entrada con un

DSNAME.

ii. (L) Lista. El jcl o procedimiento, lleva una lista de ficheros de entrada.

1. 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.

2. En procedimientos posteriores a recepción (función P xml a

plano). El procedimiento standard EDITRAN, 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.

iii. (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 EDITRAN.

1. En procedimientos previos a emisión. Si usted usa perfiles

EDITRAN en la carga, se recomienda utilizar esta opción.

2. En procedimientos posteriores a recepción (función P, xml a

plano), esta opción no tiene sentido.

f. DSNAME del fichero de entrada (no puede ser un miembro de un particionado).

i. Si tipo de fichero de entrada es P, no se indicará nada.

ii. Si tipo de fichero de entrada es F, se indicará aquí un nombre de fichero

(directamente ó con variables),



iii. 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:

// PROC ORIGEN=,FUNCION=,L0=,

// L1=,L2=,R1=,R2=,AP=,LF=,FU=,TI=,FI=

// SET LF=S

// SET FU=X

// SET TI=L

// SET FI= KI.EGDC.&L0.R&R1.R&R2.A&AP.LCAR

//PASO01 EXEC PGM=ZTBXBXML,

// PARM='&L1&L2&R1&R2&AP&FU&TI&FI/CBLQDA(ON)'

//ZTBGFDAT DD DSN=KI.EIDC.ZTBG.ZTBGFDAT,DISP=SHR

//ZTBGFCAR DD DSN=KI.PMED.R&R1..R&R2..A&AP..LISTFICX,

//ZTBXFSAL DD DSN=KI.PMED.R&R1..R&R2..A&AP..ZTBXFSAL,

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á EDITRAN (no confundir con la

la lista de ficheros que puede proporcionar el usuario al conversor) ó 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 EDITRAN), 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 EDITRAN, (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 EDITRAN (embebido en los

procedimientos previos a emisión y posteriores a recepción):

o 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

o En posteriores a recepción (descargas):

El paso del conversor, creará una nueva lista de ficheros

transformados ZTBGFCAR en todos los casos

3.4.2. Datos pasados al conversor mediante fichero de usuario (ZTBGFDAT).

En todos los casos, es necesario que el usuario cree un fichero (ó n) con ciertos

parámetros que normalmente serán siempre iguales. Este fichero se llama

ZTBGFDAT y es un plano de lrecl 86. El contenido de este fichero es el siguiente:

Nivel

Nombre Tipo

Long

Posición

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 Guión separador Alfn 1 2 Opcional Guión

3 IP ó DNS del servidor java

Alfn 1-64

3 Obligatorio

Ip xxx.xxx.xxx.xxx ó dns del servidor java Ajustado a la derecha.


3 Puerto del servidor java

Num

5 68 Obligatorio

Puerto de escucha del servidor java 00001 a 65536


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 Información libre Alfn 1 78 Opcional Valor:

S incorporar valores en la zona libre del plano N No incorporar valores Defecto N


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 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 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 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.


Datos de transformación de PLANO a XML


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 Tabla de caracteres del fichero de aplicación origen

Alfn 18 48 Opcional Nombre de la tabla de caracteres en la que se encuentra el fichero origen. Si no se especifica nada, se coge por defecto la tabla del zos donde

nos estamos ejecutando (habitualmente ISO-8859-1). En el siguiente link, aparecen las tablas

soportadas:

https://docs.oracle.com/javase/8/docs/

technotes/guides/intl/encoding.doc.html

l 3 Guión separador Alfn 1 66 Opcional Guión

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

http://docs.oracle.com/javase/1.4.2/docs/guide/intl/encoding.doc.html





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 nro de bytes y la divide por la longitud de registro máxima de un variable (32752), en que quedará el xml.


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 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 defecto 27990


Datos de transformación XML a PLANO


3 DSNAME de fichero salida (DNSMAME del PLANO)

Alfn 1-44


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 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 zos donde

nos estamos ejecutando (habitualmente ISO-8859-1). En el siguiente link, aparecen las tablas

soportadas:

https://docs.oracle.com/javase/8/docs/

technotes/guides/intl/encoding.doc.html

l 3 Guión separador Alfn 1 66 Opcional Guión

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 Espacio reservado Alfn 1 80 Opcional


Datos de generación de xml con aceptación ó rechazo (adeudos-transferencias)


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 DSNAME de fichero salida (DNSMAME del XML ACE/RECH)

Alfn 1-44


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 indicandolo 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 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 estandar

Si se indica S, se crea un fichero de confirmación

con OrgnlMsgId nif+ estandar

Ejemplo de contenido en ZTBGFDAT:

***************************** Top of Data ********************************************

----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+-

0- 111.022.033.444-00994-300-S-S-S-S-T

*0- pepito.es-00994-300-

1-%O.XML - - -N-03000

2- - - -

3-S-%O.XML.CNF -S

***************************** Bottom of Data *****************************************

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

Mantine 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 EDITRAN 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.

Tb 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 EDITRAN

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 alojar en ellos cierta

información que, estando en el fichero XML de origen, se pierde en la conversión por

no estar definido un campo para ella en la norma correspondiente. Dicha información

es tratada exclusivamente por las aplicaciones de cliente que sólo tratan ficheros en



formato plano y generalmente 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.

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 fruto de la

transformación.

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”.

<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

350 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

354 del mismo registro si el bloque de origen es del tipo Otras Transferencias.

Se escribe “XML” en la posición 598 del registro de cabecera de ordenante.

<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],


corresponda por tipo de bloque, cuando más de 8 cifras.

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 del campo <PmtInfId> a la posición 300

del registro de [Cabecera de acreedor por fecha de cobro].

Devoluciones, se traslada el contenido de <OrgnlPmtInfAndSts><OrgnlPmtInfId> a la

posición 335 del registro de [Cabecera de acreedor por fecha de devolución].

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].

Presentaciones y retrocesiones, se traslada el contenido de:

<GrpHdr><NbOfTxs> a la posición 48, del [Registro total general] si la cantidad

supera las 8 cifras que contempla el formato plano.

<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).

Presentaciones, se traslada el contenido de:

<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.

<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).

Rechazos y devoluciones, se traslada el contenido de:

<OrgnlGrpInfAndSts><OrgnlNbOfTxs> a la posición 48 del [Registro total

general]. Se utilizará para recoger números de registros individuales cuyo valor




<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).

Rechazos, se traslada el contenido de:

<OrgnlPmtInfAndSts><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.


acreedor por fecha de cobro]. Se utilizará para recoger importes de 18 cifras en

total (la norma de formato plano contempla hasta 17).

Devoluciones, se traslada el contenido de:


acreedor]. Se utilizará para recoger números de registros individuales cuyo valor



acreedor]. Se utilizará para recoger importes de 18 cifras en total (la norma de


Retrocesiones, se traslada el contenido de:

<OrgnlPmtInfAndRvsl><OrgnlNbOfTx> a la posición 91 del [Registro total de

acreedor]. Se utilizará para recoger números de registros individuales cuyo valor


<OrgnlPmtInfAndRvsl><OrgnlNbOfTx> a la posición 73 del [Registro total de

acreedor]. Se utilizará para recoger importes de 18 cifras en total (la norma de


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],


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):

Rechazos y devoluciones, 35 posiciones, comenzando en la 335, del registro de

[Cabecera de acreedor por fecha de cobro] a <OrgnlPmtInfAndSts><OrgnlPmtInfId>.


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 177, del registro de [Cabecera de presentador] a

<OrgnlGrpInfAndSts><StsRsnInf><Rsn><Cd>

11 posiciones, empezando en la 369, del registro de [Cabecera de acrredor 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 379, 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>

Presentaciones y retrocesiones, se traslada el contenido de:

15 posiciones, comenzando en la 48, 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.




<GrpHdr><CtrlSum>. Se utilizará para recoger importes de 18 cifras en total (la

norma de formato plano contempla hasta 17).

Presentaciones, se traslada el contenido de:

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.


cobro] a <PmtInf><CtrlSum>. Se utilizará para recoger importes de 18 cifras en

total (la norma de formato plano contempla hasta 17).

Rechazos y devoluciones, se traslada el contenido de:


<OrgnlGrpInfAndSts><OrgnlNbOfTxs>. Se utilizará para recoger números de

registros individuales cuyo valor supere las 8 cifras que contempla el formato

plano.


<OrgnlGrpInfAndSts><OrgnlCtrlSum>. Se utilizará para recoger importes de 18

cifras en total (la norma de formato plano contempla hasta 17).



cobro] a <OrgnlPmtInfAndSts><OrgnlNbOfTx>. Se utilizará para recoger números

de registros individuales cuyo valor supere las 8 cifras que contempla el formato

plano.


cobro] a <OrgnlPmtInfAndSts><OrgnlNbOfTx>. Se utilizará para recoger importes

de 18 cifras en total (la norma de formato plano contempla hasta 17).

Devoluciones, se traslada el contenido de:

15 posiciones, comenzando en la 91, del [Registro total de acreedor] a

<OrgnlPmtInfAndSts><OrgnlNbOfTx>. Se utilizará para recoger números de


plano.


<OrgnlPmtInfAndSts><OrgnlNbOfTx>. Se utilizará para recoger importes de 18


Retrocesiones, se traslada el contenido de:


<OrgnlPmtInfAndRvsl><OrgnlNbOfTx>. Se utilizará para recoger números de


plano.


<OrgnlPmtInfAndRvsl><OrgnlNbOfTx>. Se utilizará para recoger importes de 18




El conversor buscará en primer lugar esta información en los campos libres y, de no

estar, efectuará el mapeo como lo hace habitualmente para cada uno de esos campos.

Registro de confirmación ó 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 ó 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 ó 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:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.002.001.03"> <CstmrPmtStsRpt> <GrpHdr> <MsgId>B0081.S0901.F130314.P0120140311</MsgId> <CreDtTm>2014-03-14T11:30:00</CreDtTm> <InitgPty> <Nm>TELEFONICA DE ESPANA, S.A.</Nm> </InitgPty> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId>B0081.S0901.F130314.P0120140311</OrgnlMsgId> <OrgnlNbOfTxs>0000023448</OrgnlNbOfTxs> <OrgnlCtrlSum>1246067.16</OrgnlCtrlSum> <GrpSts>ACCP</GrpSts> </OrgnlGrpInfAndSts> </CstmrPmtStsRpt>

</Document>

La lista de variables conocidas por EDITRAN 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 primera posiciones.

Ejemplo de contenido en ZTBGFDAT:

***************************** Top of Data ********************************************

----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+-

0- 111.022.033.444-00994-300-S-S-

*0- pepito.es-00994-300-

1-%O.XML - - - -03000

2- - - -

3-S-%O.XML.CNF

***************************** Bottom of Data *****************************************

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 EDITRAN 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.

Tb 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 EDITRAN

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.

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 4.Adaptación para Pagos Telemáticos de la TGSS


4. Adaptación para Pagos Telemáticos de la TGSS

Para facilitar a nuestros clientes la integración del protocolo completo de Pagos

Telemáticos de la TGSS con el conversor SEPA, se han implementado los dos mapeos

adicionales que se detallan en este documento.

4.1. Recepción de los ficheros

Las entidades van a recibir de la TGSS los ficheros en formato XML, según el esquema

pain.001.001.03.xsd de ISO 20022.

XML(pain.001.001.03) Conversor Fichero formato plano: registro de cabecera TGSS + fichero SEPA 34-14

El contenido de la etiqueta <MsgId> de estos ficheros XML es:

Tipo de envío (2 posiciones): Fecha de creación del fichero, 6 posiciones (AAMMDD) NRBE entidad financiera del pago (4 posiciones) Referencia (20 posiciones)

Atención: Bajo la indicación específica del parámetro en el registro 0 de ZTBGFDAT

posición 86 - Cabecera TGSS (ver manual XML5XUSUA. También podría informarse en el

fichero Configuracion.properties), cuando estos ficheros pasen por el Conversor, se traducirán

a formato plano.

El uso de este parámetro ignora cualquier valor dado al parámetro del registro 3 Crear XML

CONF (Ace-Rech), respuesta automática si el fichero a convertir es de la norma 34-14.

El contenido del fichero resultante será el registro de cabecera TGSS que se definió en su

día, cuya estructura se detalla a continuación, seguido por el fichero sepa 34-14.

REGISTRO DE CABECERA DE TRANSMISIÓN (formato plano)

CAMPO A Código de Registro de Cabecera. Campo numérico de 2 posiciones. Su valor será 01

CAMPO B Código de Norma. Campo numérico de 2 posiciones. Su valor será 34 CAMPO C Tipo de Operación. Campo numérico de 2 posiciones. Su valor será 14 CAMPO D Tipo de envío I. Campo numérico de 2 posiciones. Sus posibles valores

son: 50 - Ficheros de transferencias R03, firmadas electrónicamente CAMPO E Tipo de envío II. Campo numérico de 2 posiciones. Sus valores serán los

siguientes: 01 - Para todos los tipos de envíos anteriores (Posibilidad de incluir 06 en algún caso particular en versiones posteriores)

CAMPO F Referencia de Cliente. F1 Fecha de creación del Fichero. Campo numérico de 6 posiciones F2 Hora de Creación del Fichero. Campo numérico de 4 posiciones F3 Código de la Entidad Financiera. Campo numérico de 6 posiciones



CAMPO G Ampliación de Referencia del Cliente. Campo alfanumérico de 20 posiciones. Contendrá el número de la R y la Caja Pagadora

CAMPO H Campo de longitud variable hasta ajustarse a 600.

El mapeo que realiza el Conversor es el siguiente:

Registro de cabecera TGSS: 01 + 34 + 14 + dos primeros caracteres de la etiqueta

<MsgId> + 01 + seis siguientes caracteres de <MsgId> + 000000 + veinticuatro caracteres

restantes de <MsgId> + 554 blancos.

4.2. Envío de la confirmación

La TGSS espera recibir de las entidades un fichero de confirmación XML según el esquema

pain.002.001.03.xsd.

Confirmación TGSS Conversor XML (pain.002.001.03)

Podrán obtenerlo con el Conversor aquellos usuarios que las hayan generado en sus

aplicaciones en formato plano y de acuerdo a la siguiente estructura:

FICHERO DE RESPUESTA DE CONFIRMACIÓN (formato plano)

CAMPO A Identificación del Cuaderno y Tipo de Operación del CSB. Su valor será 3414

CAMPO B Identificación del Fichero transmitido. B1 Se corresponde con el CAMPO F1 del Registro de Cabecera de Transmisión B2 Se corresponde con el CAMPO F2 del Registro de Cabecera de Transmisión B3 Se corresponde con el CAMPO F3 del Registro de Cabecera de Transmisión

CAMPO C Identificación de las Entidades Emisoras C1 Reservado. Campo de 12 posiciones C2 Identificación de la Entidad. Campo alfanumérico de 40 posiciones

CAMPO D Identificación de la Entidad Financiera. D1 NRBE de la Entidad. Campo numérico de 4 posiciones D2 Reservado. Campo de 4 posiciones

CAMPO E Datos para el Cuadrante E1 Número Total de Registros que figura en el Registro de cola del fichero

lógico. Campo numérico de 10 posiciones E2 Importe Total que figura en el Registro de cola del cola del fichero lógico.

Campo numérico de 17 posiciones E3 Número de Registros del Fichero Recibido. Campo numérico de 10 posiciones E4 Suma Total de Importes del Fichero Recibido. Campo numérico de 17

posiciones Nota: En la primera versión, donde existe un único fichero físico, los campos E1 y E2 aparecerán a ceros.

CAMPO F Códigos de Control. F1 Código Resultado de la Transmisión. Campo numérico de 2 posiciones. F2 Reservado para futuros códigos. Campo numérico de 2 posiciones. Su valor

será 00



CAMPO G Información adicional de Comprobación del Cliente G1 Se corresponde con el CAMPO D del Registro de Cabecera de Transmisión

G2 Se corresponde con el CAMPO E del Registro de Cabecera de Transmisión G3 Se corresponde con el CAMPO G del Registro de Cabecera de Transmisión G4 Reservado. Campo de 8 posiciones

El mapeo que realiza el Conversor es el siguiente:

<CstmrPmtStsRpt><GrpHdr><MsgId>: G1 + B1 + posiciones de la 2 a la 5 de B3 + G3

<CstmrPmtStsRpt><GrpHdr><CreDtTm>: en formato ISODateTime YYYY-MM-DDThh:mm:ss. Primera y segunda cifra de B1 , formateados a YYYY + “-“ + tercera y cuarta cifra de B1 + “-“ + quinta y sexta cifra de B1 + “T00:00:00”

<CstmrPmtStsRpt><OrgnlGrpInfAndSts><OrgnlMsgId>: mismo contenido que <CstmrCdtTrfInitn><GrpHdr><MsgId>

<CstmrPmtStsRpt><OrgnlGrpInfAndSts><OrgnlMsgNmId>: pain.001.001.03

<CstmrPmtStsRpt><OrgnlGrpInfAndSts><OrgnlCtrlSum>: E4 (con las dos cifras de la derecha separadas por ‘.’).

<CstmrPmtStsRpt><OrgnlGrpInfAndSts><GrpsSts>: ACTC si F1 es 00, RJCT para cualquier otro valor.

<CstmrPmtStsRpt><OrgnlGrpInfAndSts><GrpsSts><StsRsnInf><Rsn><Cd>: según el contenido de F1 y siempre que sea distinto de 00.

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 5.JCLS y PROCEDIMIENTOS.


5. JCLS y PROCEDIMIENTOS.

5.1.1. JCLS.

Se proporciona el jcl ZTBGJXML:

//XXXXXXXX JOB (XXXX,XXX,,XX),ZTBXXML,MSGCLASS=X,CLASS=X,

// MSGLEVEL=X,NOTIFY=&SYSUID

//********************************************************************+

//* JCL PARA CONVERTIR UN FICHERO PLANO SEPA A XML Ó A LA INVERSA *+

//********************************************************************+

//* 1.-DEBE APUNTAR (SET) LAS SIGUIENTES VARIABLES: *+

//* 1.1.SESION: L1+L2+R1+R2+AP: INDICAR UNA SESION DE EDITRAN/G *+

//* 1.2.FUNCION: FU. ADMITE VALORES X=PLANO A XML, P=XML A PLANO *+

//* 1.3.TIPO: TI. ADMITE VALORES:F=FICHERO (EL INDICADO EN &FI=XX) *+

//* TI=F INDICA FICHERO. EN &FI VA EL DSNAME DEL FICHERO DE *+

//* APLICACION DE ENTRADA (XML O PLANO SEGUN &FU) *+

//* TI=L INDICA LISTA DE FICHEROS. EN &FI VA DSNAME DE UN FILE *+

//* CREADO POR USUARIO, CUYO CONTENIDO SON LOS DSNAMES DE *+

//* LOS FICHEROS DE ENTRADA (XML O PLANOS SEGUN &FU) *+

//* PARA VER FORMATO DE LA LISTA, REVISE DOCUMENTACION *+

//* TI=P INDICA PERFILES. EN ESTE CASO, EDITRAN TIRA DE PERFIL *+

//* EDITRAN/G PARA COGER NOMBRES DE FICHEROS ENTRADA. *+

//* 1.4.FICHERO: FI. INDICAR EL DSNAME (DE 40 MAXIMO) &FI=XXXX *+

//* SI &TI=F ES EL DSNAME DEL FICHERO DE ENTRADA *+

//* SI &TI=L ES EL DSNAME DE LA LISTA, CUYO CONTENIDO SON LOS *+

//* DSNAMES DE LOS FICHEROS DE ENTRADA *+

//* SI &TI=P INDIQUE ESPACIOS. EL JOB COGE LOS FILES DEL PERFIL*+

//* 2.-DEBE EXISTIR EL FICHERO DD ZTBGFDAT, PUES EN SU CONTENIDO HAY *+

//* TAMBIEN OTROS PARAMETROS NECESARIOS, IP-PORT, FICHERO SALIDA, *+

//* SEGUNDOS ESPERA, ETC. (REVISE DOCUMENTACION DE PRODUCTO) *+

//* CON &FU=X, SI EN ZTBGFDAT NO SE ESPECIFICA DSNAME DE SALIDA, *+

//* EL PROGRAMA CREA UN FILE DE SALIDA LLAMADO DSNAME.XML *+

//* CON &FU=P, SI EN ZTBGFDAT NO SE ESPECIFICA DSNAME DE SALIDA, *+

//* EL PROGRAMA CREA UN FILE DE SALIDA LLAMADO: *+

//* DSNAME (si el fich. entrada es DSNAME.XML) *+

//* DSNAME.PLN(si el fich. entrada es DSNAME) *+

//* 3.-SACA UNA LISTA CON LOS FICHEROS PROCESADOS, DD ZTBGFCAR *+

//********************************************************************+

// SET L1=000099

// SET L2=940

// SET R1=000099

// SET R2=990

// SET AP=CARGAC

// SET FU=X

// SET TI=F



// SET FI=KI.EIDA.FF06

//********************************************************************+

//INBORR1 EXEC PGM=IEFBR14

//LPASO00 DD DSN=KI.PMED.R&R1..R&R2..A&AP..LISTFICX,

// DISP=(OLD,DELETE,DELETE)

//*



//STEPLIB DD DSN=KI.EIDC.ZTBG.LOAD,DISP=SHR

//SYSTCPD DD DSN=SW.TCPIP.SEZAPARM(TCPDATAB),DISP=SHR

//ZTBGFPRI DD SYSOUT=*,DCB=(BLKSIZE=105)

//ZTBGFPER DD DSN=KI.EIDC.ZTBG.ZTBGFPER,DISP=SHR

//ZTBGFLOG DD DSN=KI.EIDC.ZTBG.ZTBGFLOG,DISP=SHR



// DISP=(NEW,CATLG,DELETE),

// SPACE=(TRK,(500,50),RLSE),

// DCB=(RECFM=FB,LRECL=80,BLKSIZE=0,DSORG=PS)

//ZTBXFSAL DD DSN=KI.PMED.R&R1..R&R2..A&AP.. ZTBXFSAL,




//SYSOUT DD SYSOUT=*

//SYSPRINT DD SYSOUT=*

//SYSDBOUT DD SYSOUT=*

//ABENDAID DD SYSOUT=*

//SYSCOUNT DD DUMMY

//SYSUDUMP DD SYSOUT=*

//SYSABOUT DD SYSOUT=*

Hemos indicado como ejemplo, origen (000099990) destino (000099940), aplicación

(CARGAC), Función X (plano a xml), tipo F (fichero), DSNAME del fichero de entrada =

KI.FICHERO.ENTRADA

En el fichero ZTBGFDAT habremos indicado un registro de tipo 1, sin el nombre de fichero

de salida. Si no se indica nada, (ver el contenido de ZTBGFDAT), se creará el fichero

KI.FICHERO.ENTRADA.XML.

********************************* Top of Data ****************************************

0- 192.168.172.088-07774-300-

1- - -000000500000-N-

2- - -000000000000-S

******************************** Bottom of Data **************************************

A su vez, como ejemplo de Función P ( xml a plano), si codificamos en PARM

000099990000099940PEPITAPFKI.FICHERO.ENTRADA.XML



Y en el fichero ZTBGFDAT hemos indicado un registro de tipo 2, sin nombre de fichero de

salida, se creará el PLANO KI.FICHERO.ENTRADA

5.1.2. Procedimientos.

5.1.2.1.Previo a emisión.

Se proporciona el previo ZTBGP1CX. Actualmente, al previo a emisión estándar (ZTBGP1C),

tiene lo siguiente:


// L1=,L2=,R1=,R2=,AP=,LF=

//A1P EXEC PGM=ZTBGB110,

// PARM='&ORIGEN&FUNCION&L1&L2&R1&R2&AP&LF/CBLQDA(ON)',

// REGION=0M,TIME=1440

….

//ZTBGFCAR DD DSN=KI.PMED.&L0..R&R1..R&R2..A&AP..ZTBGFCAR,DISP=SHR

(ZTBGFCAR puede que el usuario no lo use, ó lo haya llamado de otra forma)

El nuevo procedimiento proporcionado tiene con respecto al estandard:

Un paso previo a A1P (conversor de plano a xml)

Un SET a la variable LF

Nuevas variables

Un cambio en cuanto a la lista ZTBGFCAR (si es que el usuario ya la utilizaba)

Se proporciona el previo ZTBGP1X (en amarillo no nuevo o los cambios):


// L1=,L2=,R1=,R2=,AP=,LF=,FU=,TI=,FI=

// SET LF=S

// SET FU=X

// SET TI=P

//* SET FI=XX.XXXX.XXX

//*********************************************************************

//* PROCEDIMIENTO PREVIO A LA EMISION EDITRAN/G *

//* INCLUYE UN PASO PREVIO A LA CARGA, QUE CONSISTE EN NORMA SEPA *

//* PASO DE FICHEROS DE APLICACION PLANOS A XML *

//*********************************************************************

//* DATOS: *

//* ORIGEN (O=OPERADOR,E=EDITRAN,A=JCL APLICACION) ----> 1 BYTE *

//* FUNCION (01=CARGA DE EMISION DE PRESENTACION, *

//* 03=EMISION DE PRESENTACION, *

//* 04=EMISION DINAMICA DE PRESENTACION) -----> 2 BYTES *

//* SESION-PRESENTACION ------------------------------>24 BYTES *

//* LISTA FICHEROS (S) ------------------------------> 1 BYTE *

//* INDEPENDIENTEMENTE DE QUE EL USUARIO INDIQUE QUE USA UNA *

//* LISTA DE FICHEROS EN LA CARGA, EL PASO01 LE PASA AL PASO A1P *

//* UNA NUEVA LISTA DE FICHEROS A CARGAR (LOS XML), POR LO QUE *



//* EL VALOR DE ESTA VARIABLE, DEBE APUNTARSE SIEMPRE A S. *

//* EL USUARIO, SI USA LISTA DE FICHEROS, INDICA LA MISMA EN &FI *

//* FUNCION (X) (CONVERTIR PLANO A XML EN PASO01) -----> 1 BYTE *

//* TIPO FICHERO APLICACION (P/L/F) -------------------> 1 BYTE *

//* INDICA DE DONDE TIRAR PARA SACAR LOS XML: *

//* SI P (PERFIL) : PASO01, TIRA DE PERFILES DE EDITRAN/G *

//* SI F (FICHERO): EL XML ESTA INDICADO EN LA VARIABLE &FI *

//* SI L (LISTA) : LA LISTA DE LOS XML ESTA INDICADA EN VBLE &FI *

//* FICHERO APLICACION: DSNAME DEL FICHERO DE APLICACION (DEL XML) *

//* O DSNAME DE LA LISTA QUE CONTIENE LOS FICHEROS APL-> 0-44 BYTES *

//* SI &TI=P, NO SE USA &FI, POR LO QUE PUEDE PONER SPACES *

//* SI &TI=F, &FI=DSNAME.FILE.APLIC.XML *

//* SI &TI=L, &FI=DSNAME.LISTA.FILES.APLIC.XML *

//*********************************************************************


//LPASO00 DD DSN=KI.PMED.R&R1..R&R2..A&AP..LISTFICX,














//ZTXGFSAL DD DSN=KI.PMED.R&R1..R&R2..A&AP..ZTBXFSAL,








//SYSCOUNT DD DUMMY



/*

//A1P EXEC PGM=ZTBGB110,,COND=(0,NE,PASO01),

// PARM='&ORIGEN&FUNCION&L1&L2&R1&R2&AP&LF/CBLQDA(ON)',




….

//ZTBGFCAR DD DSN=KI.PMED.R&R1..R&R2..A&AP..LISTFICX,DISP=SHR

Se ha apuntado la variable LF=S (el paso a1p, coge una lista de ficheros creada en

PASO01, con el nombre KI.PMED.R&R1..R&R2..A&AP..LISTFICX)

Se ha apuntado la variable FU=X (pasar PLANOS A XML)

Se ha apuntado la variable TI=P (el usuario quiere que los dsnames de ficheros de

aplicación planos, los saquemos del perfil de la sesión). Nota. Si por ejemplo el usuario

hubiera creado una lista de ficheros de aplicación a cargar, por ejemplo

KI.PMED.R&R1..R&R2..A&AP..ZTBGFLFE, deberíamos apuntar la variable SET

FI=KI.PMED.R&R1..R&R2..A&AP..ZTBGFLFE. El contenido de este fichero se describió en

tabla-1.

Debe existir, creado por el usuario el fichero ZTBGFDAT. Ejemplo:

***************************** Top of Data ********************************************

0- 192.172.038.244-00994-300- -

1-%O.XML - - - -00000

2- - - -S

***************************** Bottom of Data *****************************************

EDITRAN, en un primer paso XML, pasará los ficheros indicados en PERFIL EDITRAN/G

(TI=P), a formato XML. Creará una nueva lista, KI KI.PMED.R&R1..R&R2..A&AP..LISTFICX

cuyo contenido es una lista de ficheros con los nombres de los XML generados (que

será DSNAME-FILE-APLICACIÓN.XML, por haber especificado %O.XML en ZTBGFDAT). A

continuación, el paso A1P tirará de la nueva lista de ficheros

KI.PMED.R&R1..R&R2..A&AP..LISTFICX (debido a que se apuntó la variable LF=S), y

cargará los mismos

Si por ejemplo, hemos usado una lista de ficheros (TI=L), que se llama

KI.EGDC.L00.R123.R456789.APEPITA.ZTBGFCAR y tiene como contenido:

********************************* Top of Data ****************

KI.EIDA.FF01 -R-E-A-F

KI.EIDA.FF02 -R-E-A-F

******************************** Bottom of Data **************

El contenido del fichero KI.PMED.R&R1..R&R2..A&AP..LISTFICX será:

********************************* Top of Data ****************

KI.EIDA.FF01.XML -B-N-N-F

KI.EIDA.FF02.XML -B-N-N-F

******************************** Bottom of Data **************

5.1.2.2.Posterior a recepción.

Se proporciona el posterior ZTBGP4CX. Actualmente, al posterior a recepción estándar

(ZTBGP4C), tiene lo siguiente:




// L1=,L2=,R1=,R2=,AP=


// PARM='&ORIGEN&FUNCION&L1&L2&R1&R2&AP/CBLQDA(ON)',

….

//ZTBGLFE EXEC PGM=ZTBGBLFE,COND=(0,NE,A4P),

// PARM='&ORIGEN&FUNCION&L1&L2&R1&R2&AP',

//ZTBGFLFE DD DSN=KI.PMED.&L0..R&R1..R&R2..A&AP..ZTBGFLFE,DISP=SHR

El nuevo procedimiento proporcionado tiene con respecto al estandard:


// L1=,L2=,R1=,R2=,AP=,FU=,TI=,FI=

// SET FU=P

// SET TI=L

// SET FI=KI.PMED.R&R1..R&R2..A&AP..ZTBGFLFE

//*********************************************************************

//* PROCEDIMIENTO POSTERIOR A LA RECEPCION EDITRAN/G *

//* NOTA: SI PASO ZTBGB140 ACABA CON RC=01 ES PORQUE NO ES LA ULTIMA*

//* SESION DE TRANSMISION. IGNORAR DICHO WARNING *

//* INCLUYE UN PASO POSERIOR A DESCARGA, QUE CONSISTE EN NORMA SEPA *

//* PASO DE FICHEROS DESCARGADOS XML A PLANOS *

//*********************************************************************

//* DATOS: *

//* ORIGEN (O=OPERADOR,E=EDITRAN,A=JCL APLICACION) ----> 1 BYTE *

//* FUNCION (07=DESCARGA DE RECEPCION DE PRESENTACION, *

//* 09=FIN DE RECEPCION DE PRESENTACION) -----> 2 BYTES *

//* SESION-PRESENTACION ------------------------------>24 BYTES *

//* FUNCION (P) (CONVERTIR XML A PLANO EN PASO02) -----> 1 BYTE *

//* TIPO FICHERO APLICACION (L) (LISTA) ---------------> 1 BYTE *

//* EL PASO LFE SACA UNA LISTA, ZTBGFLFE CON LOS XML DESCARGADOS *

//* EL PASO02, TIRA DE ESA LISTA &FI PARA PASAR LOS XML A PLANO *

//* FICHERO APLICACION: &FI, SE APUNTA CON EL NOMBRE DE LA LISTA *

//* QUE SACA EL PASO ZTBGLFE *

//*********************************************************************


// PARM='&ORIGEN&FUNCION&L1&L2&R1&R2&AP/CBLQDA(ON)',


…..

//*********************************************************************

//*PASO PARA GENERAR LISTA DE FICHEROS RECIBIDOS EN LA PRESENTACION

//*********************************************************************


//LPASO00 DD DSN=KI.PMED.R&R1..R&R2..A&AP..ZTBGFLFE,




//*

//ZTBGLFE EXEC PGM=ZTBGBLFE,COND=(0,NE,A4P),

// PARM='&ORIGEN&FUNCION&L1&L2&R1&R2&AP',


//ZTBGFLFE DD DSN=KI.PMED.R&R1..R&R2..A&AP..ZTBGFLFE,




…..

//*********************************************************************

//*PASO PARA CONVERTIR LOS XML A PLANOS

//*********************************************************************

//PASO02 EXEC PGM=ZTBXBXML,,COND=(0,NE,ZTBGLFE),








//ZTBGFCAR DD DSN=KI.PMED.R&R1..R&R2..A&AP..ZTBGFLF2,




//ZTXGFSAL DD DSN=KI.PMED.R&R1..R&R2..A&AP..ZTBXFSAL,








//SYSCOUNT DD DUMMY



/*

Un paso intermedio entre A4P-ZTBGLFE (que borra la lista de ficheros de entrada

que va a sacar el paso ZTBGLFE

Un paso posterior a A4P-ZTBGLFE (conversor de xml a plano). El paso A4P

descarga los XML. El paso ZTBGLFE saca una lista cuyo contenido son los

dsnames de los ficheros descargados (ver tabla-2). El PASO02, tira de esa lista (al

haber apuntado TI=L y FI=KI.PMED.R&R1..R&R2..A&AP..ZTBGFLFE ZTBGLFE) y

convierte a plano (al haber apuntado FU=P. Este PASO02, saca además una lista



KI.PMED.R&R1..R&R2..A&AP..ZTBGFLF2 cuyo contenido son los dsnames de los

planos finales a tratar por la aplicación.

Debe existir, creado por el usuario el fichero ZTBGFDAT. Ejemplo:

***************************** Top of Data ********************************************

0- 198.172.033.233-00994-300- -

1-%O.XML - - -N-00000

2- - - -

***************************** Bottom of Data *****************************************

Si por ejemplo, el contenido de KI.PMED.R&R1..R&R2..A&AP..ZTBGFLFE era:

********************************* Top of Data ****************

KI.EIDA.FF01.XML 20130517125457FIJOEN PAGO E1

KI.EIDA.FF02.XML 20130517125458FIJOEN PAGO E2

******************************** Bottom of Data **************

El contenido del fichero KI.PMED.R&R1..R&R2..A&AP..ZTBGFLF2 será:

********************************* Top of Data ****************

KI.EIDA.FF01 -B-N-N-F

KI.EIDA.FF02 -B-N-N-F

******************************** Bottom of Data **************

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 6.OTROS.


6. OTROS.

6.1. Llamada a java en modo comando.

Para ejecutar el java en modo comando, se utiliza el JCL de IBM JZOS:

//********************************************************************

//JAVA EXEC PROC=JVMPRC60,

// JAVACLS='-jar EDITRANSepaXml.jar',

// ARGS='//''''FICHERO.ENTRADA.XML'''''

//STDENV DD *

# This is a shell script which configures

# any environment variables for the Java JVM.

# Variables must be exported to be seen by the launcher.

. /etc/profile

export JAVA_HOME=/usr/lpp/JAVA/J6.0

export PATH=/bin:"${JAVA_HOME}"/bin

LIBPATH=/lib:/usr/lib:"${JAVA_HOME}"/bin

LIBPATH="$LIBPATH":"${JAVA_HOME}"/bin/classic

LIBPATH="$LIBPATH":"${JAVA_HOME}"/bin/j9vm

LIBPATH="$LIBPATH":"${JAVA_HOME}"/lib/s390/classic

LIBPATH="$LIBPATH":"${JAVA_HOME}"/lib/s390/default

LIBPATH="$LIBPATH":"${JAVA_HOME}"/lib/s390/j9vm

#LIBPATH="$LIBPATH":"${JAVA_HOME}"/lib/s390

#LIBPATH="$LIBPATH":"${JAVA_HOME}"/bin/classic

export LIBPATH="$LIBPATH":

# Customize your CLASSPATH here

# APP_HOME=$JAVA_HOME

APP_HOME=/u/ki10628

CLASSPATH=$APP_HOME:"${JAVA_HOME}"/lib:"${JAVA_HOME}"/lib/ext

Add Application required jars to end of CLASSPATH

for i in "${APP_HOME}"/*.jar; do

CLASSPATH="$CLASSPATH":"$i"

done

export CLASSPATH="$CLASSPATH":

# Set JZOS specific options

# Use this variable to specify encoding for DD STDOUT and STDERR

#export JZOS_OUTPUT_ENCODING=Cp1047

# Use this variable to prevent JZOS from handling MVS operator commands

#export JZOS_ENABLE_MVS_COMMANDS=false

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 6.OTROS.


# Use this variable to supply additional arguments to main

#export JZOS_MAIN_ARGS=""

# Configure JVM options

IJO="-Xms16m -Xmx128m"

# Uncomment the following to aid in debugging "Class Not Found" problems

IJO="$IJO -verbose:class"

# Uncomment the following if you want to run with Ascii file encoding..

#IJO="$IJO -Dfile.encoding=ISO8859-1"

export IBM_JAVA_OPTIONS="$IJO "

/*

Si se utiliza esta opción será necesario configurar el fichero :

conf/Configuracion.properties.

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 7.ANEXO.


7. ANEXO.

7.1. Transformación con Warnings.

Dada la asimetría entre las normas de los formatos XML y plano en cuanto a obligatoriedad

y contenido de los campos en una y otra, en ocasiones el conversor genera ficheros que no

cumplen estrictamente la norma del formato final (campos obligatorios que quedan vacíos,

valores diferentes a los que indica la norma, etc.) aún cumpliéndola en el formato inicial.

Este resultado será más habitual en las transformaciones de XML a plano pues, dada la

transitoriedad de este último, se ha dado prioridad al cumplimiento de los requisitos del

formato XML.

Como el fichero inicial sí es correcto, la solución dada por EDITRAN es generar esos

ficheros pero dando un resultado especial de Warning (véase Códigos de resultado) para

poder diferenciarlo de un fichero que sí sigue rigurosamente la norma. Por defecto, los

ficheros así generados se graban como correctos en la lista de salida ZTBGFCAR.

Cuando el fichero que llega al conversor está vacío, el conversor da un código 28, la

ejecución acaba con 04 y en la lista de salida ZTBGFCAR se graba el nombre del fichero

vacío como entra al conversor( si es en procedimiento previo a emisión se cargaría el

fichero vacío).

7.2. Códigos de resultado del servidor.

Los posibles resultados son:

00 -Transformación correcta del fichero

La ejecución acabará con RC = 00

Mensaje de Aviso

28 – Fichero Vacío


Errores de comunicaciones y gestión de ficheros


01 - Error al leer el socket

02 - Error en los parámetros de entrada

03 - No se ha encontrado o tiene un valor inválido el parámetro Función de la petición

04 - No se ha encontrado el parámetro Fichero de entrada

05 - No se ha encontrado el parámetro Fichero de salida

06 - No se ha encontrado o tiene un valor inválido el parámetro Lenguaje de la petición

07 - El parámetro Validar Xml tiene un valor invalido. Puede ser [S] o [N]

08 - El parámetro “Información en el campo libre” tiene un valor inválido. Puede ser [S]

(Sí) o [N] (No)

09 - No se ha reconoce o es inválido el valor del parámetro Alfabeto



10 - Número de parámetros inválido

11 - Error al realizar la conversión

12 - Error al escribir la respuesta

13 - No se ha encontrado el fichero de entrada

14 - Error al abrir el fichero de salida

15 - Error al cerrar los ficheros

16 - Error en los ficheros

17 - Error al borrar el fichero de salida

Errores en el conversor plano a xml


18 - Error en el fichero plano. No se reconoce el tipo de norma a la que pertenece el

fichero

19 - Error al leer el fichero plano

20 - Error en el unmarshaller del plano(*)

21 - Error en la conversión entre objetos de plano a xml

22 - Error en el marshaller del xml(**)

23 - Error en el orden de los bloques del plano. El orden tiene que ser Transferencias

SEPA, Otras Transferencias y Cheques y solo un bloque de cada uno

24 - Error al incluir varios ficheros logicos. No pueden agruparse en un solo XML

25 - No coinciden los valores del campo [Fecha de Devolucion] en los registros [Cabecera

de Acreedor por Fecha]. No puede agruparse la información en un único fichero XML

Errores en el conversor xml a plano


26 - Error en el fichero xml. No se reconoce el tipo de norma a la que pertenece el fichero

29 - Error al leer el xml

30 - Error al validar el xml

31 - Error en el unmarshaller del xml(*)

32 - Error en la conversión entre objetos de xml a plano

33 - Error en el marshaller del plano(**)

34 - Error, el valor del importe es inválido



35 - Error en la escritura del fichero XML. No es posible escribir bloques PmtInf que no

sigan el orden: Transferencias SEPA, Otras Transferencias y Cheques

Error de licencia


27 - Licencia incorrecta

Warnings


36 - Transformación con Warnings del fichero


28 – Fichero de entrada vacío

ERRORES DEVUELTOS EN EL PROGRAMA ZTBXBITS

================================

RESULTADO RAZON DESCRIPCION

--------- --------------------------------------------------

91 ERROR EN EL SERVIDOR

XX RESULTADO DEL SERVIDOR

99 ERROR PROCESO REMOTO. ERROR PROGRAMA. ERROR CONEXION

A SERVIDOR. ERROR MACROS TCP

0X ERRORES DE AREAS DE LLAMADA AL PROGRAMA ZTBXBITS

99/01 FUNCION DESCONOCIDA

99/02 ALFABETO ERRONEO

99/03 FICHERO ENTRADA ERRONEO

99/04 FICHERO SALIDA ERRONEO

99/05 TABLA CARACTERES ERRONEA

99/06 TCPNAME ERRONEO

99/07 DIRECCION IP DEL SERVIDOR ERRONEA

99/08 PUERTO DEL SERVIDOR ERRONEO

99/09 SEGUNDOS ACTIVACION SERVIDOR ERRONEOS

5X ERRORES DE TIEMPO TRANSCURRIDO EN SERVER

99/53 NO SE HA CONSEGUIDO ENVIAR DATOS (NI 1 OCTETO)

99/54 NO SE HA CONSEGUIDO ENVIAR DATOS (ALGUN OCTETO)

99/55 NO SE HA CONSEGUIDO RECIBIR DATOS(NI 1 OCTETO) *



99/56 NO SE HA CONSEGUIDO RECIBIR DATOS(ALGUN OCTETO)*

6X-7X ERRORES TCP/IP EN CONEXION CON EL SERVIDOR *

99/61 ERROR EN MACRO INITAPI *

99/62 ERROR EN MACRO SOCKET *

99/63 ERROR EN MACRO GETHOSTBYNAME *

99/64 ERROR EN MACRO SETSOCKOPT *

99/65 ERROR EN MACRO FCNTL *

99/66 ERROR EN MACRO CONNECT *

99/67 ERROR EN MACRO SELECT DE ESCRITURA *

99/68 ERROR EN MACRO READ *

99/69 ERROR EN MACRO SELECT DE LECTURA *

99/70 ERROR EN MACRO WRITE *

99/71 ERROR EN MACRO EZACIC08 *

99/72 ERROR EN MACRO EZACIC06 *

8X ERRORES EN LOS DATOS QUE DEVUELVE EL SERVIDOR *

99/81 LONGITUD DE DATOS INVALIDA *

99/82 DATOS ERRONEOS *

(*) Unmarshalling: generación de objetos JAVA a partir de un fichero de datos.

(**) Marshalling: generación de un fichero de datos a partir de objetos JAVA.


Centros de Competencia

eCommerce

Avda. de Bruselas 35

28108 Alcobendas.

Madrid, España

T. +34 91 480 80 80

T. +34 91 480 50 00

www.indracompany.com

Conversor de planos formato moderno a XML y viceversa...

Documents

Transcript of Conversor de planos formato moderno a XML y viceversa...