> 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/descripcion-de-la-funcionalidad/datos-de-entrada-salida-para-los-conversores.md). # Input/output data for the converters ## Output data In all cases, a DD will be indicated, which is the list of output files generated by the converter (not to be confused with the list of input files that the user may have created and that could even reach A1P earlier). This list of output files will be the one that must be in step A1P (in addition to setting the variable LF=S). To see the format of the ZTBGFCAR, see [Table 1](/documentacion-editran/ibm-editran-v5.3-comun-z-os-en/editran-sepa/descripcion-de-la-funcionalidad/uso-de-listas-de-ficheros-por-onesait-ecosystems-editran.md). ```cobol //ZTBGFCAR DD DSN= KI.PMED.&L0..R&R1..R&R2..A&AP..LISTFICX,DISP=SHR ``` In the case of post-reception or JCL, this list contains the final DSNAMEs of the generated flat files. Therefore, if the user until now was indicating a file list to step A1P, it will be included as input data to the converter; the converter generates a file list (different from the previous one), which will be the one that reaches A1P. The converter can also generate a ZTBXFSAL with the result of the files passed to the converter (see table 3). If this is not desired, do not include the card or set SYSOUT \*. ```cobol //ZTBXFSAL DD DSN= KI.PMED.&L0..R&R1..R&R2..A&AP..ZTBXFSAL,DISP=SHR ``` If the converter is being used integrated with Editran, with the previous and subsequent procedures you can obtain the messages in the Editran/G LOG, including the converter step with its DD card. If this functionality is not desired, do not include the DD card. ```cobol //ZTBGFLOG DD DSN=PUNTERO.INDRA.ZTBGFLOG,DISP=SHR ``` LOG example: ``` U ZTB0000 000099940 000099990 CARGAC 05/02/2014 15:29:29 KI0F6AEA 04203 ERROR CALLING ZTBXBITS FILE TRANSFORMATION. U ZTB0000 000099940 000099990 CARGAC 05/02/2014 15:29:30 KI0F6AEA 04203 Error in the XML marshaller ``` Table 3. Content of the ZTBXFSAL file, fixed file with length 252, whose content is the files that go through the converter and the result of the conversion. The content is as follows:
LevelNameLengthTypeDescription
1Input physical name44Alphan.Physical name of the application file that enters the converter
1Filler1Alphan.Separator dash
1Output physical name44Alphan.Physical name of the application file generated by the converter
1Filler1Alphan.Separator dash
1CGO result of the converter4No.Result returned by the converter
1Filler1Alphan.Separator dash
1Error text80Alphan.Text of the error message returned by the converter
1rest of record77Alphan.Reserve area
## Input data. To call the converters, use: * Data via PARM * Data entered in a user file, (which can always be the same for all or, if not valid, can be built with variables). This ZTBGFDAT file can be different for each session. In that case, in the procedure we will specify a DSNAME with variables, for example, source, remote, application, etc. Example: ```cobol //ZTBGFDAT DD DSN=KI.PEPE.&L0..R&R1..R&R2..A&AP..ZTBGFDAT,DISP=SHR ``` ### Data passed to the converter via PARM. The following data must be passed to the converter via PARM: 1. Source. Source Rbe. In the case of non-Editran JCLs, the entity code is entered. Otherwise, the input variable for the procedure is passed (\&L1\&L2). 2. Destination. Destination Rbe. In the case of non-Editran JCLs, the code of a destination entity example is entered. Otherwise, the input variable for the procedure is passed (\&R1\&R2). 3. Application. Editran/G application. In the case of non-Editran JCLs, the code of a sample application/g is entered. Otherwise, the input variable for the procedure is passed (\&AP) 4. Function: (X) - Flat file to XML, (P) - XML to flat file 5. Type of input file (in the case of function X it refers to the FLAT FILE, in the case of function P, it refers to the XML). * (F) File. The JCL or procedure carries an input file with a DSNAME. * (L) List. The JCL or procedure carries a list of input files. * In procedures prior to issuance (function X flat file to XML). If you use file lists in loading, it is recommended to use this option. * In procedures after receipt (function P XML to flat file). The standard product procedure leaves a list of received files, so it is recommended to use this option as input data to the XML to flat file converter step. * (P) Profiles. The JCL or procedure does not carry an input file or list of input files. The issuing application files are taken from whatever is in the application profiles. * In procedures prior to issuance. If you use Editran profiles for loading, it is recommended to use this option. * In procedures after receipt (function P, XML to flat file), this option makes no sense. 6. DSNAME of the input file (it cannot be a member of a partitioned dataset). * If input file type is P, nothing will be indicated. * If input file type is F, a file name will be indicated here (directly or with variables). * If input file type is L, a list whose content is the files to be transformed will be indicated here (see Table 1). If the user was already using a file list, that name will be indicated here. PARM example, in a pre-issuance procedure with a file list: ```cobol // 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, ``` We are indicating that the session is L1+L2 (source), R1+R2 (destination), AP (application), (FU)nction X (flat file to XML), (TI)pe: (L)ist of files and FI (the dsname of the list is KI.EGDC.xxx.Ryyy.Ryyyyyy.Azzzzzz.LCAR) (where xxx is the local environment alias, yyyyyyyyy is the remote code, zzzzzz is the application). In addition, the LF = S variable is set, because step A1P will require it that way. * In loads, in ALL cases (LIST (L), FILE (F), PROFILES (P)) the DD ZTBGFCAR must be indicated, which in turn must be in step A1P. In addition, it must be indicated that it be deleted beforehand (or afterwards) and in the procedures the variable LF=S must be set. This ZTBGFCAR is the list that contains the XMLs that the application will load (not to be confused with the list of files that the user can provide to the converter) or the list of TRANSFORMED files (in the case of launching JCL or in the case of post-reception). * In downloads, a list of ZTBGFLFE files is received from step A4P (created by the application), so .PL&\&LFE must always be indicated. The converter step will create a new list of transformed files ZTBGFCAR in all cases. * When this converter is launched outside the application, (in a separate jcl), it is normal to use Input file type F (\&TI=F), since a file name can be included directly (\&FI). * When this converter is launched inside the application (embedded in the procedures prior to issuance and after receipt): * In pre-issuance (loads): * If the user is already building a file list, for example KI.EGDC.xxx.Ryyy.Ryyyyyy.Azzzzzz.LCAR, they must continue doing so in this way, indicating the name in variable \&FI and indicating \&TI=L : * If the user relies on Editran profiles to perform the loads, they must continue to do so normally, indicating \&TI=P * Normally, the F option will not be used, since that would probably mean generating a different procedure for each presentation session. * The converter, in all cases, generates a new file list that will be passed to step A1P. This file list is generated with the name that we have put in the DD //ZTBGFCAR DD xxxxx * In post-reception (downloads): * The converter step will create a new list of transformed files ZTBGFCAR in all cases ### Data passed to the converter via user file (ZTBGFDAT). In all cases, it is necessary for the user to create a file (or n) with certain parameters that will normally always be the same. This file is called ZTBGFDAT and is a flat file with LRECL of 86 and FB. The content of this file is as follows:
LevelNameTypeLengthPosUseDescription
1Record TypeNo.11Required

