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 attributeCategoryPurpose(flagShowError): when the value is empty, adds an error message and setsRefusal = 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
EditSelectedand its associated 2 events — calls the standard mechanism for bulk attribute changes (FileSelectionDialog/BulkChangeObjects) for selected rows in the list. Allows mass reinstallation ofCategoryPurposefor 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/ItemFormthrough 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.