EDITRAN/XML SEPA 5.X. Manual de usuario. Conversor de planos formato moderno a XML y viceversa CICS-IMS

(1)

EDITRAN/XML SEPA 5.X

Conversor de planos formato moderno a XML y viceversa

CICS-IMS

Manual de usuario

INDRA 19 de junio de 2015

(2)

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario ÍNDICE 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 2. SEPARADOR XML ... 2-4 2.4. Instalación: ... 2-5 2.4.1. ZOS CICS. ... 2-5 2.4.2. ZOS IMS. ... 2-5 2.4.3. ZOS COMUN (FICHERO DE USUARIO) ... 2-5 2.4.4. ZOS COMUN (JAVA) ... 2-6 2.4.4.1. Descarga de software. ... 2-6 2.4.4.2. Inserción del paquete en los servicios UNIX del zos. ... 2-6 2.4.4.3. Instalación del paquete. ... 2-7 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 3.5. JCLS y PROCEDIMIENTOS. ... 3-15 3.5.1. JCLS. ... 3-15 3.5.2. Procedimientos. ... 3-17 3.5.2.1. Previo a emisión... 3-17 3.5.2.2. Posterior a recepción. ... 3-19 4. OTROS. ... 4-1 4.1. Llamada a java en modo comando. ... 4-1 5. ANEXO. ... 5-1 5.1. Transformación con Warnings. ... 5-1 5.2. Códigos de resultado del servidor. ... 5-1

(3)

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

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

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

(4)

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.

La normativa concreta que cumplen nuestros conversores es la siguiente:  SEPA – 14 (ficheros planos)

- 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

(5)

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 2.Requisitos e instalación. - 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

 Órdenes en formato ISO 20022 (ficheros xml)

- 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. Sigue los esquemas pain.008.001.02.xsd, pain.002.001.03.xsd y pain.007.001.02.xsd

- 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. Sigue los esquemas pain.008.001.02.xsd, pain.002.001.03.xsd y pain.007.001.02.xsd

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

(6)

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 2.Requisitos e instalación. 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.

Para usar esta funcionalidad en el caso de tener licencia, 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.4.3 paso d) y e) ).

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.

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:

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

o 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

(7)

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 2.Separador XML 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.

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

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

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

(8)

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 2.Separador XML

2.4. Instalación:

2.4.1. ZOS 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: ZTBGBXML, ZTBXBITS, ZTBGBGPG y ZTBLBLLI Procedimientos: ZTBGP1CX y ZTBGP4CX

Jcls: ZTBGJXML

2.4.2. ZOS IMS.

Si licencia EDItran/IMSse recibe.

Licencia (si se contrata esta funcionalidad). Para instalarla debe pasar el jcl ZTBLJG02. Ejecutables Batch: ZTBGBXML, 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).

(9)

2.4.4. ZOS COMUN (JAVA)

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

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

(10)

2.4.4.3.Instalación del paquete.

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

(11)

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 queremos validar en la conversión el XML de entrada contra su esquema, siendo sus posibles valores S (Sí) o N (No). Por defecto se valida el XML. Sólo funciona de XML a plano

 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 el capítulo ¡Error! No se encuentra el origen de la referencia.. 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.

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 “NOT PROVIDED” 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.

(12)

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.

(13)

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 2.Separador XML 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

(14)

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

(15)

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

(16)

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

(17)

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.

(18)

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 3.Descripción de la funcionalidad. 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

(19)

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 3.Descripción de la funcionalidad. 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 “a pelo”.

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