Record type:

0- java server connection data

1-Data for the transformation from FLAT FILE to XML

2-Data for the transformation from XML to FLAT FILE

3-Confirmation-rejection record for direct debits and transfers

*-Commented record

2Type 0 recordsJava server connection data
3Separator hyphenAlphanumeric12OptionalHyphen
3IP or DNS of the java serverAlphanumeric1-643Required

IP xxx.xxx.xxx.xxx or DNS of the java server

Right-aligned.

3Separator hyphenAlphanumeric167OptionalHyphen
3Java server portNo.568RequiredJava server listening port 00001 to 65536
3Separator hyphenAlphanumeric173OptionalHyphen
3Server wait secondsNo.374Required

Maximum seconds (001-999) for which the TCP client waits for a response from the java server.

If 999 is indicated, the TCP client waits indefinitely.

3Separator hyphenAlphanumeric177OptionalHyphen
3Free informationAlphanumeric178Optional

Value:

S incorporate values in the free area of the flat file

N Do not incorporate values

Default value N

3Separator hyphenAlphanumeric179OptionalHyphen
3Keep output fileAlphanumeric180Optional

Keep the output file if error

Value:

S the output file is not deleted

N the output file is deleted

Default N

3Separator hyphenAlphanumeric181OptionalHyphen
3Remove SEPA Spain XML validationsAlphanumeric182Optional

