1. Identification
| Parameter | Value |
|---|---|
| Object Type | Catalog |
| Name | ActOfReconciliationAttachedFiles |
| Full Name | Catalog.ActOfReconciliationAttachedFiles |
| Synonym | Attached Files (Acts of Reconciliation) |
| Configuration | Accounting for Kazakhstan, ed. 3.0 (3.0.74.2) |
| Owner(s) | Document.ActOfReconciliation |
| Hierarchy | No (flat list) |
| Type of Catalog | Service (technical), generated by the "File Management" subsystem (BSP) |
Purpose. The catalog stores files attached to the "Act of Reconciliation" documents: scanned originals of signed acts, electronic versions (PDF/XLSX), accompanying correspondence, and other related documents. It provides upload, storage (in the IB or on the volume), versioning, electronic signing, and encryption of reconciliation files.
The catalog is service: users do not work with it directly from the list, but interact through the "Attached Files" command of the owner document form. Direct opening of the list is mainly used by administrators and developers for diagnostics.
Where to find (for debugging/administration):
e1cib/list/Catalog.ActOfReconciliationAttachedFiles
User scenario: open the document Sales (Purchases) → Acts of Reconciliation, in the document form — the "Attached Files" command.
2. Attributes and Table Parts
2.1 Header Attributes
The set of attributes is standard for the attached files catalog of BSP. The "Mandatory" column reflects the validation of filling (ShowError — with error output, DontCheck — without validation).
| Name | Type | Validation | Purpose |
|---|---|---|---|
| Author | CatalogLink.Users | ShowError | User who uploaded the file to the system |
| FileOwner | DocumentLink.ActOfReconciliation | DontCheck | Owner document to which the file is attached |
| ModificationDateUniversal | Date and time | DontCheck | Date of the last modification of the file (UTC) |
| CreationDate | Date and time | ShowError | Date and time of the file record creation in the system |
| Encrypted | Boolean | DontCheck | Indicates that the file content is encrypted |
| ModifiedBy | CatalogLink.Users | DontCheck | User who last modified the file or its attributes |
| ImageIndex | Number | DontCheck | Index of the file icon (by extension) in the image collection |
| Description | String | DontCheck | Text description/comment for the file |
| SignedEP | Boolean | DontCheck | Indicates the presence of an electronic signature |
| FilePath | String | DontCheck | Path to the file on the storage volume (for external storage) |
| Size | Number | DontCheck | Size of the file in bytes |
| Extension | String | DontCheck | File extension without a dot (pdf, xlsx, …) |
| EditingUser | CatalogLink.Users | DontCheck | User who has taken the file for editing (lock) |
| TextExtractionStatus | EnumerationLink.TextExtractionStatuses | DontCheck | Status of text extraction for full-text search |
| TextStorage | ValueStorage | DontCheck | Extracted text content of the file (for indexing) |
| FileStorageType | EnumerationLink.FileStorageTypes | ShowError | Storage method: in IB or on the volume |
| Volume | CatalogLink.FileStorageVolumes | DontCheck | Storage volume (for external storage) |
| FileStorage | ValueStorage | DontCheck | Binary data of the file (when stored in IB) |
| StoreVersions | Boolean | DontCheck | Indicates versioning of the file |
| BorrowDate | Date and time | DontCheck | Date the file was taken for editing |
Semantic groups of attributes:
- File Identification:
Description,Extension,Size,ImageIndex. - Link to Owner:
FileOwner. - Data Storage:
FileStorageType,Volume,FilePath,FileStorage. Binary data is stored either in theFileStorageattribute (in IB) or on the volume (Volume+FilePath) — depending on the value ofFileStorageType. - Audit and Authorship:
Author,ModifiedBy,CreationDate,ModificationDateUniversal. - Locking/Editing:
EditingUser,BorrowDate,StoreVersions. - Security:
Encrypted,SignedEP. - Full-text Search:
TextExtractionStatus,TextStorage.
2.2 Table Parts
RemoveElectronicSignatures (not used)
Deprecated table part for storing electronic signatures of the file. The prefix "Remove" and the synonym "(not used)" indicate that it is preserved only for backward compatibility during migration to the new electronic signature storage mechanism (information register of the electronic signature subsystem BSP). It is not filled in new data; it should not be relied upon during refactoring.
Binary data of versions and the current file in the current BSP mechanism are stored in the subordinate versions catalog and/or registers of the "File Management" subsystem, not in the table parts of this catalog.
3. Forms
The service catalog of attached files uses a standard set of BSP forms. Custom forms for the object are generally not defined — common forms of the file management subsystem are used.
| Form | Purpose |
|---|---|
Element Form (ElementForm) |
File card: description, storage information, author, size, electronic signature; commands for opening, saving, editing, signing, encrypting |
List Form (ListForm) |
Service list of all files (for administration/diagnostics) |
Selection Form (SelectionForm) |
Selecting a file in service scenarios |
| General Form "AttachedFiles" (BSP) | Main user interface: list of files of the owner document with commands for adding, uploading, viewing, versions, electronic signature |
User interaction mainly occurs through the general form of attached files, opened from the "Act of Reconciliation" document.
4. Key Module Procedures
Evidence with source code (BSL) for this object is not attached. Below are typical handlers for the attached files catalog of BSP; specific names/lines should be clarified according to the target release module.
Object Module (ObjectModule):
BeforeWriting(Refusal)— control of the correctness of storage attributes (FileStorageType,Volume/FileStorage), synchronization ofModificationDateUniversal,ModifiedBy.BeforeDeletion(Refusal)— deletion of binary data of the file from the volume during external storage, to avoid leaving "orphans" on the disk.OnCopying(CopyingObject)— reset of storage data/lock indicators during copying.
Manager Module (ManagerModule):
- Procedures for forming views, form selection handlers, integration with common modules
FileManagement,FileManagementService.
Common modules of the subsystem (used by the object):
FileManagement/FileManagementService(ServerCall)— adding, updating, retrieving binary data, versions, locking (EditingUser,BorrowDate).ElectronicSignature— signing/verifying electronic signature, settingSignedEP.Encryption— encryption/decryption, setting theEncryptedindicator.- Full-text search subsystem — filling
TextStorage,TextExtractionStatus.
5. Posting and Movements
The object does not generate movements. It is a catalog, not a document: it is not posted, does not create postings in accounts and records in accumulation/accounting registers. The only "data movements" are service records of the file management subsystem (versions, history, full-text index).
The economic consequences are borne by the owner document "Act of Reconciliation", not the file. The act of reconciliation itself in the standard methodology of the RK is a document of reconciliation of settlement status and generally does not generate movements (it reconciles data, does not change accounting). Postings are generated by primary documents reflected in the accounts of mutual settlements that the act reconciles.
Accounts of mutual settlements and related operations (standard chart of accounts of the RK), to which the turnovers and balances reconciled by the act relate:
| Account | Purpose |
|---|---|
| 1210 | Short-term receivables from customers |
| 3310 | Short-term payables to suppliers |
| 1030 | Cash on current bank accounts |
| 1330 | Goods |
| 3130 | VAT payable (VAT rate in the RK from 2026 — 16%) |
| 6010 | Revenue from sales |
| 7010 | Cost of sales |
Example of movements of primary documents that subsequently enter the act of reconciliation (for context, amounts are conditional, ₸):
- Sale of goods: Dr 1210 Cr 6010 (revenue), Dr 1210 Cr 3130 (VAT 16%), Dr 7010 Cr 1330 (cost).
- Payment from the customer: Dr 1030 Cr 1210.
- It is the balance and turnovers on 1210/3310 that the act of reconciliation compares with the data of the counterparty.
The file attached to the act (scan of the signed act, PDF) does not participate in accounting — it merely documents the fact of agreement.
6. Related Objects and Input on Basis
- Owner Document:
Document.ActOfReconciliation(attributeFileOwner). - BSP Catalogs:
Users(Author,ModifiedBy,EditingUser),FileStorageVolumes(Volume). - BSP Enumerations:
FileStorageTypes(FileStorageType),TextExtractionStatuses(TextExtractionStatus). - Subsystems: "File Management", "Electronic Signature", "Encryption", "Full-text Search".
- Adjacent Objects in the Business Process: electronic documents of the RK — electronic invoice (ESF) and SNT; they relate to primary documents of sales/purchases, the turnovers of which are reflected in the act of reconciliation.
Input on Basis. This is not applied for this catalog — files are created exclusively by the "Attach File" command from the owner document form (or by uploading/scanning), not by the "Input on Basis" mechanism.
7. Extension Points
- Configuration Extensions: adding attributes (for example, "Type of Reconciliation Document", "Agreed by Counterparty") in the file form or in the general form of attached files through borrowing forms.
- Object Module Handlers:
P