User Notifications Directory (Catalogs.UserNotifications)

1. Identification

Purpose. The catalog stores system notifications sent to users of the information base. It is populated by internal mechanisms of the configuration to register notifications about events requiring user attention (for example, the need for document approval, receipt of an important message, expiration of data relevance). The object operates predominantly automatically: elements are created by code when certain conditions are met, and the user sees them through specialized notification interfaces, rather than by directly opening the catalog. Within the configuration, it is a service entity that ensures communication "system → user," including in multi-tenant (SaaS) scenarios due to data area separation.

Context note: the catalog is not related to accounting calculations (VAT, PIT, social contributions, etc.) and does not work with accounts from the chart of accounts of the RK. Therefore, tax rates and amounts are not applicable — the numerical norms of Kazakhstan 2026 are provided below only where appropriate (see section 5).

Where to find in 1C:

• Navigation link: e1cib/list/Catalog.UserNotifications
• Interface: section "Service Technology" → "User Notifications".

2. Attributes and Table Parts

2.1 Header Attributes

The standard attributes of the catalog (Reference, Code, Name, DeletionMark, Predefined) are present by default. Hierarchy for a service catalog of this kind is typically not used.

2.2 Table Parts

According to the evidence, significant application table parts for the catalog are not described (the section in the source is not filled). All useful information of the notification is stored in the header attributes — which is typical for a service object of this purpose. Requires verification in a specific delivery: the presence/composition of table parts is version-specific.

3. Forms

Specialized forms in evidence are not attached. For a catalog of this type, a standard set of forms is provided in the typical configuration (some may be generated automatically):

Since the object is service, the standard user interacts with notifications through the interface notification mechanisms, rather than directly through these forms.

4. Key Module Procedures

BSL-evidence (object module / manager module / form modules) is not attached, so below is a typical set of handlers for this type of object. Specific lines: paths require verification against the source code of the delivery.

Object Module (ObjectModule):

• BeforeWriting(Refusal) — service checks/filling before writing (for example, setting NotificationDate if not specified).
• OnCopy(ObjectCopy) — reset session-dependent attributes (UserSessionNumber, dates) when copying.
• FillProcessing(FillData, FillText, StandardProcessing) — filling fields when programmatically creating a notification.

Manager Module (ManagerModule):

• Export functions for generating and obtaining notifications (creating an element by parameters "user / text / type / relevance date", selecting relevant notifications for the session, clearing outdated ones by RelevanceDate).
• GetViewProcessing / generating a view by MessageText/NotificationType.

List/Element Form Module:

• OnServerCreation — initial setup of filtering (by current user, by relevance), conditional formatting of outdated rows.
• Service maintenance command handlers (mark as read, clear outdated).

Requires verification: the exact signature and presence of export methods of the manager — they are version-specific.

5. Conducting and Movements

The catalog is not conducted and does not generate movements in accounting registers, accumulation, or information. It is a data storage: recording an element only saves the notification card.

As a consequence:

• entries in the chart of accounts of the RK are not generated;
• accounts from the typical chart of accounts of Kazakhstan (for example, 1210 "Short-term receivables from customers", 1030 "Cash in current accounts", 1330 "Goods", 3310 "Payables to suppliers", 3130 "VAT payable", 6010 "Revenue from sales", 7010 "Cost of sales") are not used in the context of this object;
• tax calculations of Kazakhstan 2026 (VAT 16%; PIT 10% up to 8,500 MRP annual income and 15% above; basic deduction for PIT 30 MRP/month, not more than 360 MRP/year; social contributions 10% with a base cap of 50 MZP; social contributions for the self-employed 3.5%; health insurance 2%; social health insurance 3%; social tax 5%; MRP = 4,325 ₸; MZP = 85,000 ₸; currency — tenge ₸) are not applicable to this catalog.

These norms are provided for completeness regarding the configuration; the object "UserNotifications" does not participate in accounting and tax movements.

6. Related Objects and Input Based On

• Data separation model (SaaS/cloud): the attribute DataArea links elements to the tenant's data area; used by configuration separation mechanisms.
• Users/sessions: binding through UserName and UserSessionNumber to the user and their session.
• Deprecated enumeration DeleteNotificationTypes — historical link through DeleteNotificationType (do not use).
• Source subsystems (background tasks, notification mechanisms, scheduled operations) — create elements programmatically through NotificationAuthor.
• Input based on: not provided by typical scenarios and generally does not have practical meaning for a service object. Notifications are created by code, not by manual input based on documents.

7. Extension Points

• Classification through NotificationType — adding custom string types for grouping/filtering and various visual formatting in the interface.
• Programmatic creation of notifications — calling notification generation methods from your subsystems/background tasks (addressing by UserName, lifetime through RelevanceDate).
• Auto-cleanup of outdated records — scheduled task/processing that removes elements with expired RelevanceDate.
• Configuration extension (Extension): adding attributes/commands, subscribing to events BeforeWriting, refining the list form (conditional formatting, additional filters) without removing from support.
• Multi-tenancy: accounting for DataArea in any modifications to avoid disrupting notification separation between tenants.

When making modifications, do not use the deprecated attribute DeleteNotificationType — instead, use the string NotificationType.