--- title: "Directory \"Key Operations\" (Catalogs.KeyOperations)" country: KZ lang: en author: Сапа Т.И. (https://buhgpt.kz/authors/sapa-ti) date: 2026-09-07 canonical: https://buhgpt.kz/suraqtar/spravochnik-klyuchevyeoperacii-catalogs-klyuchevyeoperaci-en source: BuhGPT --- # Directory "Key Operations" (Catalogs.KeyOperations) > **TL;DR:** 1. Identification Parameter Value Object Type Catalog Name KeyOperations Full Name Catalog.KeyOperations ( Catalogs.KeyOperations ) Synonym — (no separate synonym is defined in the original delivery; appears in the interface as "Key Operations") Configuration Accounting for Ka --- 1. Identification Parameter Value Object Type Catalog Name KeyOperations Full Name Catalog.KeyOperations (Catalogs.KeyOperations) Synonym — (no separate synonym is defined in the original delivery; appears in the interface as "Key Operations") Configuration Accounting for Kazakhstan, edition 3.0, version 3.0.74.2 Subsystem Library of Standard Subsystems (BSP), subsystem "Performance Evaluation" (PerformanceEvaluation) Hierarchy No (flat list) Owner No (independent catalog) Purpose. The catalog stores a list of key operations of the configuration — typical user actions, the execution time of which is measured and monitored (document processing, report generation, form opening, etc.). For each operation, the standard (target) execution time, priority, and minimum acceptable performance level are specified. Based on these standards, the "Performance Evaluation" subsystem compares actual measurements and identifies performance degradation. This is a service-administrative object of BSP, not related to accounting. It does not participate in accounting entries, tax calculations, and electronic document management (ESF/SNT). The rates and limits of the RK for 2026 (VAT 16%, MRP 4,325 ₸, MSP 85,000 ₸, PIT, OPV, social tax, etc.) are not applicable to this object — it does not calculate anything according to the RK chart of accounts. Work with it is rare: at the initial setup stage or when reviewing performance requirements. Where to find: navigation link e1cib/list/Catalog.KeyOperations. In the interface — administrative section, functionality "Performance Evaluation" of standard subsystems. 2. Attributes and Table Parts 2.1. Header Attributes Name Type Mandatory Purpose Name String Optional (DontCheck) Technical system name of the operation for program identification; serves as a key link to the performance measurement code MinimumAcceptableLevel EnumerationReference.PerformanceLevels Optional (DontCheck) Minimum acceptable performance level of the operation (e.g., "Critical", "Important", "Normal"); affects alert criteria during degradation Priority Number Optional (DontCheck) Numeric priority for sorting and determining the sequence of control; must be unique — checked upon saving TargetTime Number Mandatory (ShowError) Standard target execution time of the operation (seconds); basic indicator for comparison with actual measurements. The requirement is removed if the performance evaluation functionality is disabled NameHash String Optional (DontCheck) MD5 hash of the element for integrity control and change tracking; calculated automatically in the BeforeSaving handler ExecutedWithError Boolean Optional (DontCheck) Indicates that the last execution of the operation ended with an error; used for stability analysis LongRunning Boolean Optional (DontCheck) Flag "operation is long-running by nature"; affects evaluation algorithms and threshold values for deviations The standard attributes of the catalog are Name (representation of the operation for the user), Code, DeletionMark, Predefined. 2.2. Table Parts None. The catalog has a flat structure without subordinate tables. 3. Forms Form Purpose ElementForm Main form for creating and editing a key operation. Contains input fields: Name, Name, Priority, TargetTime, MinimumAcceptableLevel. Main point of work with a specific operation ListForm Tabular representation of all key operations (5 columns with characteristics). Entry point for navigation through the catalog; opened via link e1cib/list/Catalog.KeyOperations SelectionForm Service form for selecting an operation from other objects of the subsystem (measurement setup wizard, service processing of performance evaluation) 4. Key Procedures of Modules From the evidence for this version, the following logic has been recorded (handlers of the object module): - BeforeSaving — automatically calculates and fills the attribute NameHash (MD5 of the name/key fields of the element) for integrity control and tracking changes of the operation. - Control of uniqueness of Priority — upon saving, it is checked that the priority value does not match the priority of another operation; in case of a duplicate, the saving is rejected with an error message. - Conditional mandatory TargetTime — the check for filling (ShowError) is removed if the performance evaluation functionality in the configuration is disabled (checked via functional option/subsystem parameters). Typical handlers of this type of object, working in conjunction with BSP "Performance Evaluation": - FillingProcessing — filling default attributes when created from the subsystem code; - ElementForm.OnCreateOnServer / OnOpen — managing visibility and mandatory fields depending on the state of functionality; - server methods of the common module PerformanceEvaluation / PerformanceEvaluationService (BSP) — registration of measurements and comparison with the standards of this catalog. Requires verification: the exact paths Module:string and the full composition of export procedures depend on the specific BSP assembly integrated into 3.0.74.2. 5. Processing and Movements The catalog is not processed and does not generate accounting entries and movements in accounting/accumulation registers. As a metadata object of the type "Catalog," it does not have a processing mechanism in principle. The functional connection is not entries, but data from the "Performance Evaluation" subsystem: the elements of the catalog serve as standards (norming catalog) against which actual time measurements are compared. Actual data is accumulated not by this object, but by service information registers of BSP: - TimeMeasurements — aggregated measurements for key operations; - TechnologicalTimeMeasurements (or similar assembly) — detailed technical measurements. It is these registers that refer to the elements Catalog.KeyOperations through the measurement "KeyOperation". Accounting accounts of the typical RK chart of accounts (1210, 1030, 1330, 3310, 3130, 6010, 7010, etc.) are not involved in the operation of the object — it does not relate to the accounting contour. 6. Related Objects and Input Based On - Enumeration PerformanceLevels — source of values for the attribute MinimumAcceptableLevel. - Information registers TimeMeasurements / TechnologicalTimeMeasurements — consumers of the catalog (measurement "Key operation"). - Common modules PerformanceEvaluation, PerformanceEvaluationService, PerformanceEvaluationClient (BSP) — program API for registering measurements and working with standards. - Processing of the performance evaluation subsystem — reports on degradation/update of standards. Input based on for this catalog is not provided — filling is performed manually by the administrator or programmatically using BSP tools. 7. Extension Points - Configuration Extensions: adding custom attributes (for example, responsible for the operation, comment, business process tag) and columns in ListForm; supplementing handlers BeforeSaving/OnSaving without removing the object from support. - Event Subscriptions: handling BeforeSaving/OnSaving of the catalog for custom audit of changes to standards. - Functional Options: managing visibility and mandatory fields (in particular TargetTime) through the availability option of the performance evaluation functionality. - BSP API: registering custom key operations from application code through methods of the module PerformanceEvaluation — recommended way instead of direct recording of catalog elements. - Forms: overriding ElementForm/ListForm in the extension to add service commands (recalculate hash, check uniqueness of priorities in bulk). When making modifications, maintain control of the uniqueness of Priority and auto-filling of NameHash — they are crucial for the correct matching of measurements. --- _BuhGPT — ИИ-помощник для бухгалтеров Казахстана: https://buhgpt.kz_