Funcionalidades adicionales conversor
Ampliacion 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.
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.
Separador XML.
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.
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 del producto.
Separador Plano.
De manera análoga a la funcionalidad anterior, el conversor puede tratar ficheros de entrada de formato plano que incluyan varios ficheros lógicos. En esta caso, el resultado de la conversión será un fichero cuyo contenido podrá ser un único fichero XML lógico o varios, dependiendo de cómo se haya configurado el parámetro param.juntar.xml descrito en el apartado 2.4.7 o en el fichero de parámetros ZTBGFDAT 3.4.2.
Primero mira el fichero de parámetros ZTBGFDAT, si éste no está informado mira en Configuracion.properties, si tampoco aparece hace el defecto.
Para utilizar estas funcionalidades de los separadores, que requieren licencias específicas, en vez de iniciar Editran/SEPA usando los scripts start.sh y stop.sh, se deben usar los scripts alternativos incluidos en la carpeta /scripts: startSeparador.sh y stopSeparador.sh. Estos scripts sustituyen a los anteriores.
Antes de poder usar estos scripts, se debe configurarlos primero. La forma de configurarlos es exactamente la misma que en los scripts para Editran/SEPA.
ℹ️ El separador plano y el separador XML 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).
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.
El producto, no convierte tampoco la norma 57 (cobros en ventanilla bancaria)
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 o planos. En principio, habría que valorar técnicamente esas adaptaciones, ver si son posibles con el software distribuido, y si no fuera el caso valorarlas económicamente.
Si las mismas se refieren al contenido de los ficheros XML, a los datos, pero no afectan a la estructura que exige el esquema, longitudes de los campos, etc., en principio, el conversor podría servir tal cual está son las entidades, las que siguen su propio reglamento a la hora de confeccionar los ficheros, si bien hay que tener en cuenta ciertos aspectos:
Uno es que hay que ser conscientes de que la información que recoge el XML es un poco más extensa que la que puede alojar el fichero plano, por lo que esos datos (pocos), se pierden cuando la transformación es en ese sentido o no aparecen cuando son en el sentido contrario.
Otro aspecto es el contrario, por ejemplo, puede que alguna normativa indique que no se va a utilizar la etiqueta <CtrlSum> en la cabecera del fichero XML. Dicha etiqueta recoge la suma de los importes de todas las operaciones del fichero y efectivamente según el esquema no es obligatorio rellenarla, sin embargo, nuestro conversor siempre la añade puesto que en el fichero plano ese dato sí es obligatorio y la pauta que estamos siguiendo, por el momento, es la de que se pierda el mínimo de información posible en ambos sentidos.
Otro ejemplo. La prioridad de la instrucción no está en el plano, por tanto, los XML que generamos no incluyen ese dato, por lo que se supone el defecto que es prioridad normal, y por tanto si el XML que tratamos lo lleva, en el plano se pierde.
En general el fichero en formato XML está preparado para recoger más información que la especificada en las normas planas, por ejemplo en la norma XML de la norma 34 hay un identificador de mensaje que se pierde al llevarlo a plano, también en el XML se recogen la fecha y la hora de creación mientras que en el plano sólo es posible almacenar la fecha, en la norma plana 34-14 no se recoge la figura de presentador sobre la que en cambio sí se puede dar información en la norma XML , la clase de pago que se recoge en el registro de balanza de pagos de la norma plana 34-14 no se puede trasladar a la norma XML, en la norma plana no existe campo donde informar del BIC de la entidad del ordenante, dato que sí se refleja en la norma XML.
Última actualización