1. Identification
| Parameter | Value |
|---|---|
| Object type | Catalog |
| Name | ВзаимозачетЗадолженностиПрисоединенныеФайлы |
| Full name | Catalog.ВзаимозачетЗадолженностиПрисоединенныеФайлы |
| Synonym | "Attached files (Debt offset)" |
| Configuration | Trade Management for Kazakhstan, ed. 3.4.5.21 |
| Owning subsystem | "File Operations" (part of the Standard Subsystems Library, SSL) |
| Subordinate to | the catalog is a service storage of attached files of the document Document.ВзаимозачетЗадолженности |
Purpose. The catalog stores metadata and (optionally) binary content of files attached by the user to the "Debt Offset" document (scanned reconciliation acts, offset agreements, counterparty letters, supporting source documents, etc.). This is a standard object of the SSL attached files mechanism: for each owner object to which files are allowed to be attached, the configurator creates a separate subordinate catalog named <OwnerName>AttachedFiles. The catalog itself does not participate in accounting and does not generate postings — it serves file upload, versioning, encryption, digital signature, and viewing.
Navigation link to open the list:
e1cib/list/Справочник.ВзаимозачетЗадолженностиПрисоединенныеФайлы
In regular operation, the list is not opened directly — files are viewed via the "Attached files" command in the "Debt Offset" document form. The direct navigation link is mainly used by an administrator/developer for diagnostics.
2. Attributes and tabular sections
The structure follows the SSL attached files template. The key service attribute is Owner (Owner, type DocumentRef.ВзаимозачетЗадолженности): subordination is implemented via the standard catalog owner mechanism, so "Owner" is not shown as a separate attribute in the attribute tree, but is available in queries and code.
2.1. Header attributes
| Attribute | Type | Purpose |
|---|---|---|
Description |
String | File name without extension (catalog item description) |
Extension |
String | File extension without dot (pdf, xlsx, png …) |
Author |
CatalogRef.Users | User who uploaded the file |
CreationDate |
Date | Moment the file was attached in the database |
UniversalModificationDate |
Date | Date of last content change (UTC) |
Size |
Number | Size of current content, bytes |
FileStorage |
ValueStorage | Binary file data when stored in the database (empty when stored in a volume) |
FileStorageVolume |
CatalogRef.FileStorageVolumes | Volume where the file is located when stored on disk |
PathToFileInVolume |
String | Relative path to the file inside the volume |
TextContent / TextStorage |
ValueStorage | Extracted file text for full-text search |
Signed |
Boolean | File has at least one attached digital signature |
Encrypted |
Boolean | Content is encrypted using cryptographic tools |
EditedBy |
CatalogRef.Users | User who checked out the file for editing ("in use" lock) |
PictureIndex |
Number | Icon index by file type for display in lists |
LocalizationCode |
String | Locale code of the content |
OwnerVersion |
String | Service mark of the owner object version at the time of editing |
SSLVersionNumber |
Number | Technical version number of the file storage format (used during SSL migrations) |
2.2. Tabular sections
| Tabular section | Key columns | Purpose |
|---|---|---|
DigitalSignatures |
Signature (ValueStorage), Certificate, IssuedTo, SigningDate, Comment |
Stores attached file digital signatures and certificate data |
EncryptionData (if encryption is used) |
Certificate, Presentation, Thumbprint |
Information about certificates used to encrypt the file |
Versioning. If file version storage is enabled in the configuration, content is stored not in the item itself but in a subordinate version catalog
ВзаимозачетЗадолженностиПрисоединенныеФайлыВерсии(or in a related version register), and the item'sCurrentVersion/VersionRecordattribute references the current version. The presence and exact name of the version object are version-specific and require verification in the specific build.
3. Forms
Attached files primarily operate on common forms of the "File Operations" subsystem, so the catalog itself has minimal forms of its own.
| Form | Type | Purpose |
|---|---|---|
Item form (ItemForm or common AttachedFile) |
Item form | File card: name, author, size, dates, "Open", "Edit", "Save as" buttons, digital signature and encryption operations |
Common form AttachedFiles |
Common form (list) | List of all files attached to a specific owner document; called by a command from the document form |
| Common encoding selection / upload form | Service | Uploading a new file, selecting text encoding, importing a folder |
The main entry point for the user is the "Attached files" command added to the command interface of the "Debt Offset" document form. It opens the common list form filtered by owner.
4. Key module procedures
No BSL program code evidence is attached — below are the standard handlers and service procedures typical of SSL attached files. Exact names/signatures in build 3.4.5.21 require verification against the configurator.
Catalog object module:
BeforeWrite(Cancel)— validation of file name and extension correctness, updatingUniversalModificationDate, checking the editing lock (EditedBy).OnCopy(CopiedObject)— clearing lock/signature flags on the copy.- Fill check handling — checking that the owner and storage method (volume or database) are filled in.
Manager module: typically contains service functions for retrieving file data and is usually thin — the main logic is moved to common modules.
Common modules that actually service the object:
FileOperations/FileOperationsClient— opening, editing, saving, printing files.FileOperationsInternal/…InternalServerCall— creating a catalog item on upload, writing content to a volume or toFileStorage, extracting text for search, updating size/dates.FileOperationsInVolumesInternal— placing and deleting binary data inFileStorageVolumesvolumes.- Digital signature/encryption subsystem modules — applying and verifying signatures, encrypting/decrypting content.
5. Posting and movements
The catalog is not posted and does not generate accounting entries or movements in accounting registers — it is a file storage, not an accounting document. Data "movement" is limited to writing binary content:
- when stored in the information base — data is written to the
FileStorageattribute (and to the subordinate version catalog/register if versioning is used); - when stored in volumes — the file is physically placed on disk, and the item's
FileStorageVolumeandPathToFileInVolumeare filled in.
All business movements are generated by the owner object — the "Debt Offset" document to which the file is attached. Under standard Kazakhstan logic, an offset closes mutual debts without cash movement and is usually VAT-exempt (an offset is not a sale): in terms of the Kazakhstan chart of accounts, this is reflected as closing the buyer's receivables (1210 "Short-term receivables from customers and clients") against payables to the supplier (3310 "Short-term payables to suppliers and contractors") for the offset amount in tenge (₸), with corresponding movements in mutual settlement registers. The attached file only documents the basis for the offset (reconciliation act, agreement) and does not affect these postings.
Reference values for Kazakhstan as of 2026 (for context on the owner's accounting operations, not for this catalog): VAT rate 16%, MCI 4,325 ₸, minimum wage 85,000 ₸; accounts for cash and goods movements in other operations — 1030, 1330, income/cost of sales — 6010/7010, VAT payable — 3130. These figures have no direct bearing on the attached files mechanism.
6. Related objects and input based on
| Relationship | Object | Nature of the relationship |
|---|---|---|
| Owner | Document.ВзаимозачетЗадолженности |
Each catalog item is subordinate to a single offset document |
| Storage volumes | Catalog.FileStorageVolumes |
Physical file placement on disk |
| Author / lock | Catalog.Users |
The Author, EditedBy attributes |
| Versions | subordinate attached files version catalog | Storage of content version history (if enabled) |
| Digital signature | SSL digital signature subsystem | Signatures are stored in the DigitalSignatures tabular section |
Input based on. "Input based on" is not applicable to the attached files catalog. Items are not created manually via "Create" — they are generated automatically when a file is uploaded to the owner document (the "Attached files" command → "Add"/drag-and-drop/from scanner).
7. Extension points
- File storage. Switching storage "in the IB ↔ in volumes" is configured in the "File Operations" subsystem (constants and the
FileStorageVolumescatalog) without modifying the catalog metadata. - Configuration extension. Via an extension, attributes can be added (e.g., offset document type/category, "original received" flag) and displayed on the common attached file form, as well as subscribing to object write events.
- Event subscriptions.
BeforeWrite/OnWriteobject handlers allow logging the upload of scanned copies and checking whether attachments are mandatory when posting the owner document. - Digital signature and encryption operations. Configured using standard SSL mechanisms; custom certificate validation and signature requirements for offset acts are implemented in digital signature subsystem handlers.
- Access restriction (RLS). File access rights inherit the owner's access logic; for a custom access model, RLS templates for the attached files catalog are configured in sync with the "Debt Offset" document.
- Type/size restrictions. Allowed extensions and maximum file size are set by "File Operations" subsystem settings and checked on upload.