Optional. If this field is not present, the default option is N

Value:

S Removes SEPA Spain validations

N Adds SEPA Spain validations

3Separator hyphenAlphanumeric183OptionalHyphen
3Validate XMLAlphanumeric184Optional

Optional. If this field is not present, the default option is S

Value:

X Validates the XML generated by the converter

P Validates the XML that enters the converter

S Validates the XML in both directions

N Does not validate XML in any case

Warning: by disabling this validation, the files obtained could contain errors.

3Separator hyphenAlphanumeric185OptionalHyphen
3TGSS headerAlphanumeric186Optional

Optional. If this field is not present, the default option is N

Value:

T This is a TGSS conversion with FF

N Normal SEPA conversion (not TGSS)

Warning: by activating this parameter, all 34.14s that enter the converter will be considered TGSS and it will try to put the header.

**Automatic confirmation will not be generated even if indicated in this type 3 record file.

2Type 1 recordsData for transformation from FLAT FILE to XML
3Separator hyphenAlphanumeric12OptionalHyphen
3Output file DSNAME (DNSMAME of the XML)Alphanumeric1-443Required-optional

DSNAME of the XML transformed file. In this case, as there may be several transformed files

1.- Variables known by Editran can be used, for example, Origin, Destination, Application, YEAR, MONTH, DAY, SOURCE DSNAME, etc. (See Table 3)

2.- A fixed name can be used

3.-If nothing is indicated (spaces), Editran creates output files with the name: DSN-ENTRADA.XML. This is the recommended option, since the converter will automatically create a file list, which will be loaded by Editran, so that profiles do not have to be modified.

3Separator hyphenAlphanumeric147OptionalHyphen
3Source application file character tableAlphanumeric1848Optional

Name of the character table (encoding) in which the source file is found. If nothing is specified, the default table of the z/OS where it is running is used, as long as the param.alfabeto of Configuracion.properties is not parameterized. In the following link, the supported tables appear: https://docs.oracle.com/en/java/javase/11/intl/supported-encodings.html#GUID-D29CF3AD-FC0B-465F-8897-C38C0395AB02

⚠️ In case the param.alfabeto option of Configuracion.properties is configured, it will take precedence over this parameter.

3Separator hyphenAlphanumeric166OptionalHyphen
3Output file sizeNo.1267Optional

Size in bytes of the output file.

If nothing is specified, Editran creates by default an output file of 99,999 bytes.

If any value is specified, Editran calculates the space to allocate the output file as follows: it takes the value specified in bytes and divides it by the maximum record length of a variable (32752), in which the XML will remain.

3Separator hyphenAlphanumeric179OptionalHyphen
3Merge XMLNo.180Optional

Value:

S.- Whenever possible (creation date, ordering party/creditor identification, etc. match in all cases), unify all the information of each logical input into a single logical and physical XML output file.

N.- Obtain an output file with as many logical XML documents as the original has logical flat files.

The default value is S.

3Separator hyphenAlphanumeric181OptionalHyphen
3Output XML record lengthNo.582Optional

Value:

