---
title: "User Notifications Directory (Catalogs.UserNotifications)"
country: KZ
lang: en
author: Сапа Т.И. (https://buhgpt.kz/authors/sapa-ti)
date: 2026-09-07
canonical: https://buhgpt.kz/suraqtar/spravochnik-opoveshcheniyapolzovateley-catalogs-opoveshch-en
source: BuhGPT
---

# User Notifications Directory (Catalogs.UserNotifications)

> **TL;DR:** 1. Identification Parameter Value Object Type Catalog Name UserNotifications Full Path Catalog.UserNotifications / Catalogs.UserNotifications Synonym User notifications (no separate synonym specified) Configuration Accounting for Kazakhstan, edition 3.0.74.2 Category Service (

---

1. Identification

Parameter
Value

Object Type
Catalog

Name
UserNotifications

Full Path
Catalog.UserNotifications / Catalogs.UserNotifications

Synonym
User notifications (no separate synonym specified)

Configuration
Accounting for Kazakhstan, edition 3.0.74.2

Category
Service (technological) object

Conducted
No (the catalog is not a document and does not generate movements)

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

Name
Type
Mandatory
Purpose

DataArea
Number (decimal)
Optional (DontCheck)
Identifier of the data area in the separation model. Distinguishes notifications between organizations/tenants in a multi-tenant (cloud, SaaS) configuration.

NotificationDate
Date/Time (dateTime)
Optional (DontCheck)
Date and time of creation/sending of the notification. Used for sorting, chronological display, and determining the "freshness" of the notification.

RelevanceDate
Date/Time (dateTime)
Optional (DontCheck)
Date until which the notification remains relevant. After its expiration, the notification may be hidden or marked as outdated; used for automatic cleanup.

DeleteNotificationType
EnumRef.DeleteNotificationTypes
Optional (DontCheck)
Deprecated attribute (prefix "Delete", synonym "Not used"). Previously classified notifications through enumeration. Retained for compatibility with old data. Do not use in new code.

UserName
String (string)
Optional (DontCheck)
Name of the recipient user. Addresses the notification to a specific user, displayed in the list of notifications.

UserSessionNumber
Number (decimal)
Optional (DontCheck)
Number of the user session in which the notification was created/should be displayed. Links the notification to a specific session.

MessageText
String (string)
Optional (DontCheck)
Main text of the notification: event description, action instructions, other significant information.

NotificationAuthor
String (string)
Optional (DontCheck)
Name of the user or subsystem that created the notification. Identifies the source (another user, system, background task).

NotificationType
String (string)
Optional (DontCheck)
Current classification of the type of notification (as a string). Replaces the deprecated DeleteNotificationType. Serves for grouping, filtering, and various visual representation.

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):

Form
Purpose

ListForm
View the list of notifications: filtering by user, type, relevance date; service control of records. Main entry via link e1cib/list/Catalog.UserNotifications.

ElementForm
View/edit a single notification (text, author, dates, type). Used primarily by the administrator/for debugging.

SelectionForm
Select a notification when picking from other objects/mechanisms.

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.

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