> 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-iseries-en/sepa/description/converter-additional-functionalities.md). # Converter additional functionalities ## Extended version of the C19.14+ published by CECA. It consists of adapting the converter for SEPA direct debit XML files to include new tags that allow expanded concepts to be reported (up to 640 characters), in order to generate a new C19.14+ booklet that differs from the current one in that it incorporates a new type of record to include concepts with 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 those files with several nested XML files 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-file separator. Similarly to the previous functionality, the converter can process flat-format input files 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, To use these separator functionalities, which require specific licenses, instead of starting editran/SEPA using the start.sh and stop.sh scripts, you must use the alternative scripts included in the /scripts folder: 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 in the editran/SEPA scripts (Installation section 2.2.1) {% 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, you must use the alternative scripts included in the /scripts folder: 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 in the Editran/SEPA scripts. {% endhint %} ℹ️ The flat-file separator and the XML separator need to generate some temporary auxiliary files on the UNIX side, which are deleted when the process finishes; the auxiliary file name is always created using 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 the 3414 and 19 rules 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 application also does not convert rule 57 (cash 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 technically assessed, to 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, 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 contained in the XML is a little more extensive than what the flat file can hold, so that data (a few items) 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. For example, some regulations may indicate that the \ tag will not be used in the XML file header. That tag contains the sum of the amounts of all the transactions in the file and, indeed, according to the schema it is not mandatory to fill it in; however, our converter always adds it because in the flat file that data is mandatory, and the guideline we are following, for the moment, is to lose as little information as possible in both directions. * Another example. The instruction priority is not in the flat file; therefore, the XML we generate does not include that data, so normal priority is assumed by default, and therefore if the XML we process contains it, it is lost in the flat file. * In general, the XML-format file is prepared to hold more information than specified in the flat rules; for example, in the XML version of rule 34 there is a message identifier that is lost when converted to flat, and the XML also records the creation date and time while the flat version can only store the date. 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 recorded in the balance-of-payments record of flat rule 34-14 cannot be transferred to the XML rule, and in the flat rule there is no field to report the BIC of the ordering entity, a datum 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-iseries-en/sepa/description/converter-additional-functionalities.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.