Size of the record we want to give to the XML file generated by the converter.

Zeros, spaces or low-values as before

Default 27990

2Type 2 recordsData for transformation from XML to FLAT FILE
3Separator hyphenAlphanumeric12OptionalHyphen
3Output file DSNAME (DNSMAME of the FLAT FILE)Alphanumeric1-443Required-optional

DSNAME of the transformed FLAT FILE. In this case, as there may be several transformed files:

1-Variables known by Editran can be used, for example, Origin, Destination, Application, YEAR, MONTH, DAY, SOURCE DSNAME, etc. (See table 3)

2.- A fixed name can be used

3.-If nothing is indicated (spaces) and the input file is called DSNAME.A.XML, an output flat file called DSNAME.A is created. In the event that you are used in Editran to putting DSNAME.A, change it to DSNAME.A.XML, because the final result will be the same as before. . RECOMMENDED OPTION

4.-If nothing is indicated (spaces) and the input file is called DSNAME.XML, the DSNAME.PLN file is created by default

3Separator hyphenAlphanumeric147OptionalHyphen
3Character table into which the flat file will be transformedAlphanumeric1848Optional

Name of the character table into which the flat file should be transformed. If nothing is specified, the default table of the z/OS where it is running is used, as long as the param.alfabeto of Configuracion.properties is not parameterized. In the following link, the supported tables appear: https://docs.oracle.com/en/java/javase/11/intl/supported-encodings.html#GUID-D29CF3AD-FC0B-465F-8897-C38C0395AB02

⚠️ In case the param.alfabeto option of Configuracion.properties is configured, it will take precedence over this parameter.

3Separator hyphenAlphanumeric166OptionalHyphen
3Output file sizeNo.1267Optional

Size in bytes of the output file.

If nothing is specified, Editran checks that it is a file list (usual option when downloading, as INPUT FILE OPTION = L, VIA PARM). In it, the bytes of the downloaded file appear

If the PARM option has INPUT FILE=F (option P not allowed for downloads), Editran creates by default an output file of 99,999 bytes

If you specify something, that takes precedence.

3Separator hyphenAlphanumeric179OptionalHyphen
3Reserved spaceAlphanumeric180Optional
2Type 3 recordsXML generation data with acceptance or rejection (direct debits-transfers)
3Separator hyphenAlphanumeric12OptionalHyphen
3Create CONF XML (Acc-Rej)Alphanumeric13Required-optional

Create CONF XML (Y/N), for acceptance or rejection (direct debits and transfers), depending on the XML received.

If N is indicated, a confirmation file is never created:

If S is indicated, a confirmation file is created **

(see DSNAME of the ACE/REJ XML)

3Separator hyphenAlphanumeric14OptionalHyphen
3Output file DSNAME (DNSMAME of the ACE/REJ XML)Alphanumeric1-445Required-optional

DSNAME of the XML file that contains the acceptance or rejection.

1.- If CREATE CONF XML = 'N' is indicated, whatever is in this field is ignored

2.- If CREATE CONF XML = 'S' is indicated

2.1- If DSNAME of the ACE/REJ XML = spaces, a confirmation XML is created, whose DSNAME = input XML.CNF

2.2- If DSNAME of the ACE/REJ XML contains a DSNAME, a confirmation XML is created with that DSNAME

If CREATE CONF XML='S'.

The resulting confirmation file will be the user's responsibility to load and issue:

Either by creating a file list with it (and matching what is indicated here).

Or by indicating it in the session profile as a file to issue.

It is also responsible for linking a loading procedure if applicable.

3Separator hyphenAlphanumeric149OptionalHyphen
3Create CONF XML with NIFAlphanumeric150Optional

Create CONF XML with NIF (Y/N), included in the OrgnlMsgId tag.

If N is indicated, the standard OrgnlMsgId will be generated

If S is indicated, a confirmation file is created with OrgnlMsgId nif+ standard

