Directory "Client Notification Types" — Technical Description (UT for Kazakhstan 3.4.5.21)

1. Identification

Purpose. A classifier catalog that stores the list of types (kinds) of notifications sent to clients within the customer interaction subsystem (CRM / marketing / service). The catalog values are used as an analytics dimension when configuring, planning, and recording the facts of informing the client — for example, "Order Arrival Notification", "Debt Reminder", "Shipment Notification", "Promotion Information". This is a reference (master data) object: it does not participate in accounting or tax accounting and does not generate postings.

The catalog belongs to the applied classifiers of the configuration. It is populated by the user/implementer according to the business processes of a specific organization; predefined items are generally not defined (see item 7).

2. Header Attributes and Tabular Sections

No specific description of the attribute composition is present in the attached evidence, so the typical composition for this type of object is given below. Verify the exact list in Designer for version 3.4.5.21.

Standard Attributes (Platform)

Typical Header Attributes (Applied)

Tabular sections. Tabular sections are typically not used for a classifier of this kind. If the version provides for linking message templates by channel, this is more often implemented via a separate reference attribute or a related template catalog, rather than a tabular section.

3. Forms

No separate forms are recorded in the evidence; the standard set of catalog forms is used. In the absence of custom forms, the platform generates them automatically.

4. Key Module Procedures

The attached evidence contains no BSL fragments (path:line) for this catalog, so the typical handlers characteristic of a classifier catalog are listed. Verify their presence and content in Designer for version 3.4.5.21.

Object module (МодульОбъекта):

• FillingProcessor(FillingData, ...) — initial filling of attributes when entering a new item, including default channel substitution.
• BeforeWrite(Cancel) — validation of attribute correctness before writing (e.g., uniqueness of the name, mandatory channel).
• FillCheckProcessing(Cancel, CheckedAttributes) — checking that key fields are filled in.

Form module (МодульФормы of list/item):

• OnCreateAtServer(Cancel, StandardProcessing) — configuring the visibility and availability of form elements.
• OnChange of the corresponding fields (e.g., SendMethodOnChange) — managing dependent availability of attributes.

Manager module (МодульМенеджера):

• Export functions for retrieving default/channel-specific items, if required by the applied logic of the notification subsystem.

Requires verification (version-specific): the presence of custom forms and manager export methods in 3.4.5.21 — the specific composition depends on how the notification subsystem is implemented in this build.

5. Posting and Movements

The object is a catalog and is not posted — the posting mechanism is not applicable to catalogs. Catalog items do not generate accounting entries or accumulation/information register movements independently and do not affect VAT, IIT, MPC, MSHI, or other calculations.

The catalog values serve only as an analytical dimension in other objects (documents/registers of the notification subsystem) where the fact of informing the client is recorded. Such registers record the notification type, client, channel, and date, but not monetary amounts.

For reference — the accounting framework of the Trade Management configuration for Kazakhstan (current parameters for 2026), with which this catalog does not directly intersect:

Standard RK accounts (1210 accounts receivable, 1030 cash, 1330 inventory, 3310 accounts payable, 3130 VAT payable, 6010 sales revenue, 7010 cost of sales) are used by the trade and cash documents of the configuration, but not by this catalog.

6. Related Objects and Input Based On

• Value consumers. Attributes/settings of the client notification subsystem where the notification type is selected (recording the fact of informing, message templates/mailing scenarios, notification settings for orders and debts).
• Related catalogs. Partners/Counterparties (notification recipients), catalogs of message templates and communication channels (if provided by the build).
• Input based on. Not applicable for a classifier: the catalog is not a basis for entering documents and is not itself entered based on anything. Population is manual or via initial filling/data exchange.

7. Extension Points

• Configuration extension. Adding custom attributes (e.g., priority, linkage to a trigger event), customizing the list/item forms, intercepting BeforeWrite/FillCheckProcessing via object module borrowing.
• Additional attributes and information (SSL). If the property mechanism is enabled for the catalog, its composition can be extended with additional attributes without modifying the configuration.
• Additional processing/event subscriptions. Subscribing to BeforeWrite/OnWrite of the catalog for integration with external mailing services.
• Predefined items. If rigid linkage of applied logic to specific types is required, they can be made predefined (requires modifying the main configuration or an agreed methodology; the presence of predefined items in the standard 3.4.5.21 delivery should be verified).