Guide "Electronic Document Incoming EDO Attached Files" - Technical Description

1. Identification

Purpose. The catalog stores metadata and content of files attached to "Electronic Document Incoming EDOC" (Kazakhstan) documents. It is essentially a file storage for incoming electronic document flow: it contains files received from the counterparty via the "1C:EDO" service — the XML of the document (ESF, SNT, etc.), its visualization (PDF/print form), attached images and scans, as well as service files (containers of electronic signatures .p7s, etc.).

The catalog is auxiliary: the user rarely opens it directly, but works with files through the incoming EDOC document form and general file handling mechanisms of the BSP. Each file is linked to a specific incoming electronic document through the attribute FileOwner, which ensures grouping of files by document, auditing, and access control.

Where to find: e1cib/list/Catalog.ElectronicDocumentIncomingEDOCAttachedFiles

2. Attributes of Headers and Table Parts

2.1 Header Attributes

Additionally, the object has standard storage attributes of the BSP: Volume (CatalogLink.FileStorageVolumes), FileStorage/TextStorage (ValueStorage — content when stored in the IB), UploadedFromInternet, indicators of signing/encryption. The exact composition of these fields is version-specific.

2.2 Table Parts

The catalog does not have table parts. This is typical for "Attached Files" objects: one catalog item = one file. File versions, if supported, are stored in a separate subordinate version catalog, not in a table part.

3. Forms

In practice, instead of their own element/list forms, general file handling forms of the BSP (AttachedFiles, AttachedFile) are usually used, which manage capture for editing, versions, signing, and encryption uniformly for all storage catalogs. The presence/absence of their own forms is version-specific.

4. Key Procedures of Modules

BSL snippets in evidence are not attached, so below are typical handlers for the attached files storage catalog (BSP). Specific lines should be viewed in the configurator.

Object Module:

• OnWrite — records the modification date, updates the ModifiedBy attribute, recalculates Size/HashSum, checks editing lock (EditingUser).
• CheckFillingProcessing — controls mandatory fields Author and CreationDate.
• BeforeDelete — clears content in the volume (deletes the file from disk by Volume + FilePath).

Manager Module:

• GetViewProcessing — generates the file view (name + extension).
• Integration procedures with the general module FileHandling/AttachedFiles of the BSP: adding a file, obtaining/capturing for editing, releasing, adding a version, working with electronic signatures (signing, verification, encryption/decryption).

General mechanisms involving the catalog:

• AttachedFiles.AddFile(...) — creates an item when receiving a document from "1C:EDO".
• Storage mechanism in volumes (FileStorageVolumes) or in the IB (FileStorage), chosen by file storage settings.

5. Posting and Movements

The catalog is not posted and does not generate movements in registers — the posting mechanism exists only for documents. This object does not create any accounting entries; it merely stores files.

Accounting movements arise from related documents of the EDOC subsystem when the incoming electronic document is reflected in the accounting (typical logic of the RK, VAT rate 16%):

• Receipt of Goods (created based on incoming EDOC/ESF):
  • Dr 1330 "Goods" — Cr 3310 "Short-term Payables to Suppliers" — for the cost excluding VAT;
  • VAT to be credited 16% — to a separate account for incoming VAT accounting according to the configuration's chart of accounts, in correspondence with 3310.
• Sale (outgoing flow, for comparison): Dr 1210 — Cr 6010; VAT accrual 16% — Cr 3130 "VAT Payable"; cost Dr 7010 — Cr 1330.
• Payment through the bank: Dr 3310 — Cr 1030 "Cash in Current Accounts".

The catalog being examined does not participate in these entries — it provides files attached to documents (XML ESF/SNT, PDF visualization, signature containers).

6. Related Objects and Input Based On

File Owners:

• Document.ElectronicDocumentIncomingEDOC — through the attribute FileOwner; files are added/opened from the form of this document.

Adjacent Objects of the EDOC Subsystem:

• Documents of electronic documents "1C:EDO" (ESF from the ESF IS, SNT), accounting documents created based on incoming EDOC (receipt of goods and services).
• BSP catalogs: Users (attributes Author, ModifiedBy, EditingUser), FileStorageVolumes (attribute Volume).

Input Based On. As a file storage, the catalog is usually neither a source nor a receiver of input based on. Items are created programmatically when receiving a document from the EDOC service or manually through the form of attached files of the owner document.

7. Extension Points

• Configuration Extensions. Adding attributes (for example, additional classification of files) and subscribing to write events for custom integrity/audit control logic.
• Subscriptions to events BeforeWrite/OnWrite of the catalog — for logging, additional checking of HashSum, integration with an external archive.
• Overridable BSP modules for working with files and EDOC — to change storage rules (volumes/IB), version policies, signature processing.
• Roles and RLS — restricting access to files by FileOwner/Author through rights to the catalog and to the owner document.
• Additional processing/commands — opening, bulk export, checking file signatures from lists.

Version-specific (check in 3.0.74.2): the exact composition of storage attributes (Volume, FileStorage), presence of own element/list forms and connected general BSP forms.