> 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-v3.1-en/firma/administracionconnectfirma/grupoficheros/alta/configuracion.md). # Configuration This first stage of configuring a *file group* contains its general parameters (where the files are located, format, data that must be provided in the files it applies to, signing mode) and its specific parameters for sending. ![New file group](https://1190478111-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FzO0mk2eo5LONjICfqrP8%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 automatically composed from the values of the parameters **Purpose**, **Application**, **Format**, **NIF**, **Suffix**, **Account** and minimum and maximum value of the type of **Amount** that are configured. It is not editable. * **Description**: user-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* being configured. Its value is one of: * **`Sign`**: the files will be processed for signing before being sent * **`Verify`**: the files to be processed are signatures that are received and verified. * **Email**: email address to receive notifications regarding documents that belong to this *file group*. * **Check certificate revocation status**: if checked, the certificate revocation status 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 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 signing. When checked, 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 they are located (and where it is not accessible from any process outside the product) to another directory where both files recover the original name and can be accessed by external processes. The output directory can be consulted by clicking the parameter info icon and is not editable. If this parameter is not enabled, at the end of the sending process only the file or files transmitted to the other end (usually only one of the data/signature pair) will remain accessible in the channel's sending directory. * **Permanently delete data and signature work 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 listed 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 signed file --verification purpose--. It can be one of: `Transfer`, `Direct debits`, `Single Confirming`, `AEB 63 (Attachments)`- Phases 3 (Seizure execution order) and 5 (Order to lift the hold), `Multiformat` and `No format`. * Files of **Transfers** are XML according to ISO 20022. * Files of **Direct debits** are XML files according to ISO 20022 and may correspond to Presentation, Rejection, Return, or Reversal messages. * Files of **Single Confirming** are fixed-length flat-format files of 250 and according to the standard regulated for these messages. * Files of **AEB 63** are fixed-length flat-format files of 650 and according to the standard regulated for these messages. Phases 3 (Seizure 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 they are, but are shown organized in tables with rows and columns to make it easier to check their contents. 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 (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 display 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** and **Amounts** are shown disabled. * **No format** with this parameter value **Format** the document content 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** and **Amounts** are shown disabled. * **NIF**: 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. It corresponds to the identification of the main party in the files (Ordering Party or Creditor). * **Suffix**: 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. It corresponds to the identification of the main party in the files (Ordering Party or Creditor). * **Account number**: 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. 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**: 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. * **Amount type to validate against**: 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 amount of the file of the selected type (total or largest transaction amount) of the file to be signed must fall within the range described in this parameter for the *file group* being configured.\ When this parameter is configured: 1. Cents must be taken into account so that all values are covered. For example, if you configure 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 of the amount ranges should be avoided so that the system does not encounter ambiguity when assigning the *file groups* to the documents to be signed or verified. For example, if you configure 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. * **Signing mode**: is the format in which signing will be performed and may be one of `PKCS#7 Attached` or `XAdES Detached Internal Implicit`. Includes help to check whether, with the selected mode, the file with the signatures includes the data file being signed or not. * **XAdES Template/Policy**: when any of the signing modes has been selected *XAdES*, the following must be defined here: * If the *file group* has the signing purpose, it is the template to use. Templates are XML documents, according to Editran's proprietary schema, that gather a set of characteristics 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 the verification purpose and the protection level required 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 sets out a series of characteristics required in the received signatures. The product includes the policy of the General State Administration (AGE). 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 with β€œEPES-AGE” in the name on the signing end ensures compliance with the AGE policy on 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. * Choose **`Data`** when the receiving end does not need to receive the signed information. * Choose **`Signatures`** when the receiving end needs to receive the signed information and the selected signing mode is one in which the file with the signatures includes the data file. * Choose **`Data and Signatures`** when the receiving end needs to receive the signed information and the selected 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 and which does not. * **Automatically send when signing is complete**: this parameter is only shown if the purpose is signing. When checked, Connect immediately sends the file once the required number of signatures is reached and they are all correct. When not checked, the already signed file remains available in the sending inbox 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 direction corresponding to the transmission (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 will be 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 feature in the direction of transmission corresponding to the purpose (sending, if the purpose is signing, or receiving, if the purpose is verification). * **Format, Record Length, Delimiter, Compression, Alphabet, and Translate**: are shown only when the purpose is signing. They are parameters for the transmission of the files through Connect itself. When what is transmitted are signature files or data files for Transfers or Direct debits, .doc, .xls, .pdf or .xml, the Format value must be Binary. πŸ“Œ **Things to keep in mind** * Since the name of the *file group* is an identifier that is automatically composed (not editable) from the values of the parameters **Purpose**, **Application**, **Format**, **NIF**, **Suffix**, **Account** and 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 the same installation. 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, largest transaction amount or total amount, must be chosen 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 amount 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 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**, **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, values are not set for any of **NIF**, **Suffix**, **Account** and **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** and **Amounts**) parameters has been specified in both), the system will report the ambiguity and the file will not be received. * Due to the initial processing applied to files in each case, there cannot be **file groups** with format `Multiformat` or `No format` pointing to the same input directory 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 *file groups* received through the same *channel* must match in signing mode. This is because when verifying a signature file, the operations are performed 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, according to it, the *file group* verification purpose 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 *NIF* in NIF\ > *File group two* for format *A* with a value for largest transaction amount between *X* and *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* and *Y*, the system encounters 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* and *Y*.\ > *File group two* for format *A* with NIF *NIF*.\ > *File group three* for format *A* without values for NIF, suffix, account and 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* and *Y*, although the system has also 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 included between *X* and *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 short, 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 message is issued. Finally, when there is no candidate file group for the file, Connect will also not receive it and will report it.** Once the general and transmission parameters of the *file group*, 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-v3.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.