(20)

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 3.Descripción de la funcionalidad. 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 a pelo (&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

(21)

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 3.Descripción de la funcionalidad. 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:

Niv el Nombre Tip o Lon g Posició n Uso Descripción 1 Tipo de Registro Nu m. 1 1 Obligatori o 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 Obligatori o

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

3 Guión separador Alfn 1 67 Opcional Guión 3 Puerto del servidor

java

Nu m

5 68 Obligatori o

Puerto de escucha del servidor java 00001 a 65536 3 Guión separador Alfn 1 73 Opcional Guión

3 Segundos de espera del servidor

Nu m

3 74 Obligatori o

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

3 Mantener F. salida Alfn 1 80 Opcional Mantener el fichero de salida si error Valor:

(22)

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 3.Descripción de la funcionalidad. N el fichero de salida se borra

Defecto N 3 Guión separador Alfn 1 81 Opcional Guió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 Guión separador Alfn 1 83 _Opcional Guión

3 Filler Alfn 3 84 Opcional Area de reserva

Datos de transformación PLANO a XML

3 Guión separador Alfn 1 2 Opcional Guión 3 DSNAME de fichero salida (DNSMAME del XML) Alfn 1-44 3 Obligatori o-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 Guión separador Alfn 1 47 Opcional Guión

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:

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

3 Guión separador Alfn 1 66 Opcional Guión 3 Tamaño del fichero

de salida

Nu m

12 67 Opcional Tamaño en bytes del fichero de salida.

Si no se especifica nada, EDItran crea por defecto un fichero de salida de 99.999 bytes.

Si se especifica cualquier valor, EDItran calcula el espacio a alocar el fichero de salida de la siguiente forma: coge el valor especificado en nro de bytes y la divide por la longitud de registro máxima de un variable (32752), en que quedará el xml. 3 Guión separador Alfn 1 79 Opcional Guión

3 Reserva Alfn 1 80 Opcional

3 Guión separador Alfn 1 81 Opcional Guión 3 Longitud de registro

del XML de salida Nu m

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 Guión separador Alfn 1 2 Opcional Guión 3 DSNAME de fichero salida (DNSMAME del Alfn 1-44 3 Obligatori o-opcional

Dsname del fichero transformado PLANO. En este caso, como puede haber varios ficheros

(23)

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 3.Descripción de la funcionalidad. 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 no se llama DSNAME.XML, se crea por defecto el fichero DSNAME.PLN

3 Guión separador Alfn 1 47 Opcional Guión 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:

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

3 Guión separador Alfn 1 66 Opcional Guión 3 Tamaño del fichero

de salida

Nu m

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

3 Validar XML Alfn 1 80 Opcional Valor:

S Validar el XML N No validar XML Defecto S

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

3 Guión separador Alfn 1 2 Opcional Guión 3 Crear XML CONF

(Ace-Rech)

Alfn 1 3 Obligatori

o-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 Guión separador Alfn 1 4 Opcional Guión 3 DSNAME de fichero salida (DNSMAME del XML ACE/RECH) Alfn 1-44 5 Obligatori o-opcional

Dsname del fichero XML que contiene la aceptación ó el rechazo.

1.- Si se indica CREAR XML CONF = ‘N’, se ignora lo que hubiera en este campo

2.- Si se indica CREAR XML CONF = ‘S’

2.1- Si DSNAME del XML ACE/RECH = espacios, se crea un XML de confirmación, cuyo DSNAME = XML-entrada.CONF

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 usuario, es responsable de crear una lista de ficheros con el

(24)

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 3.Descripción de la funcionalidad. mismo (y que coincida con lo indicado aquí), ó indicarlo 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 Guión separador Alfn 1 49 Opcional Guión

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.

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 de transferencias si el bloque de origen es de transferencia SEPA.

 En cuanto a los registros de totales, recogen la suma de importes del fichero independientemente de la divisa en la que estén expresados en sus registros de beneficiario correspondientes.

 <PmtInf><CdtTrfTxInf><Amt><EqvAmt><CcyOfTrf> a la posición 505 del primer registro obligatorio de beneficiario de transferencias si el bloque de origen es de transferencia SEPA.

 <PmtInf><CdtTrfTxInf><XchgRateInf><XchRate> a la posición 508 del primer registro obligatorio de beneficiario de transferencias si el bloque de origen es de transferencia SEPA.

 <PmtInf><CdtTrfTxInf><XchgRateInf><RateTp> a la posición 521 del primer registro obligatorio de beneficiario de transferencias si el bloque de origen es de transferencia SEPA.

(25)

 <PmtInf><CdtTrfTxInf><XchgRateInf><CtrctId> a la posición 525 del primer registro obligatorio de beneficiario de transferencias si el bloque de origen es de transferencia SEPA.

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

Adeudos directos (esquemas básicos y B2B):

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

 En la conversión de la Presentación de adeudos de XML a plano, se traslada el contenido del campo <PmtInfId> a la posición 300 del registro de [Cabecera de acreedor por fecha de cobro].

Por su parte, cuando sea el cliente quien genere los ficheros planos, puede hacer uso de ciertas zonas libres para alojar en ellas información que de otra manera sería imposible trasladar al formato XML. 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.

Adeudos directos (esquemas básicos y B2B), mensajes de devolución y rechazos:

 35 posiciones, comenzando en la 335, del registro de [Cabecera de acreedor por fecha de cobro] a <OrgnlPmtInfAndSts><OrgnlPmtInfId>.

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>

(26)

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 3.Descripción de la funcionalidad. <CreDtTm>2014-03-14T11:30:00</CreDtTm>

<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

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.

(27)

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 3.Descripción de la funcionalidad.  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.

(28)

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 3.Descripción de la funcionalidad. 3.5. JCLS y PROCEDIMIENTOS. 3.5.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

(29)

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 3.Descripción de la funcionalidad. // 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) //* //PASO01 EXEC PGM=ZTBXBXML, // PARM='&L1&L2&R1&R2&AP&FU&TI&FI/CBLQDA(ON)' //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 //ZTBGFDAT DD DSN=KI.EIDC.ZTBG.ZTBGFDAT,DISP=SHR //ZTBGFCAR DD DSN=KI.PMED.R&R1..R&R2..A&AP..LISTFICX, // 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, // DISP=(NEW,CATLG,DELETE), // SPACE=(TRK,(500,50),RLSE), // DCB=(RECFM=FB,LRECL=252,BLKSIZE=0,DSORG=PS) //SYSOUT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSDBOUT DD SYSOUT=* //ABENDAID DD SYSOUT=* //SYSCOUNT DD DUMMY //SYSUDUMP DD SYSOUT=* //SYSABOUT DD SYSOUT=*

Hemos indicado origen (000099990) destino (000099940), aplicación (PEPITA), 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 descarga, si por ejemplo codificamos en PARM 000099990000099940PEPITAPFKI.FICHERO.ENTRADA.XML

(30)

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario 3.Descripción de la funcionalidad. Y en el fichero ZTBGFDAT hemos indicado un registro de tipo 2, sin nombre de fichero de salida, se creará el PLANO KI.FICHERO.SALIDA

3.5.2. Procedimientos. 3.5.2.1.Previo a emisión.

Se proporciona el previo ZTBGP1CX. Actualmente, al previo a emisión estándar (ZTBGP1C), tiene lo siguiente: // PROC ORIGEN=,FUNCION=,L0=, // 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):

// PROC ORIGEN=,FUNCION=,L0=, // 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 *