---
title: "Guide \"Complete Paths to Forms\" (Accounting for Kazakhstan 3.0.74.2)"
country: KZ
lang: en
author: Сапа Т.И. (https://buhgpt.kz/authors/sapa-ti)
date: 2026-09-07
canonical: https://buhgpt.kz/suraqtar/spravochnik-polnyeputikformam-buhgalteriya-dlya-kazahstan-en
source: BuhGPT
---

# Guide "Complete Paths to Forms" (Accounting for Kazakhstan 3.0.74.2)

> **TL;DR:** 1. Identification Parameter Value Object Type Catalog Name FullPathsToForms Full Name Catalogs.FullPathsToForms / Catalog.FullPathsToForms Alias not set (—) Configuration Accounting for Kazakhstan, ed. 3.0.74.2 Hierarchy no Owner none (not subordinate) Purpose Service (system)

---

1. Identification

Parameter
Value

Object Type
Catalog

Name
FullPathsToForms

Full Name
Catalogs.FullPathsToForms / Catalog.FullPathsToForms

Alias
not set (—)

Configuration
Accounting for Kazakhstan, ed. 3.0.74.2

Hierarchy
no

Owner
none (not subordinate)

Purpose
Service (system) catalog for storing full paths to configuration forms and their hash identifiers.

Purpose in detail. The catalog is a service object that supports the internal mechanisms of the platform and libraries (BSP). It stores the correspondence "full path to form → checksum (hash) of the form". This is used for identifying forms in metadata, caching, and tracking changes in form structure (versioning of interfaces). The object is not intended for interactive work by end users (accountants, warehouse workers, managers) and does not participate in accounting operations — it does not generate accounting entries and does not affect tax calculations (VAT 16%, PIT, OPE, OMS/VOOMS, social tax, MRP 4,325 ₸, MSP 85,000 ₸, etc. are not related to this object).

Where to find in 1C. Section "Service Technology" → "Full Paths to Forms". Direct navigation link: e1cib/list/Catalog.FullPathsToForms. In the standard user interface, the object is hidden and works "under the hood".

2. Header Attributes and Table Parts

2.1 Header Attributes

Name
Type
Mandatory
Purpose

FullPathToForm
String (xs:string)
Optional (DontCheck)
Stores the full path to the form in the configuration (for example, Catalog.Counterparties.Form.ElementForm). Used for unambiguous identification of the form in metadata.

Hash
String (xs:string)
Optional (DontCheck)
Contains the hash value (checksum) of the form. Allows tracking changes in the form structure; used in caching and versioning mechanisms.

The standard attributes of the catalog (Code, Name, Link, DeletionMark, Predefined) are present by default in the platform. The substantive identification load is carried by the two application attributes above.

2.2 Table Parts

Table parts are absent.

3. Forms

No custom forms for this catalog are defined in the metadata. This confirms the service nature of the object: interactive editing by the user through the standard interface is not expected. If a list needs to be opened (for example, for diagnostics), the platform will automatically generate a list form by default.

Form
Availability
Purpose

Element Form
not defined
— (auto-generation by the platform upon request)

List Form
not defined
— (auto-generation by the platform upon request)

Selection Form
not defined
—

4. Key Procedures of Modules

The application BSL code (custom handlers of the object/module manager) for this catalog in evidence is not attached and, judging by the service purpose of the object, is absent. Filling and reading the catalog is performed programmatically from the common modules of the platform/BSP responsible for form caching.

Standard handlers apply to catalogs of this type (if they are added in a specific version — version-specific, requires verification in a specific release):

- ObjectModule.FillProcessing — filling attributes when programmatically creating a record (path + hash of the form).

- ObjectModule.BeforeWriting / OnWriting — control/normalization of values FullPathToForm and Hash.

- ManagerModule — methods for searching records by form path and by hash, used in caching mechanisms.

There is no application business logic (posting, calculations) in the modules.

5. Posting and Movements

The catalog is not a document and is not posted: it does not generate accounting entries and movements in registers. It has no relation to the chart of accounts of the RK (1210, 1030, 1330, 3310, 3130, 6010, 7010), to VAT, PIT, contributions (OPE 10%, OPEI 3.5%, VOOMS 2%, OMS 3%, social tax 5%, social tax 6%) and to electronic documents (ESF IS ESF, SNT).

The data of the catalog is used exclusively for technical purposes — to match form paths and their hashes when working with caching and versioning mechanisms.

6. Related Objects and Input on Basis

- Input on basis — not supported (the object is service).

- Not a basis for documents and is not input on the basis of other objects.

- Connections are technical in nature: attribute values refer to forms of configuration objects through string paths (MetadataObject.Form.FormName), and the hash is related to the structure of the corresponding form. There are no explicit reference connections (like CatalogReference/DocumentReference) for the object.

7. Extension Points

- Configuration extensions (without removal from support). It is not recommended to modify the service catalog: it supports internal mechanisms, and interference may disrupt form caching. If modification is unavoidable — use an extension and add your own attributes without affecting FullPathToForm and Hash.

- Programmatic reading. For diagnostics, it is permissible to read the catalog via a query/through the manager (search by form path), but writing data should be left to the platform's standard mechanisms.

- Updates. When updating the release, the contents of the catalog are automatically repopulated; manual edits will be lost. The presence/composition of service handlers may change between versions — requires verification in a specific release.

- Do not use this object as a reference-classifier in application modifications: for user data, create a separate object.

---
_BuhGPT — ИИ-помощник для бухгалтеров Казахстана: https://buhgpt.kz_