1. Identification
| Parameter | Value |
|---|---|
| Object Type | Catalog |
| Name | DocumentOriginalStates |
| Full Name | Catalog.DocumentOriginalStates (Catalogs.DocumentOriginalStates) |
| Synonym | — (not set; the name/description of the element is used in the presentation) |
| Configuration | Accounting for Kazakhstan, edition 3.0 (version 3.0.74.2) |
| First Appeared | Release 3.0.73 |
| Where to Find | Navigation link: e1cib/list/Catalog.DocumentOriginalStates |
Purpose. The catalog stores a user-defined classifier of the states of paper (or other material) originals of primary documents — for example, "Original received", "Original expected", "Original returned", "Original not required". It is used in the electronic document management subsystem and in the primary document accounting mechanisms to track the status of the physical original document: whether it has been received from the counterparty, sent, or archived. The values of the catalog mark documents/lines, helping the accountant and clerk control the completeness of originals for tax and accounting purposes.
The catalog is maintained manually: the user creates the necessary states. Typically, it is filled out once during setup and then only occasionally supplemented. This is a simple auxiliary classifier without complex business logic.
2. Attributes and Tabular Parts
2.1 Header Attributes
| Name | Type | Mandatory | Purpose |
|---|---|---|---|
| Description | String | DontCheck | Text description/name of the original state (what the user sees when selecting a value). The main substantive field of the element. |
| SortingAdditionalAttribute | Number | DontCheck | Order — a number for manual sorting of states in selection lists, to arrange them in a logical sequence rather than alphabetically. |
In addition to the listed attributes, the element has standard platform fields — in particular, Name and Code, used as the representation of the element.
2.2 Tabular Parts
Tabular parts are not defined (tabular_sections: []). The catalog is flat, consisting only of header attributes.
3. Forms
Custom forms in the object card are not defined (forms: []). Automatically generated platform forms are used:
| Form | Purpose |
|---|---|
| Element form (auto) | Input/editing of a single state: name, attribute "Description", sorting order. |
| List form (auto) | Viewing and maintaining the entire classifier of states, selecting values in other objects. |
| Selection form (auto) | Choosing a value when filling out document attributes/electronic document management subsystem. |
The automatically generated forms are sufficient for maintaining a simple classifier; custom forms have not been created by the standard configuration developer.
4. Key Module Procedures
No application BSL code in evidence for this catalog is attached, and for a classifier of this type, it is generally absent. Below are typical handlers characteristic of a catalog of this kind:
- Object Module — usually empty or contains the standard
FillingProcessing(initial filling of attributes when inputting based on) andBeforeSaving(basic control). There is no specific processing logic — the catalog does not generate movements. - Manager Module — usually empty; if necessary, it may contain functions for obtaining predefined/typical state values.
- Forms — platform forms are used, so there are no custom form modules.
Requires verification: the presence of the
FillingProcessingprocedure and predefined elements may differ in a specific release assembly (appeared in 3.0.73).
5. Posting and Movements
The catalog is not a document and does not generate movements in accumulation registers, information registers, or accounting registers. It does not create postings.
The role of the object is to be a reference-value (analytics/attribute), which marks the state of the original document in the electronic document management subsystem and primary document accounting. Accounting consequences arise not from the catalog, but from the primary documents to which the original belongs. For reference — typical postings of such documents are formed according to the chart of accounts of the RK:
| Business Operation | Debit | Credit |
|---|---|---|
| Sale of goods to the customer (income) | 1210 "Short-term receivables from customers" | 6010 "Income from sales" |
| VAT accrual on sales (16%) | 1210 | 3130 "VAT payable" |
| Cost of goods sold | 7010 "Cost of sales" | 1330 "Goods" |
| Receipt of goods from the supplier | 1330 | 3310 "Payables to suppliers" |
| Payment to the supplier from the current account | 3310 | 1030 "Cash in current accounts" |
Note on VAT: from 2026, a rate of 16% is applied in the RK (for example, with a base of 1,000,000 ₸ VAT = 160,000 ₸). Electronic support for primary documents is ESF (ESF IS) and SNT; it is to these documents that the control of the original state applies.
6. Related Objects and Input Based On
- Electronic Document Management and Primary Document Accounting Subsystem — the main consumer of the catalog: the values mark the state of the original for receipt/sale documents and electronic documents (ESF, SNT).
- Primary Documents (receipts, sales, invoices) — use the catalog element as a state attribute of the paper original.
- Input Based On — not provided: the catalog is a value-classifier, not a source for documents.
7. Extension Points
- Adding New States — a standard scenario: the user/implementer creates their own values (for example, "Original in transit", "Scan received, original expected"). The order of display is regulated by the attribute
SortingAdditionalAttribute. - Extending the Configuration — it is possible to add attributes (for example, "RequiresControl", "IndicationColor") or a custom list form with conditional formatting for visually highlighting problematic states.
- Event Subscriptions / BSL — when refining the control of the completeness of originals, the catalog can be conveniently used as a source of statuses in reports and processes for missing primary documents.
- Integration with Reporting — catalog values can be displayed in universal reports and customizable document lists to control the presence of originals before closing the period.
When making modifications, ensure compatibility with the standard electronic document management subsystem: do not redefine standard representation fields (Name/Code) and do not change the purpose of the sorting attribute.