> 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/connect-v2.1-en/firma/administracionconnectfirma/grupoficheros/alta/configuracion.md). # Configuration This first stage of configuring a *file group* collects its general parameters (where the files are, format, data that must be present in the files to which it applies, signing mode) and its specific parameters for sending. ![New file group](https://64653979-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvdpBggYaSLH9X3nOAiMG%2Fuploads%2Fgit-blob-b94b27723b5bd99ee515699821c835decc4b514e%2F02_configuracion_grupo_ficheros.png?alt=media) ## General data * **Name**: unique identifier of the *file group* in the system. It is composed automatically from the value of the parameters **Purpose**, **Application**, **Format**, **Tax ID**, **Suffix**, **Account** and minimum and maximum value of the type of **Amount** that are configured. It is not editable. * **Description**: friendly literal so the administrator can easily identify the *file group*. * **Application**: identifier to group the *file groups* that refer to the same set of files. It is the identifier that the signer sees and should help them recognize which set of files the file they are signing belongs to. * **Purpose**: purpose of the *file group* that is being configured. Its value is one of: * **`Sign`**: the files will receive signing treatment prior to sending * **`Verify`**: the files to be processed are signatures that are received and verified. * **Email**: email address to receive notifications related to documents that belong to this *file group*. * **Check the revocation status of certificates**: if checked, the revocation status of certificates will be checked before performing the signature. * **Input/output directory**: * If the purpose is to sign, this is the directory where the files to be signed are initially located. The files remain there until the system assigns them a *file group*. At that moment, they are moved to an internal Connect directory, where they are registered with a new name and the corresponding signature file is generated for each one. While the data and signature files remain in the internal directory, they are not accessible or identifiable by any process outside of Connect. * If the purpose is to verify, this is the output directory where the documents extracted from the signatures will be placed once they are verified. The input/output directory must exist and be accessible before the creation/modification of the *file group*, otherwise the *file group* cannot be created/modified. * **Save output files**: this parameter is only shown if the purpose is to sign. When checked, once the file type indicated in the parameter **Send**, the pair of data and signature files is copied from the internal Connect directory where they are located (and where they are not accessible from any process outside the product) to another directory where both files recover the original name and can be accessible by external processes. The output directory can be consulted by clicking the parameter information icon and is not editable. If this parameter is not enabled, at the end of the issuance process only the file or files transmitted to the other end (usually only one of the data and signature pair) will remain accessible in the channel's sending directory. * **Permanently delete working data and signature files**: this parameter is only shown if the purpose is to sign. When enabled, once the file type indicated in the parameter **Send**, the pair of data and signature files is deleted from the internal directory where it is located. In that case, the files will still be mentioned in the activity log, but they will no longer be viewable or accessible from the **Files**. * **File format**: type of file to be signed --purpose sign-- or of the signed file --purpose verify--. It can be one of: `Transfer`, `Direct debits`, `Single Confirming`, `AEB 63 (Garnishments)`- Phases 3 (Garnishment execution order) and 5 (Order to lift the retention), `Multiformat` and `Unformatted`. * The **Transfer** files are XML according to ISO 20022. * The **Direct debits** are XML files according to ISO 20022 and may correspond to the Presentation, Rejection, Return or Reversal messages. * The **Single Confirming** are flat files with fixed length of 250 and according to the regulated standard for these messages. * The **AEB 63** are flat files with fixed length 650 and according to the regulated standard for these messages. Phases 3 (Garnishment execution order) and 5 (Order to lift the retention) have been implemented. Selecting the formats Transfers, Direct Debits, AEB - 63 and Single Confirming for files of those formats allows the document view for the signer to be friendly. That is, files are not displayed as they are, but are shown organized in tables with rows and columns to facilitate checking their content. This view is not saved in any case and does not alter the original document or its format, which is what is signed. In addition, for the Transfers, Direct Debits and Single Confirming formats, it is possible to establish signing rules based on information contained in the files (Tax ID, suffix and accounts of the main entity - Ordering party or Creditor - and total file amount or highest transaction amount). * **Multiformat** is the parameter value appropriate when TXT, XML, Word, Excel and PDF files are going to be processed. In this case, the file view shows them as they are and it is not possible to establish signing rules based on information contained in the documents. Therefore, when this option is selected, the parameters **Tax ID**, **Suffix**, **Account** and **Amounts** are shown disabled. * **Unformatted** with this parameter value **Format** the document content is not displayed before signing it. This format does not allow establishing signing rules based on information contained in the documents. Therefore, when selected, the parameters **Tax ID**, **Suffix**, **Account** and **Amounts** are shown disabled. * **Tax ID**: shown available for the Transfers, Direct Debits and Single Confirming formats. It is the one that must be reported in the document to be signed, or in the document extracted from a signature that is verified, for the *file group* that is being configured to apply. It corresponds to the identification of the main entity of the files (Ordering party or Creditor). * **Suffix**: shown available for the Transfers, Direct Debits and Single Confirming formats. It is the one that must be reported in the document to be signed, or in the document extracted from a signature that is verified, for the *file group* that is being configured. It corresponds to the identification of the main entity of the files (Ordering party or Creditor). * **Account number**: shown available for the Transfers, Direct Debits and Single Confirming formats. It is the one that must be reported in the document to be signed, or in the document extracted from a signature that is verified, for the *file group* that is being configured to apply. It corresponds to the main entity of the files (Ordering party or Creditor). The system validates that the indicated account number is valid. * **Transfer type**: shown available for the Transfers format. It is the one that must be reported in the document to be signed, or in the document extracted from a signature that is verified, for the *file group* that is being configured to apply. * **Type of amount to validate with**: shown available for Transfers, Direct Debits and Single Confirming. One of the following must be selected `Total amount of the file`or `Largest transaction amount`. In both cases the minimum and maximum value will be specified. The amount of the file of the selected type (total or largest transaction) of the file to be signed must be within the range described in this parameter for the *file group* that is being configured to apply.\ When configuring this parameter: 1. Cents must be taken into account so that all values are covered. For example, if a *file group* is configured for documents with largest transaction amount between `0` and `1.000`, the *file group* for the next amount range should start at `1.000,01`; or the first should cover from `0` to `1.000,99` and the next start at `1.001`. 2. Overlapping of amount ranges should be avoided so that the system does not find ambiguity when assigning the *file groups* to the documents to be signed or verified. For example, if a *file group* is configured for documents with largest transaction amount between `0` and `1.000`is configured, there cannot be another file group for those same documents with largest transaction amount between `100` and `900` or between `500` and `1001`, etc. 3. A single amount validation strategy must be chosen (largest transaction amount or total amount) for the set of *file groups* that govern the same set of documents. * **Signing mode**: is the format in which the signature will be made and can be one of `PKCS#7 Attached` or `XAdES Detached Internal Implicit`. Includes help to check whether, with the chosen mode, the file with the signatures includes the data file being signed or not. * **XAdES Template/Policy**: when any of the *XAdES*signing modes has been selected, the following must be defined here: * If the *file group* has purpose sign, it is the template to use. Templates are XML documents, according to an Editran proprietary schema, that gather a set of configurable characteristics for the chosen signing mode, such as protection level (BES or EPES), SHA version to obtain the document hash, RSA SHA version with which it is signed, mandatory tags, etc. Different templates for each signing mode with commonly used configurations are distributed with the product. * If the *file group* has purpose verify and the required protection level for the signatures to be received is EPES, the policy to use is defined here. The policy file is another XML file, this time according to a proprietary schema of *XAdES*, which collects a series of required characteristics in the received signatures. The product includes the policy of the General State Administration (AGE). When the protection level to be used in exchanged signatures is EPES, in this field the signing end will place a template with EPES in the name, and the validating end will place the policy file. The use by the signing end of those templates with β€œEPES-AGE” in the name guarantees compliance with the AGE policy at the receiving and validating end of those signatures. Conversely, when the protection level to be used in exchanged signatures is BES, in this field the signing end will place a template with BES in the name and the validating end will leave the Policy field with the value None. ## Transmission data * **Send**: this parameter is only shown if the purpose is to sign. In this parameter it is configured which files, of the pair that exists in every signing process, will be sent to the other end. * You choose **`Data`** when the receiving end does not require receiving the signed information. * You choose **`Signatures`** when the receiving end requires receiving the signed information and the chosen signing mode is one in which the file with the signatures includes the data file. * You choose **`Data and Signatures`** when the receiving end requires receiving the signed information and the chosen signing mode is one in which the file with the signatures does not include the data file. Next to the parameter **Signing mode** there is an information icon that allows you to check which signing mode includes the data file in the same and which does not. * **Send automatically when the signature is completed**: this parameter is only shown if the purpose is to sign. When checked, Connect immediately sends the file once the required number of signatures is reached and all are correct. When not checked, the signed file remains available in the channel's sending mailbox, awaiting another process to trigger the sending (scheduler, manual sending, etc.). *channel*, awaiting another process to trigger the sending (scheduler, manual sending, etc.). * **Contact**: recipient of the files to be sent or sender of the signature files to be received. The combo offers those *contacts* in the system that have *channels* with signing capability in the direction of the corresponding transmission (sending, if the purpose is to sign, or receiving, if the purpose is to verify). * **Channel**: when the purpose is to sign, it is the *channel* of the *contact* through which the file will be transmitted once signed. When the purpose is to verify, it is the *channel* of the *contact* through which the signature documents to be verified are received. The combo offers those *channels* of the *contact* that have been configured with the signing feature in the transmission direction corresponding to the purpose (sending, if the purpose is to sign, or receiving, if the purpose is to verify). * **Format, Record Length, Delimiter, Compression, Alphabet and Translate**: only shown when the purpose is to sign. They are parameters for the transmission of the files by Connect itself. When what is transmitted are signature files or data files of Transfers or Direct Debits, .doc, .xls, .pdf or .xml, the value of Format must be Binary. πŸ“Œ **To keep in mind** * Since the name of the *file group* is an identifier that is composed automatically (not editable) from the values of the parameters **Purpose**, **Application**, **Format**, **Tax ID**, **Suffix**, **Account** and minimum and maximum value of **Amount** that are configured, and that such identifier must be unique in the system, there cannot be more than one *file group* with the same values in those parameters in the same installation. In this way, whenever the *file groups* are configured sufficiently, the system can unambiguously choose which is appropriate for each file found in the input directory. * When defining the *file groups* of the same set of files in which a range of amounts is specified, one of the two strategies must be chosen between largest transaction amount or total amount for all of them. This is because the name of the *file group* mentions the amount ranges that have been specified (if any) but not their type, whether largest transaction or total. Therefore, there cannot be two file groups with the same values of **Purpose**, **Application**, **Tax ID**, **Suffix**, **Account** in which the minimum and maximum amount values coincide, even if one refers to largest transaction amount and the other to total amount. * There cannot be *file groups* with the same values for **Purpose**, **Application**, **Format**, **Tax ID**, **Suffix**, **Account** and with amount ranges that, although different, produce overlap with other amount ranges already defined in the rest of the *file groups*. * When in *file groups* for banking file formats values are not set for any of **Tax ID**, **Suffix**, **Account** and **Amounts**, those file data are not taken into account when assigning the signing rule to the file. The signing rules, or *file groups*, will be more restrictive the more of those parameters are set and more generic the fewer of them are configured. * When the same file could be subject to more than one *file group*, the system will always choose the most restrictive one. * When the same file could be subject to more than one *file group* and these are equally restrictive (in both the same number of **Tax ID**, **Suffix**, **Transfer type**, **Account** and **Amounts**parameters have been specified), the system will report the ambiguity and the file will not be accepted. * Due to the initial processing performed on files in each case, there cannot be **file groups** with format `Multiformat` or `Unformatted` pointing to the same input directory that is already configured for *file groups* of banking formats (Transfer, Direct Debits and Confirming). However, *file groups* for different banking formats may share the same input directory. * When the purpose is to verify, all the *file groups* that are received through the same *channel* must match in the signing mode. This is because in the case of verifying a signature file, the operations are carried out in the reverse order to signing: first the signature is verified and the signed document is extracted (both tasks absolutely tied to the signing mode) and then, when the verification succeeds and the signed document is extracted from the signature file, its main data are obtained to, according to them, assign the *file group* with purpose verify that corresponds to it. ## πŸ“ Examples In the following examples, all the *file groups* mentioned share the same input directory): **Example 1** > *File group one* for format *A* with value *tax ID* in Tax ID\ > \&#xNAN;*File group two* for format *A* with value for largest transaction amount between *X* and *Y*. If a file of format *A*arrives in the input directory, with Tax ID *tax ID* in the main entity and a largest transaction amount between *X* and *Y*, the system finds ambiguity when assigning a *file group* to the file since it could apply either `File group one` or `File group two`. In this case, the system does not accept the file and reports it. **Example 2** > *File group one* for format *A* with Tax ID *tax ID* and largest transaction amount between *X* and *Y*.\ > \&#xNAN;*File group two* for format *A* with Tax ID *tax ID*.\ > \&#xNAN;*File group three* for format *A* without values for Tax ID, suffix, account and amount. If a file of format *A* with Tax ID *tax ID* in the main entity and a largest transaction amount between *X* and *Y*, although *File group two* and *File group three*have also been defined in the system, which in terms of values would be possible candidates for that file, there is no ambiguity when assigning the *file group* to the file since *File group one* is more restrictive than the other two (it is the one with a greater number of defined parameters). If a file of format *A* with Tax ID *tax ID* in the main entity and a largest transaction amount that is not within *X* and *Y*, will be assigned *File group two* because it is more restrictive than *File group three*, which is the only other candidate in this case. If a file of format *A* but with Tax ID different from *tax ID*, will be assigned *File group three* because it is the only possible candidate in this case. If a file of format *B*, since there is no *file group* defined for that format, the system does not accept the file and reports it. πŸ“Œ **In summary, the system always chooses the *****file group***** most restrictive among all those that could apply to the file. When among all those that could apply to the file there is ambiguity because none of them is more restrictive than the others, the file is not accepted and is reported. Finally, when there is no candidate file group for the file, it will also not be received by Connect and will be reported.** Once the general and transmission parameters of the *file group*are configured, you must go to the next screen to register the *signer groups* and to define the total number of signatures required for each file. --- # 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/connect-v2.1-en/firma/administracionconnectfirma/grupoficheros/alta/configuracion.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.