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 26 de septiembre de 2017

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

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

(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

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

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

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

(5)

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

(6)

 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

(7)

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

(8)

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

Esta funcionalidad es una ampliación a EDITRAN/SEPA que convierte ficheros con varios planos anidados en un fichero con sus correspondientes XML anidados

Adaptaciones para los ficheros firmados de TGSS

Esta funcionalidad es una ampliación a EDITRAN/SEPA que convierte ficheros con las particularidades de la Tesorería de la Seguridad Social.

(9)

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

(10)

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

(11)

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

(12)

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

(13)

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

(14)

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

(15)

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

(16)

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

(17)

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

(18)

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.

(19)

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 ZTBGFDAT, puede ser distinto para cada sesión. En ese caso, en el

(20)

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.

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

(21)

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

(22)

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:

(23)

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

https://docs.oracle.com/javase/8/docs/ technotes/guides/intl/encoding.doc.html l

3 Guión separador Alfn 1 66 _Opcional Guión

(24)

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

m

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 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 PLANO) Alfn 1-44 3 Obligatori o-opcional

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

transformados:

1-Se admite el uso de variables conocidas por EDITRAN, por ejemplo Origen, Destino, Aplicación, AÑO, MES, DIA, DSNAME ORIGEN, etc (Ver tabla

3)

2.-Se puede poner un nombre fijo

3.-Si no se indica nada (espacios) y el fichero de entrada se llama DSNAME.A.XML, se crea un plano de salida llamado DSNAME.A. En el caso de que usted esté habituado en EDITRAN a poner el DSNAME.A, cámbielo por DSNAME.A.XML, porque el resultado final será el que tenía hasta ahora. .

OPCION RECOMENDADA

4.-Si no se indica nada (espacios) y el fichero de entrada se llama DSNAME.XML, se crea por defecto el fichero DSNAME.PLN

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

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

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

(25)

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario ‎3.Descripción de la funcionalidad. 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 Espacio reservado Alfn 1 80 Opcional

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

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

(26)

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

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.

(27)

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario ‎3.Descripción de la funcionalidad. 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], [Registro total de Otras transferencias] o [Registro total de Cheques] según corresponda por tipo de bloque, cuando más de 8 cifras.

(28)

EDITRAN/XML SEPA 5.X CICS-IMS Manual de usuario ‎3.Descripción de la funcionalidad. 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 supere las 8 cifras que contempla el formato plano.

 <OrgnlGrpInfAndSts><OrgnlCtrlSum> a la posición 38 del [Registro total general]. Se utilizará para recoger importes de 18 cifras en total (la norma de formato plano contempla hasta 17).

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