> 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-3.2-en/firma/administracionconnectfirma/grupoficheros/alta/configuracion.md). # Configuration This first stage of the configuration of a *file group* gathers its general parameters (where the files are, format, data that must be provided in the files to which it applies, signature mode) and its specific parameters for sending. ![New file group](https://1386330368-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2jqgE5yyM3S58JKHROiz%2Fuploads%2Fgit-blob-b94b27723b5bd99ee515699821c835decc4b514e%2F02_configuracion_grupo_ficheros.png?alt=media) ## General data * **First name**: unique identifier of the *file group* in the system. It is automatically generated from the value of the parameters **Purpose**, **Application**, **Format**, **NIF**, **Suffix**, **Account** and the minimum and maximum value of the type of **Amount** that are configured. It is not editable. * **Description**: friendly label 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 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 signature processing before sending * **`Verify`**: the files to be processed are signatures that are received and verified. * **Email**: email address to receive notifications regarding documents belonging to this *file group*. * **Check the revocation status of the certificates**: if selected, the revocation status of the certificates will be checked before signing. * **Input/output directory**: * If the purpose is signing, 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 point, they are moved to an internal Connect directory, where they are recorded 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 Connect. * If the purpose is verification, this is the output directory where the documents extracted from the signatures will be left once they have been 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 signing. When selected, once the type of file indicated in the parameter **Send**, the pair of data and signature files is copied from the internal Connect directory where it is located (and where it is not accessible from any process outside the product) to another directory where both files regain the original name and can be accessed by external processes. The output directory can be viewed by clicking the parameter info icon and is not editable. If this parameter is not enabled, when the sending process finishes only the file or files transmitted to the other end will remain accessible, in the channel's sending mailbox (generally, only one of the data/signature pair). * **Permanently delete data and signature working files**: this parameter is only shown if the purpose is signing. When enabled, once the type of file 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 can no longer be consulted or viewed from the menu **Files**. * **File format**: type of file to sign --signing purpose-- or of the signed file --verification purpose--. It can be one of: `Transfer`, `Direct Debits`, `Single Confirming`, `AEB 63 (Attachments)`- Phases 3 (Attachment execution order) and 5 (Order to lift the hold), `Multiformat` and `Without format`. * The files for **Transfers** are XML according to ISO 20022. * The files for **Direct Debits** are XML files according to ISO 20022 and may correspond to the Submission, Rejection, Return, or Reversal messages. * The files for **Single Confirming** are fixed-length flat files of 250 and according to the standard regulated for these messages. * The files for **AEB 63** are fixed-length flat files of 650 and according to the standard regulated for these messages. Phases 3 (Attachment execution order) and 5 (Order to lift the hold) have been implemented. The selection of the Transfers, Direct Debits, AEB-63 and Single Confirming formats for files of those formats allows the signer to view the document in a user-friendly way. That is, the files are not displayed as-is, but are shown organized in tables with rows and columns to make it easier to check their content. This view is never saved 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 set signing rules according to information contained in the files (tax ID/NIF, suffix and accounts of the main party - Ordering Party or Creditor - and total file amount or largest transaction amount). * **Multiformat** is the appropriate parameter value when TXT, XML, Word, Excel, and PDF files are to be processed. In this case, the file view shows them as they are and it is not possible to set signing rules based on information contained in the documents. Therefore, when this option is selected, the parameters **NIF**, **Suffix**, **Account** e **Amounts** are shown disabled . * **Without format** with this parameter value **Format** the content of the document is not displayed before signing. This format does not allow signing rules to be set based on information contained in the documents. Therefore, when selected, the parameters **NIF**, **Suffix**, **Account** e **Amounts** are shown disabled. * **NIF**: it is available for the Transfers, Direct Debits, and Single Confirming formats. It is the one that must be provided in the document to be signed, or in the document extracted from a signature being verified, for the *file group* being configured to apply. It corresponds to the identification of the main party in the files (Ordering Party or Creditor). * **Suffix**: it is available for the Transfers, Direct Debits, and Single Confirming formats. It is the one that must be provided in the document to be signed, or in the document extracted from a signature being verified, for the *file group* being configured to apply. It corresponds to the identification of the main party in the files (Ordering Party or Creditor). * **Account number**: it is available for the Transfers, Direct Debits, and Single Confirming formats. It is the one that must be provided in the document to be signed, or in the document extracted from a signature being verified, for the *file group* being configured to apply. It corresponds to the main party in the files (Ordering Party or Creditor). The system validates that the indicated account number is valid. * **Transfer type**: it is available for the Transfers format. It is the one that must be provided in the document to be signed, or in the document extracted from a signature being verified, for the *file group* being configured applies. * **Amount type to validate with**: it is available for Transfers, Direct Debits, and Single Confirming. One of the following must be selected: `Total file amount`or `Largest transaction amount`. In both cases, the lower value and the upper value will be specified. The file amount of the selected type (total or largest transaction) of the file to be signed must fall within the range described in this parameter for the *file group* being configured to apply.\ When this parameter is configured: 1. Cents must be taken into account so that all values are covered. For example, if a *file group* 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 else the first should cover from `0` to `1.000,99` and the next start at `1.001`. 2. Overlap between amount ranges must be avoided so that the system does not encounter ambiguity when assigning the *file groups* to the documents that are going to be signed or verified. For example, if a *file group* for documents with largest transaction amount between `0` and `1.000`, 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 (largest transaction amount or total amount) must be chosen for the set of *file groups* that govern the same set of documents. * If the *file group* has signing purpose, it is the template to use. Templates are XML documents, according to Editran's proprietary schema, which bring together a set of features configurable for the chosen signing mode, such as protection level (BES or EPES), SHA version to obtain the document hash, SHA version of the RSA algorithm with which it is signed, mandatory tags, etc. The product includes different templates for each signing mode with the most commonly used configurations. * If the *file group* has verification purpose 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 includes a series of features required in the received signatures. The product includes the General State Administration (AGE) policy. When the protection level to be used in the 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. Using templates named β€œEPES-AGE” at the signing end guarantees compliance with the AGE policy at the receiving and validating end of those signatures. Conversely, when the protection level to be used in the 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 signing. This parameter configures which files, from the pair that exists in every signing process, will be sent to the other end. * The following is chosen **`Data`** when the receiving end does not need to receive the signed information. * The following is chosen **`Signatures`** when the receiving end needs to receive the signed information and the chosen signing mode is one in which the file with the signatures includes the data file. * The following is chosen **`Data and Signatures`** when the receiving end needs to receive 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 lets you check which signing mode includes the data file in it and which does not. * **Automatically send upon completing the signature**: this parameter is only shown if the purpose is signing. When selected, Connect immediately sends the file once the required number of signatures is reached and all are correct. When not selected, the already signed file remains available in the sending mailbox of the *channel*, waiting for 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 drop-down offers those *contacts* in the system that have *channels* signing in the corresponding transmission direction (sending, if the purpose is signing, or receiving, if the purpose is verification). * **Channel**: when the purpose is signing, it is the *channel* of the *contact* through which the file is transmitted once signed. When the purpose is verification, it is the *channel* of the *contact* through which the signature documents to be verified are received. The drop-down offers those *channels* of the *contact* that have been configured with the signing characteristic in the corresponding transmission direction (sending, if the purpose is signing, or receiving, if the purpose is verification). * **Format, Record Length, Delimiter, Compression, Alphabet and Translate**: these are only shown when the purpose is signing. They are parameters for the transmission of files through Connect itself. When what is being transmitted are signature files or data files for Transfers or Direct Debits, .doc, .xls, .pdf or .xml, the Format value must be Binary. πŸ“Œ **To keep in mind** * Since the name of the *file group* is an identifier that is automatically generated (not editable) from the values of the parameters **Purpose**, **Application**, **Format**, **NIF**, **Suffix**, **Account** and the minimum and maximum value of **Amount** that are configured, and since that identifier must be unique in the system, there cannot be more than one *file group* with the same values in those parameters. In this way, whenever the *file groups* necessary ones have been configured, the system will be able to unambiguously choose which one is appropriate for each file found in the input directory. * When defining the *file groups* for the same set of files in which an amount range 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**, **NIF**, **Suffix**, **Account** in which the minimum and maximum amount values match, no matter that 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**, **NIF**, **Suffix**, **Account** and with amount ranges that, even if different, overlap with other amount ranges already defined in the rest of the *file groups*. * When in *file groups* for bank file formats no values are set for any of **NIF**, **Suffix**, **Account** e **Amounts**, that file data is not taken into account when assigning the signing rule to the file. 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 more than one *file group*can apply to the same file, the system will always choose the most restrictive one. * When more than one *file group* and these are equally restrictive (the same number of **NIF**, **Suffix**, **Transfer type**, **Account** e **Amounts**parameters have been defined), the system will report the ambiguity and the file will not be received. * Due to the initial processing performed on the files in each case, there cannot be **file groups** with format `Multiformat` or `Without format` pointing to the same input directory that is already configured for *file groups* bank formats (Transfers, Direct Debits, and Confirming). However, *file groups* different bank formats may share the same input directory. * When the purpose is verification, all the *file groups* received through the same *channel* must match in signing mode. This is because in the case of verifying a signature file, the operations are carried out in reverse order to signing: first the signature is verified and the signed document is extracted (both tasks are absolutely tied to the signing mode) and then, when verification succeeds and the signed document is extracted from the signature file, its main data is obtained so that, based on it, the *file group* verification-purpose one corresponding to it is assigned. ## πŸ“ Examples In the following examples, all the *file groups* mentioned ones share the same input directory): **Example 1** > *File group one* for format *A* with value *NIF* in NIF\ > \&#xNAN;*File group two* for format *A* with value for largest transaction amount between *X* e *Y*. If a file in format arrives in the input directory *A*, with NIF *NIF* in the main party and a largest transaction amount between *X* e *Y*, the system finds ambiguity when assigning a *file group* to the file since it could apply both `File group one` as `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 NIF *NIF* and largest transaction amount between *X* e *Y*.\ > \&#xNAN;*File group two* for format *A* with NIF *NIF*.\ > \&#xNAN;*File group three* for format *A* with no values for NIF, suffix, account, or amount. If a file in format arrives in the input directory *A* with NIF *NIF* in the main party and a largest transaction amount between *X* e *Y*, although in the system there have also been defined *File group two* and *File group three*, 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 the greatest number of parameters defined). If a file in format arrives in the input directory *A* with NIF *NIF* in the main party and a largest transaction amount that is not within *X* e *Y*, it 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 in format arrives in the input directory *A* but with NIF different from *NIF*, it will be assigned *File group three* because it is the only possible candidate in this case. If a file in format arrives in the input directory *B*, since there is no *file group* defined for that format, the system does not receive 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 there is ambiguity among all those that could apply to the file because none of them is more restrictive than the others, the file is not received and a report is issued. Finally, when there is no candidate file group for the file, it will also not be received by Connect and a report will be issued.** Once the general and transmission parameters of the *file group*, the next screen must be opened to create 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-3.2-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.