--- title: "Reference \"DeleteObjectCategories\" — Technical Description" country: KZ lang: en author: Сапа Т.И. (https://buhgpt.kz/authors/sapa-ti) date: 2026-09-07 canonical: https://buhgpt.kz/suraqtar/spravochnik-udalitkategoriiobektov-tehnicheskoe-opisanie-en source: BuhGPT --- # Reference "DeleteObjectCategories" — Technical Description > **TL;DR:** 1. Identification Parameter Value Object Type Catalog Name DeleteObjectCategories Full Path Catalog.DeleteObjectCategories / Catalogs.DeleteObjectCategories Synonym not specified (in older builds displayed as “(Do not use) Object Categories”) Configuration Accounting for Kazak --- 1. Identification Parameter Value Object Type Catalog Name DeleteObjectCategories Full Path Catalog.DeleteObjectCategories / Catalogs.DeleteObjectCategories Synonym not specified (in older builds displayed as “(Do not use) Object Categories”) Configuration Accounting for Kazakhstan, ed. 3.0 (3.0.74.2) Interface Section Universal Mechanisms → “(Do not use) Object Categories” Navigation Link e1cib/list/Catalog.DeleteObjectCategories Purpose. An obsolete auxiliary catalog designed for classifying information base objects by categories with a specified purpose. The prefix Delete in the name is a standard marking of the 1C platform for objects that have been decommissioned: they are retained solely for backward compatibility and correct data transfer when updating from previous versions. The catalog was part of the subsystem for managing additional properties of objects and worked in conjunction with the characteristic types plan DeletePropertyCategoryAssignments. Requires verification (version-specific): in different builds of 3.0.x, the visibility in the interface and the presence of the synonym “(Do not use)” differ. In 3.0.74.2, the object is marked as obsolete; it should not be used in new business processes. 2. Header Attributes and Table Parts 2.1 Header Attributes Name Type Mandatory Purpose CategoryPurpose CharacteristicTypesPlanLink.DeletePropertyCategoryAssignments Mandatory (ShowError) Defines the target purpose of the category, linking it to the type of objects or area of application. Used for classifying and filtering categories by functional criteria. When changing the attribute for an existing item, the system checks for the absence of links in the information register. Name String (standard attribute) Standard Displayed name of the category. Inherited from the base type “Catalog”, explicitly not described in metadata.attributes, but present in the item form. Code String/Number (standard attribute) Standard Unique code of the item, assigned automatically. Inherited from the base type “Catalog”. 2.2 Table Parts Table parts are absent. The catalog has a simple flat structure without additional data collections. 3. Forms The catalog contains three standard forms: Form Purpose ItemForm Form for editing a single category. Contains fields Name, Code, and CategoryPurpose. The key form for creating and editing items. SelectForm Form for selecting a category from a list when substituting into the attributes of other objects. Tabular representation with search and filtering. ListForm Main form for viewing the list of categories. Contains an additional command “EditSelected” for bulk editing of items (2 form events, 1 command). 4. Key Module Procedures There is no explicit BSL code for modules in the evidence. Below are typical handlers characteristic of a catalog of this type in BK 3.0. Object Module (ObjectModule) - CheckFilling(Refusal, CheckedAttributes) — control of the mandatory attribute CategoryPurpose (flag ShowError): when the value is empty, adds an error message and sets Refusal = True. - BeforeWriting(Refusal) — typical integrity control point; for an obsolete object, usually checks for the absence of invalid links in information registers when changing the purpose. List Form Module (ListForm) - Command EditSelected and its associated 2 events — calls the standard mechanism for bulk attribute changes (FileSelectionDialog/BulkChangeObjects) for selected rows in the list. Allows mass reinstallation of CategoryPurpose for selected items. Item Form Module (ItemForm) - OnCreateOnServer(Refusal, StandardProcessing) — initial initialization of form fields (Name, Code, CategoryPurpose). Since the evidence does not contain paths path:string, specific procedure names and their placement should be confirmed by the configurator of this build. 5. Posting and Movements The object is a catalog, not a document: it is not posted and does not generate movements in accumulation/accounting registers. This object does not create postings according to the RK chart of accounts. The only “data movement” related to the catalog is writing/reading in the information register of the additional properties subsystem (historical link “category ↔ purpose”), as well as control of referential integrity when changing CategoryPurpose. For reference: accounting entries and tax calculations (VAT 16%, PIT, social contributions, etc.) are generated by configuration documents (sales, receipts, payroll) using accounts from the standard RK chart of accounts — 1210 (short-term receivables from customers), 1030 (money in current accounts), 1330 (goods), 3310 (payables to suppliers), 3130 (VAT payable), 6010 (revenue from sales), 7010 (cost of sales). This catalog does not participate in these movements. 6. Related Objects and Input Based On Relation Object Nature of Relation Attribute Type CharacteristicTypesPlan.DeletePropertyCategoryAssignments CategoryPurpose refers to the elements of this CTP. Subsystem Mechanism of additional properties of objects (obsolete) Historical use of categories for classifying IB objects. Information Register Register(s) for storing property/category values Checks for the presence of links when changing the purpose. Input based on for this catalog is not provided (neither as a basis nor as a result). The obsolete object does not participate in input chains based on current documents. 7. Extension Points - Configuration Extension. Adding attributes/forms is permissible, but considering the status “Delete…” — it is impractical; extensions should be made to current classification objects. - Form Event Handlers. Subscription to events ListForm/ItemForm through extension — if adaptation of bulk change is necessary (EditSelected). - Subscriptions to events (BeforeWriting, OnWriting) of the object — for control/logging in migration scenarios. - Data Migration. The main practical scenario is transferring values of obsolete categories to current mechanisms during updates; implemented by information base update handlers, not by direct modification of the catalog. Recommendation. Do not use the object in new logic. Any modifications related to object classification should be implemented on current mechanisms of additional information/properties in BK 3.0. --- _BuhGPT — ИИ-помощник для бухгалтеров Казахстана: https://buhgpt.kz_