Directory "Sales of Goods and Services Attached Files"

1. Identification

Purpose. The reference stores files attached to the "Product and Service Sales" documents and manages their lifecycle: uploading, storage (in the information base or on external volumes), versioning, encryption, and electronic signing. It is used by accountants and managers to attach scans of invoices, acts of completed work, electronic invoices (ESF)/SNT, and other primary documentation to sales operations. It works in conjunction with the "File Management" subsystem: it supports storage both in the database (ValueStorage) and on storage volumes. Access to files is from the sales document card through the attached files panel.

Where to find: e1cib/list/Reference.ProductServiceSalesAttachedFiles

This is a service (technical) reference of the attached files mechanism. The user does not work directly with the list but with files through the panel on the owner document form. Direct opening of the list is an administration/debugging scenario.

2. Attributes and Structure

2.1 Header Attributes (from evidence)

2.2 Standard Attributes of the BSL Mechanism (supplement header)

In addition to the above, the attached files reference usually contains:

• Volume (ReferenceLink.StorageVolumes) — the volume on which the file is stored when stored outside the database;
• VersionUsed / CurrentVersion — reference to the active version (when versioning is enabled);
• FileStorageType — indicator of storage: in the information base or on the volume;
• UploadCompleted — indicator of successful upload completion;
• file content — in the binary data information register or in ValueStorage of the version.

The exact composition of service attributes is version-dependent (implementation of the "File Management" subsystem of BSL). Requires verification for the specific build 3.0.74.2 if there is programming work with the storage.

2.3 Table Parts

The reference does not have its own table parts — it is a flat file card. Versions (history) are stored by a separate versioning mechanism, not by a table part.

3. Forms

In practice, file management is conducted through common forms of the "File Management" subsystem (attached files panel on the owner document form, file viewing and selection forms), rather than through the reference's own forms. Therefore, the set of its own forms is minimal.

4. Key Procedures of Modules

BSL modules in evidence are not attached. Below are typical handlers for the attached files reference of BSL.

Object Module (ObjectModule):

• FillProcessing(FillingData, StandardProcessing) — filling Author, CreationDate upon element creation.
• BeforeWriting(Refusal) — recording ModifiedBy, UniversalModificationDate; controlling file occupancy for editing.
• BeforeDeletion(Refusal) — clearing data on the storage volume and related versions.
• OnCopying(CopyingObject) — resetting service flags (EditingUser, SignedEP, references to versions) for the copy.

Manager Module (ManagerModule):

• integration procedures with common modules FileManagement / ServiceFileManagement: adding a file, updating a version, transferring between the database and volume, text extraction, applying/checking EP.

Specific paths path:string are not provided, as BSL evidence is not available. Implementation is delegated to the common modules of the "File Management" subsystem of BSL.

5. Posting and Movements

The reference is not posted and does not generate movements in registers — it is an object of type "Reference", it has no posting mechanism, registrars, or accounting entries. An attached file does not affect accounting totals; it only stores the attachment and metadata.

Accounting movements are generated by the owner document Document.ProductServiceSales. For context — standard posting logic for sales in the RK (typical chart of accounts of the RK, VAT rate 16 %, currency — tenge ₸):

Example: sale for the amount of 116,000 ₸ with VAT → revenue without VAT 100,000 ₸ (Dr 1210 Cr 6010), VAT 16,000 ₸ (Dr 1210 Cr 3130). Upon receipt of payment to the account — Dr 1030 Cr 1210. Electronic support for sales — issuance of ESF (IS ESF) and, if necessary, SNT; their printed/xml forms are typical candidates for attachment to the document in the form of files of this reference.

Other rates/limits of RK-2026 applicable in related calculations of the configuration (for reference, not directly related to this reference): MRP 4,325 ₸, MZP 85,000 ₸; basic deduction for individual income tax — 30 MRP/month (not more than 360 MRP/year); individual income tax 10 % up to 8,500 MRP of annual income and 15 % above; OPE 10 % (base ceiling 50 MZP), OPEI 3.5 %, VOSMS 2 %, OSMS 3 %, CO 5 %, social tax 6 %.

6. Related Objects and Input Based on

• Document.ProductServiceSales — owner of the files (attribute FileOwner). Files are attached from the form of this document.
• Reference.Users — source of values for Author, ModifiedBy, EditingUser.
• Reference.StorageVolumes — volumes of external storage (when stored outside the database).
• Enumeration.TextExtractionStatus — statuses of full-text indexing.
• Common modules/forms of the "File Management" subsystem (BSL) — all UI and logic for uploading/downloading/signing/versions.

Input based on: not applicable. Attached files do not participate in the input based on scheme and do not generate documents; elements are created only through the mechanism of attaching files to the owner document.

7. Extension Points

• Configuration extension for intercepting BeforeWriting / FillProcessing of the object module — for example, additional checks of file types/sizes, auto-filling Description.
• Event subscriptions (BeforeWriting, BeforeDeletion) of the reference — auditing operations with files, integration with external archive.
• Overridable common BSL modules "File Management" (FileManagementOverridable and analogs) — setting rules for storage, encryption, text extraction, applying EP.
• Additional attributes/information (subsystem "Properties") — if necessary for classification of files (document type, approval status).
• Configuration of storage volumes and rules for transferring files from the database to volumes — by regulatory assignments.

When making modifications, do not change the service attributes of the storage directly — use the API of the "File Management" subsystem, otherwise the integrity of the "file card ↔ version ↔ volume" linkage will be violated.