Directory "IndividualsAttachedFiles" — Technical Description (BK 3.0.74.2)

1. Identification

Purpose. The catalog is intended for storing files attached to the cards of individuals: scanned copies of documents (identity card, IIN, employment contract, applications), photographs, resumes, and other electronic documents related to employees and candidates. It is used by HR specialists, payroll accountants, and managers in maintaining personal files. Access to files is inherited from the rights to the individual’s card: no rights to view the employee — their files are not visible.

This is a service (subordinate) catalog of the standard subsystem library. It is not intended for manual input from the list — records are created by the file attachment mechanism on the element form Catalog.PhysicalPersons. Storage is possible both in the information base and on the volumes of the file storage; versioning, electronic signature, and encryption are supported.

Each metadata object of BK/ZUP RK that supports attached files has its own subordinate catalog of the form <Owner>AttachedFiles — this catalog serves PhysicalPersons.

2. Attributes and Table Parts

2.1 Header Attributes

Additionally, the attached files catalogs of BSP contain standard service attributes (the composition may vary depending on the storage mode):

2.2 Table Parts

Table parts are absent. Like most attached files catalogs of BSP, the object stores one file in one record; versions and signatures are placed in separate subordinate catalogs (…FileVersions) and information registers of the cryptography subsystem.

3. Forms

In practice, the user works with files not through their own catalog forms, but through the embedded field “Attached Files” / hyperlink “Files” on the element form Catalog.PhysicalPersons, which uses the common forms of the subsystem FileManagement (for example, CommonForm.AttachedFilesForm).

4. Key Procedures of Modules

Application BSL code in the module of the catalog itself is usually absent — all logic is transferred to the common BSP modules. Typical handlers and called mechanisms:

• ManagerModule / ObjectModule — standard handlers ProcessFilling, BeforeWriting, BeforeSettingNewObjectCode. When recording, UniversalModificationDate and ModifiedBy are updated.
• FileManagementService (common module) — central logic: AddFile, UpdateFileVersion, GetFileVersion, transfer between storage in IB and on the volume.
• FileManagementServerCall / FileManagementClient — client-server interaction: opening, saving, locking for editing (EditRestriction, EditingUser).
• FileManagementInternetServer — mechanism for attaching a file to the owner and creating a catalog record through FileManager.
• Cryptography Subsystem (ElectronicSignatureAndEncryption…) — setting/removing EP and encryption, updating attributes SignedEP, Encrypted.
• Versioning — when the setting is enabled, each change in content generates a record in the subordinate versions catalog, and CurrentVersion switches to the current one.

Requires verification: the exact composition and presence of the object module for the catalog is version-specific — in the specific release 3.0.74.2, the logic may be entirely in the common BSP modules without its own object code.

5. Posting and Movements

The catalog is not a document and does not generate movements in registers and accounting entries. Accordingly, the chart of accounts of the RK (1210, 1030, 1330, 3310, 3130, 6010, 7010) and tax calculations (VAT 16%, PIT 10%/15%, OPV 10%, OPVR 3.5%, VOSMS 2%, OSMS 3%, SO 5%, social tax 6%; MRP 4,325 ₸, MZP 85,000 ₸, deduction 30 MRP/month) do not directly relate to it — these mechanisms are implemented by payroll and sales documents, not by the file storage.

What actually happens when working with the catalog:

• Recording in IB or on the volume. When stored in the database, binary data is written to FileStorage; when stored on the volume, the file is transferred to StorageVolume, and the record retains FilePath.
• Information registers of the file subsystem are updated service-wise: occupancy for editing, version compliance, EP/encryption indicators (information registers of the FileManagement and cryptography subsystems).
• Storage volume accounting — the attribute Size is aggregated by BSP reports on the occupied volume of the volumes.

Practical context of the RK: here, for example, a scan of the employee's identity card and IIN, employment contract, application for the standard tax deduction on PIT (30 MRP = 129,750 ₸ per month at MRP 4,325 ₸), certificates for calculating OPV/VOSMS are attached. The files themselves are supporting documents; they do not affect accounting and tax records but serve as a basis for settings in the individual’s card.

6. Related Objects and Input Based On

• Owner: Catalog.PhysicalPersons — the only source for creating records.
• Subordinate Objects: file version catalog (…FileVersions) when versioning is enabled.
• Users: Catalog.Users — attributes Author, ModifiedBy, EditingUser.
• Storage Volumes: Catalog.FileStorageVolumes.
• Cryptography: information registers of the EP and encryption subsystem (certificates, signatures).
• Input Based On: not provided. The file is added by the “Add” command in the owner’s attached files field (from disk, scanner, or template).

7. Extension Points

• Configuration Extensions: you can add your own attributes to the catalog (for example, “DocumentType”, “ValidityPeriod”) and display them on the common attached files form through borrowing the form.
• Programmatic Attachment: API FileManagement / FileManager — automatic loading of files from external systems/scans (e.g., bulk loading of scans of identity cards during hiring).
• Subscriptions to events BeforeWriting/OnWriting of the catalog — control of extension, maximum size, mandatory description.
• Categorization and Additional Information through the properties subsystem of BSP (AdditionalAttributesAndInformation), if allowed for this catalog.
• Rights Restriction (RLS): access is already inherited from PhysicalPersons; if necessary, restrictions by file type or organization can be added through access restriction templates.

Requires verification: the list of mechanisms allowed for this catalog by BSP (additional properties, categories) is configured in the configuration and may differ in the release 3.0.74.2.