Справочник «ОповещенияПользователей» (Catalogs.ОповещенияПользователей)

1. Идентификация

Назначение. Справочник хранит системные оповещения, отправляемые пользователям информационной базы. Его наполняют внутренние механизмы конфигурации для регистрации уведомлений о событиях, требующих внимания пользователя (например, необходимость утверждения документа, получение важного сообщения, истечение срока актуальности данных). Объект работает преимущественно автоматически: элементы создаются кодом при наступлении определённых условий, а пользователь видит их через специализированные интерфейсы уведомлений, а не через прямое открытие справочника. В составе конфигурации это служебная сущность, обеспечивающая коммуникацию «система → пользователь», в том числе в мультиарендных (SaaS) сценариях за счёт разделения по областям данных.

Оговорка по контексту: справочник не связан с учётными расчётами (НДС, ИПН, ОПВ и т. п.) и не работает со счетами плана счетов РК. Поэтому налоговые ставки и суммы к нему неприменимы — числовые нормы Казахстана 2026 приведены далее только там, где это уместно (см. раздел 5).

Где найти в 1С:

• Навигационная ссылка: e1cib/list/Справочник.ОповещенияПользователей
• Интерфейсно: раздел «Технология сервиса» → «Оповещения пользователей».

2. Реквизиты и табличные части

2.1 Реквизиты шапки

Стандартные реквизиты справочника (Ссылка, Код, Наименование, ПометкаУдаления, Предопределённый) присутствуют по умолчанию. Иерархия для служебного справочника такого рода, как правило, не используется.

2.2 Табличные части

По данным evidence значимые прикладные табличные части у справочника не описаны (раздел в источнике не заполнен). Вся полезная информация оповещения хранится в реквизитах шапки — что типично для служебного объекта такого назначения. Требует проверки в конкретной поставке: наличие/состав табличных частей версионно-специфично.

3. Формы

Специализированные формы в evidence не приложены. Для справочника этого вида в типовой конфигурации предусмотрен стандартный набор форм (часть может генерироваться автоматически):

Так как объект служебный, штатный пользователь взаимодействует с оповещениями через механизмы уведомлений интерфейса, а не через эти формы напрямую.

4. Ключевые процедуры модулей

BSL-evidence (модуль объекта / модуль менеджера / модули форм) не приложен, поэтому ниже — типовой для данного вида объекта состав обработчиков. Конкретные строки:путь требуют проверки по исходному коду поставки.

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

• ПередЗаписью(Отказ) — служебные проверки/заполнение перед записью (например, установка ДатаОповещения, если не задана).
• ПриКопировании(ОбъектКопирования) — сброс сеансо-зависимых реквизитов (НомерСеансаПользователя, даты) при копировании.
• ОбработкаЗаполнения(ДанныеЗаполнения, ТекстЗаполнения, СтандартнаяОбработка) — заполнение полей при программном создании оповещения.

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

• Экспортные функции формирования и получения оповещений (создание элемента по параметрам «пользователь / текст / вид / срок актуальности», выборка актуальных оповещений для сеанса, очистка устаревших по ДатаАктуальности).
• ОбработкаПолученияПредставления / формирование представления по ТекстСообщения/ВидОповещения.

Модуль формы списка/элемента:

• ПриСозданииНаСервере — начальная настройка отбора (по текущему пользователю, по актуальности), условное оформление устаревших строк.
• Обработчики команд служебного обслуживания (пометка прочитанным, очистка устаревших).

Требует проверки: точная сигнатура и наличие экспортных методов менеджера — они версионно-специфичны.

5. Проведение и движения

Справочник не проводится и не формирует движений по регистрам бухгалтерии, накопления или сведений. Он является хранилищем данных: запись элемента лишь сохраняет карточку оповещения.

Как следствие:

• проводки по плану счетов РК не формируются;
• счета типового плана счетов Казахстана (например, 1210 «Краткосрочная дебиторская задолженность покупателей», 1030 «Деньги на текущих счетах», 1330 «Товары», 3310 «Кредиторская задолженность поставщикам», 3130 «НДС к уплате», 6010 «Доход от реализации», 7010 «Себестоимость реализации») в контексте этого объекта не задействуются;
• налоговые расчёты Казахстана 2026 (НДС 16 %; ИПН 10 % до 8 500 МРП годового дохода и 15 % сверх; базовый вычет по ИПН 30 МРП/мес., не более 360 МРП/год; ОПВ 10 % с потолком базы 50 МЗП; ОПВР 3,5 %; ВОСМС 2 %; ОСМС 3 %; СО 5 %; соцналог 6 %; МРП = 4 325 ₸; МЗП = 85 000 ₸; валюта — тенге ₸) к данному справочнику не применяются.

Эти нормы приведены для полноты картины по конфигурации; сам объект «ОповещенияПользователей» в учётных и налоговых движениях не участвует.

6. Связанные объекты и ввод на основании

• Модель разделения данных (SaaS/облако): реквизит ОбластьДанных связывает элементы с областью данных арендатора; используется механизмами разделения конфигурации.
• Пользователи/сеансы: привязка через НаименованиеПользователя и НомерСеансаПользователя к пользователю и его сессии.
• Устаревшее перечисление УдалитьВидыОповещенийПользователей — историческая связь через УдалитьВидОповещения (не использовать).
• Подсистемы-источники (фоновые задания, механизмы уведомлений, регламентные операции) — создают элементы программно через АвторОповещения.
• Ввод на основании: типовыми сценариями не предусмотрен и, как правило, не имеет практического смысла для служебного объекта. Оповещения создаются кодом, а не ручным вводом на основании документов.

7. Точки расширения

• Классификация через ВидОповещения — добавление собственных строковых видов для группировки/фильтрации и различного визуального оформления в интерфейсе.
• Программное создание оповещений — вызов методов формирования оповещений из своих подсистем/фоновых заданий (адресация по НаименованиеПользователя, срок жизни через ДатаАктуальности).
• Автоочистка устаревших записей — регламентное задание/обработка, удаляющая элементы с истёкшей ДатаАктуальности.
• Расширение конфигурации (Extension): добавление реквизитов/команд, подписки на события ПередЗаписью, доработка формы списка (условное оформление, дополнительные отборы) без снятия с поддержки.
• Мультиарендность: учёт ОбластьДанных при любой доработке, чтобы не нарушить разграничение оповещений между арендаторами.

При доработках не используйте устаревший реквизит УдалитьВидОповещения — вместо него применяйте строковый ВидОповещения.