Guide "LetterExchangeWithBanksAttachedFiles" — Technical Description

1. Identification

Purpose. The catalog stores files attached to "Letter exchange with banks" documents within the framework of electronic document management with banks. This is one of the standard file attachment storage objects of the FHS: for each owner object (here — the document "Letter exchange with banks"), a separate catalog of attached files is created in the configuration. The mechanism supports versioning, electronic signature (E-Signature), encryption, and storage of content both in the information base and on external storage volumes.

Practically, the object is used when statements, payment orders, bank receipts, scans, and XML files from the client-bank are attached to the letter exchange with the bank. The user interacts with it not directly as a list of the catalog, but through the owner document form ("Attached files").

Where to find in 1C: section "Electronic Interaction" → "Attached files (Letters with banks)". Navigation link: e1cib/list/Catalog.LetterExchangeWithBanksAttachedFiles

File attachment storages are considered service objects: they are usually not displayed in the command interface as a standalone list, but are called from the owner document form.

2. Attributes and Table Parts

2.1 Header Attributes

Name (standard attribute). Stores the file name without the extension — the user identifies the file in the list by it.

Additionally, the standard file attachment storage in FHS includes attributes FileStorageType (in IB / in volume), Volume (CatalogReference.FileStorageVolumes) and CurrentVersion (if versioning is enabled for the object). Their presence in a specific build is version-specific; they are not listed in the provided evidence.

2.2 File Content Storage

The binary data of the file is stored separately, not in the catalog attribute:

• when the storage type is "in the information base" — in the information register of the file attachment storage (binary data are linked to the element reference);
• when the storage type is "in the volume" — on the disk at the path from the FilePath attribute, the volume is determined by the FileStorageVolumes catalog.

2.3 Table Parts

The object does not have its own application table parts. File versions, electronic signatures, and encryption certificates are stored in auxiliary objects of the file handling subsystem (information registers of versions, signatures, and certificates), not in the table parts of the catalog itself.

3. Forms

In practice, the end user interacts with the common forms of the file handling subsystem (for example, "AttachedFiles", "FileView", "FileEditingAttributes") — they receive this catalog as storage and provide upload, download, viewing, signing, and versioning.

4. Key Module Procedures

Evidence with the source code BSL for this object is not attached — below are standard handlers for the file attachment storage of FHS (description based on standard logic; signatures and presence depend on the version of FHS in build 3.0.74.2).

Catalog manager module:

• DataSelectionProcessing — filtering files during interactive selection.
• Service functions for obtaining the owner and storage parameters, used by common modules for file handling.

Object module:

• BeforeWriting — recording the author/modified by, creation date, and universal modification date, recalculating ImageIndex based on extension and state (signed/encrypted/occupied).
• BeforeDeletion — clearing related content (binary data in IB or file in the volume) and dependent records of versions/signatures.
• CheckFilling — control of mandatory attributes Author and CreationDate.

Common modules of the subsystem (work with this catalog as a storage):

• FileHandlingService / FileHandling — adding a file, creating versions, occupying/releasing for editing, saving to disk.
• ElectronicSignatureService — setting/checking E-Signature (attribute SignedES).
• EncryptionService — encrypting/decrypting content (attribute Encrypted).

Exact paths and line numbers are version-specific; they are checked according to the composition of common modules of the specific build.

5. Posting and Movements

The catalog is not posted and does not generate accounting entries and movements in accumulation registers. As a file storage object, it does not participate in reflecting economic operations.

Data changes lead to entries in auxiliary information registers of the file handling subsystem:

• register for storing binary data of the file (when stored in IB);
• register of versions of the file (when versioning is enabled);
• registers of electronic signatures and encryption certificates of the file.

Accounting consequences arise not from the file, but from the owner document LetterExchangeWithBanks and related banking documents. For reference — movements are generated by these documents, not the attached file; standard accounts of the Chart of Accounts of the RK involved in the banking block:

(For reference, in the context of RK-2026; the file attachment catalog does not make these entries.)

6. Related Objects and Input on Basis

• Owner Document: Document.LetterExchangeWithBanks — the only owner, specified in the FileOwner attribute.
• Author Users: catalogs Users, ExternalUsers, FileSynchronizationAccounts (attributes Author, ModifiedBy, EditingUser).
• Storage Volumes: Catalog.FileStorageVolumes — when storing files outside IB.
• Subsystems: "File Handling", "Electronic Signature", "Encryption", "File Synchronization".
• Electronic Document Management of the RK: files may contain attachments of EDM — electronic invoices (ESF) (IS ESF), payment orders, as well as client-bank formats (XML statements, payment orders).

Input on Basis: not provided — attached files are created only through the mechanism of adding a file to the owner document (drag and drop, "Add → File from disk / from scanner"), not through input on basis commands.

7. Extension Points

• Configuration Extension: adding custom attributes (for example, type of EDM attachment, bank verification status) through catalog extension; overriding element/list forms.
• Object Handlers: BeforeWriting, BeforeDeletion, CheckFilling — for additional validation (control of extensions, size limitation, mandatory signature for outgoing to the bank).
• Common FHS modules with the suffix Overridable (FileHandlingOverridable and similar) — standard points for implementing file handling logic without modifying standard code.
• Event Subscriptions by catalog reference — for integration with external storage/antivirus checking systems.
• Access Restriction (RLS): through the FileOwner attribute (letter document) and Author — setting file visibility based on rights to the owner document.

Recommendation: extend behavior through overridable modules of the file handling subsystem, rather than modifying the standard catalog — this preserves compatibility during configuration updates.