> 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/functional-description/use-of-file-lists-by-editran.md). # Use of file lists by Editran The application allows the transmission of several files through the same session To send: * Some clients use a file list (LISTAFICH, see TABLE 1 format) to perform the loads, since their files have different names in each one. Therefore, they create a daily file list for each statement to be issued. This list is passed to the step prior to issuance. Normally, in order to use a single procedure with all remotes, the file list content is formed with variables recognizable by the procedure (source, remote and application) * § Other clients always use the same file names to be issued (each transmission has different content), so they choose to indicate in the product profiles themselves the names of the files to be issued. To receive: * In the application's profiles, the name of the files to be downloaded is indicated; it downloads the received files with the indicated name. Table 1. Content of the LISTAFICH file, a fixed-length file of 327 characters, whose content is the application files to be sent and their characteristics. The content is as follows (one record per file):
LevelNameLongTypeDescription
1Key
2Identifier1Alphanum.File record identifier “F”
2Session24Alphanum.Session: LocalCode+RemoteCode+Application
2Order Number2Alphanum.File order number
1Application File
2Physical name30Alphanum.Physical name of the application file
2filler8
2File format1Alphanum.

Application file format:

‘R’: Record, ‘B’: Binary

2Source data language1Alphanum.

Original language of the data:

‘A’: Ascii, ‘E’: Ebcdic

2Translate on issuance1Alphanum.

Language in which the data is issued:

‘A’: Ascii, ‘E’: Ebcdic, ‘N’: No translation

2Compression1Alphanum.

Compression:

‘S’ Compressed, ‘N’ Uncompressed

2Filler2
2Binary File Name251Alphanum.Binary Application File Name
2Binary file length5NumLength with zeros
Use of the free area of the records It has been agreed with certain clients to use some positions in the free areas of certain records of files in flat format. The purpose is to store there certain information that, being in the source XML file, is lost in the conversion because there is no field defined for it in the corresponding standard. This information is handled exclusively by client applications that only process flat-format files and are generally used to generate confirmation files from them directly in XML format. To make use of this functionality, 'S' must be indicated in the Free information parameter of the ZTBGFDAT file in the program call because by default the converter does not do it. The values transferred from the XML format file and the records and positions where they are left in the plain format file as a result of the transformation are described below. Issuance of transfers and checks: The content of: * \\ to position 290 of the debtor header record. * \\\ to position 325 of the debtor header record, provided that the value is different from “EUR”. * \\ to position 23 of the header records of SEPA transfers, other transfers or checks, depending on the block type of the three from which the data comes. * The value of the Ccy attribute of \\\\ or of \\\\\, provided that it is different from “EUR”, in position 502 of the first mandatory transfer beneficiary record if the source block is a SEPA transfer. * As for the total records, they collect the sum of the amounts in the file regardless of the currency in which they are expressed in their corresponding beneficiary records. * \\\\\ to position 505 of the first mandatory transfer beneficiary record if the source block is a SEPA transfer. * \\\\ to position 508 of the first mandatory transfer beneficiary record if the source block is a SEPA transfer. * \\\\ to position 521 of the first mandatory transfer beneficiary record if the source block is a SEPA transfer. * \\\\ to position 525 of the first mandatory transfer beneficiary record if the source block is a SEPA transfer. * “XML” is written in position 598 of the debtor header record. Direct debits (basic and B2B schemes): * “XML” is written in position 598 of the presenter header record. * In the conversion of the XML debit presentation to plain format, the content of the \ field is transferred to position 300 of the \[Creditor header by collection date] record. On the other hand, when the client generates the plain files, it can make use of certain free areas to store information there that would otherwise be impossible to transfer to XML format. These are the following: Issuance of transfers and checks: The content of: * 70 positions, starting at 290, from the Debtor Header to \\. This functionality is used to transform several plain logical files that do not match in debtor names into a single XML. Direct debits (basic and B2B schemes), return and rejection messages: * 35 positions, starting at 335, from the \[Creditor header by collection date] record to \\. The converter will first look for this information in the free fields and, if it is not there, it will perform the mapping as it normally does for each of those fields. --- # 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/functional-description/use-of-file-lists-by-editran.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.