Example of content in 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 -S ***************************** Bottom of Data ***************************************** ``` In the previous case: * There is a type 0 record (java server connection data). The IP of the java server (z/OS USS) is 111.22.33.444, port 994. The TCP client waits a maximum of 5 minutes (300 seconds) for the server to resolve the process. * Incorporates values in the free area of the flat file * Keeps the output file if error * Removes SEPA Spain validations * Validates the XML in both directions * This is a TGSS conversion with FF (it is recommended to create a special ZTBGFDAT for the conversion of TGSS 34.14s). * There is a type 0 record (commented), the same, but in this case, a DNS is used. * There is a type 1 record (data for the transformation from FLAT FILE to XML. It tells us (by not putting an output dsname), that if, for example, the flat file is called KI.PEPE, the XML file will be called KI.PEPE.XML. In addition, it is in the system language, so no character table is indicated. It also indicates that the application calculates the default output file size. * There is a type 2 record (data for the transformation from XML to FLAT FILE. By not indicating anything in the transformed file name, if, for example, the XML is called KI.PEPE.XML, the output flat file will be called KI.PEPE (it removes .XML). If the XML is called KI.PEPE, the output flat file will be called KI.PEPE.PLN. * It also indicates that the XML be validated against the Schema since no value has been included in the Validate XML field and the default value is S. * In addition, it is in the system language, so no character table is indicated. It also indicates (by not putting anything) that if TIPO=FILE, \&TI=F, the application calculates the default output file size. * Use of the free area of the records, in the example it uses this functionality since 'S' is indicated in the Free information parameter. * Use of record size for the XML file generated by the converter, in this case it will be LRECL 3000. * Keep the output file if error, in the example, in case of error in the converter, the generated output file will not be deleted. * A confirmation file (acceptance or rejection) will be generated automatically. * If a name is entered that follows the same mechanics as that of records 1 and 2. The presenter's NIF will be included at the beginning in the confirmation file in the OrgnlMsgId tag. ### Use of the free area of the records The use of some positions in the free areas of certain records in the flat-file format has been agreed with certain clients. The purpose is to read (flat file to XML) or write (XML to flat file) certain information in them that would otherwise be lost because no field is defined for it in the corresponding standard. This information is handled by client applications that only interpret flat-file formats and are usually used to generate confirmation files directly in XML format from them. To use this functionality, ‘S’ must be indicated in the Free information parameter of the ZTBGFDAT file in the program call, since by default the converter does not perform it. ## XML to flat file The values transferred from the XML-format file and the records and positions where they are placed in the flat-file format are described below. All those positions in the free areas that are not used with this functionality will remain blank. ### Issuance of transfers and cheques: The content of: * \\ to position 290 of the payer header record. * \\\ to position 325 of the payer header record, provided the value is different from “EUR”. * \\\\\\ to position 328 of the payer header record. * “XML” is written in position 598 of the payer header record. * \\ to position 23 of the SEPA transfers header records, other transfers or cheques, depending on the type of block from which the data comes. * The value of the Ccy attribute of \\\\ or of \\\\\, provided it is different from “EUR”, in position 502 of the first mandatory beneficiary record if the source block is a SEPA Transfer or in position 333 of the same record if the source block is of the Other Transfers type. * \\\\\ to position 505 of the first mandatory beneficiary record if the source block is a SEPA Transfer or to position 336 of the same record if the source block is of the Other Transfers type. * \\\\ to position 508 of the first mandatory beneficiary record if the source block is a SEPA Transfer or to position 339 of the same record if the source block is of the Other Transfers type. * \\\\ to position 521 of the first mandatory beneficiary record if the source block is a SEPA Transfer or to position 352 of the same record if the source block is of the Other Transfers type. * \\\\ to position 525 of the first mandatory beneficiary record if the source block is a SEPA Transfer or to position 356 of the same record if the source block is of the Other Transfers type. * \\ to position 41 of the \[General total record] if it contains 18 digits. * \\ to position 59 of the \[General total record] if it contains more than 8 digits. * \\ to position 41 of the \[SEPA transfer total record], \[Other transfer total record] or \[Cheque total record], as applicable by block type, when it contains 18 digits. * \\ to position 59 of the \[SEPA transfer total record], \[Other transfer total record] or \[Cheque total record], as applicable by block type, when it contains more than 8 digits. * \\ (for both legal entity and natural person) to positions 405-440 of the \[Optional Third Beneficiary Record]. ### Direct debits (basic and B2B schemes): * “XML” is written in position 598 of the presenter header record. * Submissions, the content of: * \\\ to position 167 of the \[Presenter header record]. * \\ to position 300 of the \[Creditor header record by collection date]. * \\ to position 335 of the \[Creditor header record by collection date] according to the following conversion: if it contains true, 0 is written, and if it contains false, 1 is written. * Basic scheme only: \\\ to position 365 of the \[Optional Second Individual Record]. * Basic scheme only: \\\ or \\\\ to field 10 together with the first 6 positions of the free field that follows it in the \[Optional Fourth Individual Record]. * \\\ to two new optional individual records that are written after the last existing optional individual record. The first of them has data number “507” and includes the first 525 positions of the tag value, ending with 65 free positions. The second has data number “508” and includes the next 500 positions of the tag value, ending with 90 free positions. * \\ to position 81 of the \[Creditor total record by collection date]. It will be used to capture amounts of 18 digits in total (the flat-file standard allows up to 17). * \\ to position 99 of the \[Creditor total record by collection date]. It will be used to capture individual record counts whose value exceeds the 8 digits allowed by the flat-file format. * Rejections, originator information. 11 positions from the content of the first of the following tags found in the file are transferred: * \\\ \\\ or \\\\ or * \\\\\\ or * \\\\ or * \\\\\\\ or * \\\\\ to position 586 of each \[First individual record]. * Chargebacks, the content of: * \\ to position 81 of the \[Creditor total record by collection date]. It will be used to capture amounts of 18 digits in total (the flat-file standard allows up to 17). * \\ to position 99 of the \[Creditor total record by collection date]. It will be used to capture individual record counts whose value exceeds the 8 digits allowed by the flat-file format. * Submissions and chargebacks, the content of: * \\ to position 38 of the \[General total record]. It will be used to capture amounts of 18 digits in total (the flat-file standard allows up to 17). * \\ to position 56 of the \[General total record] if the amount exceeds the 8 digits allowed by the flat-file format. * Rejections and returns, the content of: * \\ to position 81 of the \[Creditor total record by collection/return date]. It will be used to capture amounts of 18 digits in total (the flat-file standard allows up to 17). * \\ to position 99 of the \[Creditor total record by collection/return date]. It will be used to capture individual record counts whose value exceeds the 8 digits allowed by the flat-file format. * \\ to position 38 of the \[General total record]. It will be used to capture amounts of 18 digits in total (the flat-file standard allows up to 17). * \\ to position 56 of the \[General total record]. It will be used to capture individual record counts whose value exceeds the 8 digits allowed by the flat-file format. ## Flat file to XML For its part, when the client generates the flat-file files, it may make use of certain free areas to store information there that would otherwise be impossible to transfer to the XML file resulting from the conversion. They are as follows: ### Issuance of transfers and cheques: The content of: * 70 positions, starting at position 290, from the Ordering Party Header to \\. This functionality is used to be able to transform several flat logical files with different ordering party names into a single XML. * 4 positions, starting at position 360, from the Ordering Party Header to as many \\ elements as need to be built in the resulting XML file. This mapping makes it possible to report and preserve this concept (which is not covered by either format) so that it can be returned in the bank statements sent by La Caixa (AEB 43). * 12 positions, starting at position 364, from the Ordering Party Header to \\\ or to \\\, as applicable. This functionality is used to be able to convert several flat logical files that do not match in the ordering party identifiers into a single XML file, this being the Presenter Id to be reported. * When the value H is found in position 23 of the \[SEPA Transfers Header Record], \\\ will be filled with the code HIGH in the resulting XML file. * 18 positions, starting at position 41 of the \[General total record], to \\. It will be used to capture amounts of 18 digits in total (the flat-file standard allows up to 17). * 15 positions, starting at position 59 of the \[General total record], to \\. It will be used to capture individual record counts whose value exceeds the 8 digits allowed by the flat-file format. * 18 positions, starting at position 41 of the \[SEPA transfer total record], \[Other transfer total record] or \[Cheque total record], as applicable by block type, to \\. It will be used to capture amounts of 18 digits in total (the flat-file standard allows up to 17). * 15 positions, starting at position 59 of the \[SEPA transfer total record], \[Other transfer total record] or \[Cheque total record], as applicable by block type, to \\. It will be used to capture individual record counts whose value exceeds the 8 digits allowed by the flat-file format. ### Direct debits (basic and B2B schemes): Submissions, the content of: * Basic scheme only: the content of field 10 together with the first six positions of the free field of the \[Optional Fourth Individual Record] to \>\\ if it is a BIC, or to \\\\ in any other case. * 18 positions, starting at 81, of the \[Creditor total record by collection date] to \\. It will be used to capture amounts of 18 digits in total (the flat-file standard allows up to 17). * 15 positions, starting at 99, of the \[Creditor total record by collection date] to \\. It will be used to capture individual record counts whose value exceeds the 8 digits allowed by the flat-file format. Rejections, the content of: * 11 positions, starting at position 167, of the \[Presenter header] record to \\\ \\\ if it is a BIC, or to \\\\ if it is not. * 4 positions, starting at position 178, of the \[Presenter header] record to \\\\ * 11 positions, starting at position 370, of the \[Creditor header record by collection date], to \\\\\\ if it is a BIC, otherwise to \\\\ * 4 positions, starting at position 381, of the \[Creditor header record by collection date], to \\\\ * 11 positions, starting at position 586, of the \[First individual record] to \\\\\\\ if it is a BIC, otherwise to \\\\\ Chargebacks, the content of: * 18 positions, starting at 81, of the \[Creditor total record by collection date] to \\. It will be used to capture amounts of 18 digits in total (the flat-file standard allows up to 17). * 15 positions, starting at 99, of the \[Creditor total record by collection date] to \\. It will be used to capture individual record counts whose value exceeds the 8 digits allowed by the flat-file format. Submissions and chargebacks, the content of: * 18 positions, starting at 38, of the \[General total record] to \\. It will be used to capture amounts of 18 digits in total (the flat-file standard allows up to 17). * 15 positions, starting at 56, of the \[General total record] to \\. It will be used to capture individual record counts whose value exceeds the 8 digits allowed by the flat-file format. Rejections and returns, the content of: * 35 positions, starting at position 335, of the \[Creditor header record by collection date] to \\. * 18 positions, starting at position 81, of the \[Creditor total record by collection/return date] to \\. It will be used to capture amounts of 18 digits in total (the flat-file standard allows up to 17). * 15 positions, starting at position 99, of the \[Creditor total record by collection/return date] to \\. It will be used to capture individual record counts whose value exceeds the 8 digits allowed by the flat-file format. * 18 positions, starting at position 38, of the \[General total record] to \\. It will be used to capture amounts of 18 digits in total (the flat-file standard allows up to 17). * 15 positions, starting at position 56, of the \[General total record] to \\. It will be used to capture individual record counts whose value exceeds the 8 digits allowed by the flat-file format. Returns, the content of: *An \[Optional Second Individual Record] is provided, which will start with 2319143004. This record does not exist in the standard, but it is necessary to store the information detailed below, which cannot be mapped to the \[mandatory first individual record] because it does not have enough space in the free field.* * 35 positions starting at position 11, from the \[Optional Second Individual Record] to the \\ tag * 35 positions starting at 46, from the \[Optional Second Individual Record], to the \\ tag * 105 positions, starting at 81, from the \[General total record] to \\< AddtlInf>. The converter will first look for this information in the free fields. If they are empty, the mapping will be performed as is usually done for each of those fields. ### Confirmation or rejection record for debits and transfers: § If the user indicates it, (type 3 record), when downloading the XML, a confirmation or rejection XML file is generated in certain cases, which can automatically be chained with an Editran procedure to generate the automatic response (Xml to Flat conversions of standards 3414 and 19 of type Submissions). * If it is possible to download the XML, an acceptance file is generated (even if there is a warning in the XML download) * If it is not possible to download the XML, a rejection file is generated. Example: PAIN002. Starting from the data in the flat or XML file record 01 and 99, an XML would be generated > (ACCP - RECEIPT AND CORRECT VALIDATION or RJCT - REJECTED) with certain data that came in the original XML: > > ```xml > > > > > B0081.S0901.F130314.P0120140311 > 2014-03-14T11:30:00 > > TELEFONICA DE ESPANA, S.A. > > > > B0081.S0901.F130314.P0120140311 > 0000023448 > 1246067.16 > ACCP > > > > ``` * The list of variables known to the application is as follows (Table 3):
VariableMeaning
%ODSN at source
%EDecade
%YLast digit of the year
%ALast two digits of the year (yy)
%MMonth in two digits (mm)
%XMonth in one character (1,2,3,4,5,6,7,8,9,O,N,D)
%DDay of the month (dd)
%HTime (hhmmss)
%COrder number of the received file (nn)
%KOrder number of the received file (nnnn)
%RThe last 7 characters of the remote endpoint code
%PApplication code
* If the parameter is specified with NIF, the confirmation file will carry the OrgnlMsgId tag with the NIF in the first positions. Example of content in ZTBGFDAT: ``` ***************************** Top of Data ******************************************** ----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+- 0- 111.022.033.444-00994-300-S-S- *0- pepito.es-00994-300- 1-%O.XML - - - -03000 2- - - - 3-S-%O.XML.CNF ***************************** Bottom of Data ***************************************** ``` In the previous case: * There is a type 0 record (java server connection data). The IP of the java server (z/OS USS) is 111.22.33.444, port 994. The TCP client waits a maximum of 5 minutes (300 seconds) for the server to resolve the process. * There is a type 0 record (commented), the same, but in this case, a DNS is used. * There is a type 1 record (data for the transformation from FLAT to XML). It tells us (by not specifying the output dsname) that, for example, if the flat file is called KI.PEPE, the XML file will be called KI.PEPE.XML. Also, it is in the system language, so no character table is specified. It also indicates that the application calculates the default output file size.There is a type 2 record (data for the transformation from XML to FLAT). By not indicating anything in the transformed file name, for example, if the XML is called KI.PEPE.XML, the output flat file will be called KI.PEPE (it removes .XML). If the XML is called KI.PEPE, the output flat file will be called KI.PEPE.PLN. * It also indicates that the XML be validated against the Schema since no value has been included in the Validate XML field and the default value is S. * In addition, it is in the system language, so no character table is indicated. It also indicates (by not putting anything) that if TIPO=FILE, \&TI=F, the application calculates the default output file size. * Use of the free area of the records, in the example it uses this functionality since 'S' is indicated in the Free information parameter. * Use of record size for the XML file generated by the converter, in this case it will be LRECL 3000. * Keep the output file if error, in the example, in case of error in the converter, the generated output file will not be deleted. * A confirmation file (acceptance or rejection) will be generated automatically. If a name is entered that follows the same mechanism as that of records 1 and 2. --- # 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/descripcion-de-la-funcionalidad/datos-de-entrada-salida-para-los-conversores.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.