1. Identification
| Parameter | Value |
|---|---|
| Object Type | Catalog |
| Name | AccountingCheckRules |
| Full Name | Catalog.AccountingCheckRules (Catalogs.AccountingCheckRules) |
| Synonym | Accounting check rules |
| Configuration | Accounting for Kazakhstan, edition 3.0.74.2 |
| Subsystem | Accounting control (Standard subsystems) |
| Navigation Link | e1cib/list/Catalog.AccountingCheckRules |
Purpose. The catalog stores a list of rules (checks) for the correctness of accounting. Each element describes a specific situation to be checked: the essence of the problem, its criticality, causes of occurrence, recommendations for resolution, and parameters for automatic execution (launch method, schedule, limits, start date of analysis). The system uses these rules to automatically identify errors and discrepancies in accounting data (for example, negative balances on account 1330 "Goods", unclosed advances on 1210/3310, VAT discrepancies on account 3130, absence of electronic invoices (ESF) for sales with movements on 6010/1210).
The catalog is a dictionary of control settings, not a document: it does not generate movements in registers, but sets metadata for the accounting check mechanism. Work with it is carried out during initial setup and periodically — when requirements for control change or after configuration updates.
Where to find: section "Standard subsystems" → "Accounting check rules" (or directly via the navigation link e1cib/list/Catalog.AccountingCheckRules).
2. Header Attributes and Table Parts
2.1 Header Attributes
| Name | Type | Mandatory | Purpose |
|---|---|---|---|
| ProblemCriticality | EnumerationReference.ProblemCriticality | Mandatory (ShowError) | Criticality of the identified problem ("Critical", "Important", "Informational"). Affects the priority of resolution and visual highlighting in the reports of the check results. |
| Identifier | String | Optional | Unique program code of the rule for linking with configuration metadata and handler procedures. Used during configuration updates to synchronize the predefined set of rules. |
| Usage | Boolean | Optional | Activity flag: True — check is performed, False — disabled. Automatically reset to False when the item is marked for deletion. |
| Causes | String (unlimited) | Optional | Text description of the causes of the problem. Used for user training and documenting the logic of the check. |
| Recommendation | String (unlimited) | Optional | Recommendations for resolving the problem. Displayed to the user along with the check results. |
| ExecutionMethod | EnumerationReference.ExecutionMethods | Optional | How the check is initiated: by schedule (regulatory task), on user demand, automatically when processing documents, etc. |
| RegulatoryTaskIdentifier | String | Optional | Identifier of the regulatory task when automatically executed by schedule. Links the rule with the background task. |
| AdditionalParameters | ValueStorage | Optional | Arbitrary structure of specific check parameters (filters, threshold values, algorithm settings). |
| CheckStartDate | Date (DateTime) | Optional | Initial date for data analysis. Allows exclusion of historical periods from the check. |
| ProblemLimit | Number (decimal) | Optional | Maximum number of problems identified in one run. Limits execution time and volume of results. |
| CheckExecutionSchedule | ValueStorage | Optional | Serialized schedule object (TaskScheduler) defining the frequency of auto-start for the regulatory task. |
In addition to the listed attributes, the element has standard catalog attributes: Code, Name, DeletionMark, Predefined. Typically, the catalog is not hierarchical and contains a predefined set of rules supplied with the configuration.
2.2 Table Parts
In the attached evidence, table parts are not recorded. For a catalog of this purpose, additional check parameters (filters, thresholds, list of controlled accounts/objects) are stored not in table parts, but in attributes of type ValueStorage (AdditionalParameters, CheckExecutionSchedule). The presence/absence of table parts is version-specific and is clarified in the configurator of the specific version.
3. Forms
| Form | Purpose |
|---|---|
| ListForm | Main list of rules. Displays the name, problem criticality, and usage flag; allows enabling/disabling rules, opening elements, and running checks on selected rules. |
| ElementForm | Rule card: editing criticality, identifier, causes, recommendations, execution method, start date, problem limit, and regulatory task schedule settings. |
| SelectionForm | Selecting a rule from other configuration objects (for example, when setting up groups of checks or when programmatically accessing a rule). |
The exact composition of forms depends on the version; in the absence of explicitly defined forms, the platform uses auto-generated list/element/selection forms.
4. Key Procedures of Modules
In the attached evidence, the text of the modules (BSL) is not provided. Below are typical handlers for a catalog of this type; specific lines should be viewed in the modules of the object/form of the corresponding version.
Object Module (BeforeWriting, BeforeCopying):
BeforeWriting— control of filling the mandatory attributeProblemCriticality; synchronization of theUsageflag withDeletionMark(when setting the deletion markUsage→False).CheckFillingHandler— check of fillingProblemCriticality(ShowError) and, whenExecutionMethod = BySchedule, requirement for filledCheckExecutionSchedule.
Manager Module / Common Modules of the Control Subsystem:
- Procedures for obtaining active rules (
Usage = True) and launching the associated accounting check mechanism. - Registration/updating of the regulatory task by
RegulatoryTaskIdentifierandCheckExecutionSchedule. - Formation of check results considering
ProblemLimit,CheckStartDate, and parameters fromAdditionalParameters.
Element Form Module:
OnCreateOnServer/OnReadOnServer— restoration of schedule settings fromValueStoragefor display in the schedule control element.- Handlers for visibility/accessibility of schedule fields depending on the value of
ExecutionMethod.
5. Processing and Movements
The catalog is not a document and is not processed — it does not generate accounting entries and movements in accumulation/summary registers. Its role is to store check settings.
Movements in accounting registers are generated by documents, and the rules from this catalog only analyze the results of such accounting. Typical checks configured through the catalog are oriented towards the chart of accounts of the RK, for example:
- Negative balances of inventory — control of debit/credit balance on account
1330"Goods". - Unclosed settlements and advances — analysis of
1210"Short-term accounts receivable from customers" and3310"Short-term accounts payable to suppliers". - VAT control — reconciliation of turnover and balance on
3130"VAT payable" (the VAT rate in Kazakhstan from 2026 is 16%) with the register of issued/received ESF (IS ESF) and issued СНТ. - Completeness of sales reflection — comparison of income on
6010"Income from sales" and written-off cost7010"Cost of sales" with the presence of issued ESF. - Cash flow — control of the correctness of entries on
1030"Cash in current bank accounts".
The results of rule execution are saved by the accounting control mechanism (journal/register of check results of the "Accounting control" subsystem), not by the catalog itself.
6. Related Objects and Input Based On
Enumerations (attribute types):
Enumeration.ProblemCriticality— levels of criticality.Enumeration.ExecutionMethods— methods of initiation.
Platform/BSP Mechanisms:
- Regulatory tasks (
RegulatoryTask,TaskScheduler) — byRegulatoryTaskIdentifierandCheckExecutionSchedule. - Subsystem "Accounting control" — consumer of rules; forms and stores the results of checks.
Analyzed accounting objects (indirect link through check algorithms): sales/purchase documents, payment documents, accounting register (chart of accounts of the RK), electronic documents ESF and СНТ.
Input Based On. For the catalog, input based on is not provided and does not make sense: elements are created manually or supplied as predefined data of the configuration.
7. Extension Points
- Custom check rules. Creating new catalog elements by filling in
Identifier,Causes,Recommendation, and launch parameters; linking to a custom check algorithm throughAdditionalParameters. - Configuration extension (Extensions). Adding attributes/forms, overriding handlers
BeforeWriting,CheckFillingHandlerwithout removing the configuration from support. - Schedule settings. Changing
ExecutionMethodandCheckExecutionScheduleto fit the enterprise regulations (for example, monthly VAT control before generating ESF). - Parameterization through
AdditionalParameters. Storing threshold values and filters (list of controlled accounts, minimum amounts, organizations) without changing the metadata structure. - Localization of texts. Maintaining
Causes/Recommendationunder the requirements of the RK with indication of current norms for 2026 (VAT 16%, MRP 4,325 ₸, MZP 85,000 ₸).
Version-specific: the specific composition of predefined rules and the list of available values for enumerations ProblemCriticality/ExecutionMethods is clarified in the configurator of version 3.0.74.2.