> For the complete documentation index, see [llms.txt](https://docs.editran.onesait.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.editran.onesait.com/documentacion-editran/ibm-editran-v5.3-comun-z-os-en/editran-sepa/description/additional-converter-features.md). # Additional converter features ## Extension of the C19.14+ version published by CECA. It consists of adapting the converter for the SEPA debit XML files to include new tags that allow expanded concepts (up to 640 characters) to be reported in order to generate a new C19.14+ layout that differs from the current one in that it incorporates a new record type to include concepts of more than the 140 characters currently allowed. Therefore, there will be a (licensed) converter capable of handling a new version of CustomerDirectDebitInitiationV02 (pain.008.001.02) and generating a version of the C19.14+ published by CECA. ## Adaptations for TGSS signed files This functionality is an extension to Editran/SEPA that converts files with the particularities of the Social Security Treasury. ## XML separator. XML files are not designed to be nested within a single file, since the resulting file is not a valid file. In response to some customers, a new functionality has been added that converts these files with several nested XMLs into a file with their corresponding nested flat files. {% hint style="info" %} This functionality is an add-on to Editran/SEPA; therefore, it also requires an additional license to be used. If you do not have this additional license and are interested, you should contact product Support. {% endhint %} ## Flat separator. Similarly to the previous functionality, the converter can handle input files in flat format that include several logical files. In this case, the result of the conversion will be a file whose content may be a single logical XML file or several, depending on how the param.juntar.xml parameter described in section 2.4.7 or in the ZTBGFDAT 3.4.2 parameter file has been configured. First it looks at the ZTBGFDAT parameter file; if this is not specified there, it looks in Configuracion.properties; if it still does not appear, it uses the default. {% hint style="info" %} To use these separator functionalities, which require specific licenses, instead of starting Editran/SEPA using the start.sh and stop.sh scripts, the alternative scripts included in the /scripts folder must be used: startSeparador.sh and stopSeparador.sh. These scripts replace the previous ones. Before being able to use these scripts, they must first be configured. The way to configure them is exactly the same as for the scripts for Editran/SEPA. {% endhint %} ℹ️ The flat separator and XML separator need to generate some temporary auxiliary files on the UNIX side that are deleted when the process ends; the auxiliaries are always created with the input name followed by a timestamp. ℹ️ As for the temporary directory, if nothing is specified, it will use the machine's default /tmp directory. If another one is needed, it is passed with the java.io.tmpdir variable in the JAVA call (in the start or by command). ## Automatic response message. This field is used to generate response messages when certain SEPA rules are received, although it can only be used for XML to Flat conversions of rules 3414 and 19 of the Presentations type, in which this file is generated. The code returned in \ indicates whether the conversion could be performed (ACCP), or not (RJCT). The value of this field is the name of the automatic response file. By default, the response file is not created. The product also does not convert rule 57 (collections at the bank counter) With the converters, it always handles flat files in the “modern” format, with record lengths of 600. There are still entities that use the old format, with length 72 or 162, and these files are not handled by the converters described. Some entities introduce “particularities” in XML or flat files. In principle, these adaptations should be assessed technically, see whether they are possible with the distributed software, and if not, assess them economically. If these refer to the content of the XML files, to the data, but do not affect the structure required by the schema, field lengths, etc., in principle, the converter could be used as is. It is the entities that follow their own rules when preparing the files, although certain aspects must be taken into account: * One is that we must be aware that the information collected in the XML is a little more extensive than what the flat file can hold, so that data (a few) is lost when the transformation is in that direction or does not appear when it is in the opposite direction. * Another aspect is the opposite one; for example, some regulation may state that the \ tag will not be used in the header of the XML file. That tag contains the sum of the amounts of all operations in the file and, indeed, according to the schema it is not mandatory to fill it in; however, our converter always adds it since in the flat file that data is mandatory, and the guideline we are following, for the time being, is that the minimum possible information is lost in both directions. * Another example. The instruction priority is not in the flat file, therefore the XMLs we generate do not include that data, so the default is assumed to be normal priority, and therefore if the XML we process carries it, it is lost in the flat file. * In general, the file in XML format is prepared to collect more information than that specified in the flat rules. For example, in the XML rule 34 there is a message identifier that is lost when taken to flat; also in XML the creation date and time are collected, while in flat only the date can be stored. In flat rule 34-14 the presenter figure is not included, whereas information about it can be provided in the XML rule. The payment class collected in the balance of payments record of flat rule 34-14 cannot be transferred to the XML rule. In the flat rule there is no field to report the BIC of the ordering party's entity, a piece of data that is reflected in the XML rule. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.editran.onesait.com/documentacion-editran/ibm-editran-v5.3-comun-z-os-en/editran-sepa/description/additional-converter-features.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.