Документ «Сведения о трудовой деятельности работника, СТД-Р»

⚠️ RU-объект, наследие типовой российской ЗУП 3.1. СТД-Р — российская форма «Сведения о трудовой деятельности, предоставляемые работнику работодателем» (механизм электронных трудовых книжек РФ): обязательный реквизит СтраховойНомерПФР (СНИЛС), вид мероприятий из EnumRef.ВидыМероприятийТрудовойДеятельности. В конфигурации «Зарплата и управление персоналом для Казахстана 3.1» объект достался от типовой и к кадровому учёту РК отношения не имеет.

1. Назначение и место в учёте

Документ формирует для конкретного работника выписку СТД-Р — сведения о его трудовой деятельности у данного работодателя (российский механизм электронных трудовых книжек). Используется кадровой службой по запросу работника: при выдаче сведений по заявлению или при увольнении. Документ выписывается по одному физическому лицу (шапка содержит персональные данные и СНИЛС) и подписывается руководителем кадровой службы. Номер строковый длиной 11, нумерация непериодическая. Расположение в меню и формы по данным JSON-карты не определены (списки форм и команд пусты); в ЗУП КЗ 3.1 объект — наследие российской типовой.

2. Структура объекта

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

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

ТЧ Мероприятия («Мероприятия»)

Кадровые мероприятия трудовой деятельности, попадающие в выписку. Важно: 19 из 22 колонок помечены «(не используется)» (префикс Удалить*) — фактически рабочих колонок три: ИдМероприятия, Отменено, Организация. Состав колонок указывает, что детальные данные мероприятий в актуальной версии хранятся вне ТЧ, а строка ссылается на мероприятие по UUID (механизм в карте не зафиксирован).

ТЧ ДополнительныеРеквизиты («Дополнительные реквизиты»)

Стандартный механизм доп. реквизитов БСП.

2.3 Формы

В JSON-карте список форм пуст (forms: []) — (не определено). Ключевая форма по данным карты не определяется.

3. Сценарии работы

BSL-модулей, форм и команд в карте нет — сценарии синтезированы из метаданных и связи based_on; автозаполнение и кнопки данными не подтверждены.

3.1 Сценарий: «Создание СТД-Р на основании сотрудника» (основной путь)

• Когда применяется: работник запросил сведения о трудовой деятельности (или увольняется).
• Шаги пользователя: 1. Открыть справочник Сотрудники, выбрать работника. 2. Выполнить «Создать на основании» → «Сведения о трудовой деятельности работника, СТД-Р» (связь based_on: Catalog.Сотрудники). 3. Проверить заполнение шапки: Организация, ФизическоеЛицо, Фамилия, Имя, Отчество, ДатаРождения, СтраховойНомерПФР (механизм автозаполнения в карте не зафиксирован — проверить вручную). 4. Указать РуководительКадровойСлужбы и ДолжностьРуководителяКадровойСлужбы. 5. Записать документ.
• На что обратить внимание: восемь реквизитов шапки обязательны (см. 2.1); Отчество — единственное персональное поле без проверки.
• Какие проверки сработают: стандартная проверка заполнения по fill_value_required (ShowError) для восьми обязательных реквизитов; других валидаций в карте нет.
• После «Записать»: документ сохранится; движений по регистрам нет (register_records пуст).

3.2 Сценарий: «Создание документа вручную»

• Когда применяется: если документ создаётся из списка документов, а не от сотрудника.
• Шаги пользователя: 1. Создать новый документ «Сведения о трудовой деятельности работника, СТД-Р». 2. Выбрать Организация и ФизическоеЛицо. 3. Заполнить персональные данные (Фамилия, Имя, Отчество, ДатаРождения, СтраховойНомерПФР) — они хранятся в документе строками/датой, а не подтягиваются динамически при печати. 4. Заполнить подписанта (РуководительКадровойСлужбы, ДолжностьРуководителяКадровойСлужбы, при необходимости ОснованиеПодписиРуководителяКадровойСлужбы). 5. Записать.
• Проверки: те же восемь ShowError-реквизитов.
• После «Записать»: сохранение без движений.

3.3 Сценарий: «Фиксация заявления работника»

• Когда применяется: работник подал заявление о продолжении ведения бумажной трудовой книжки либо о предоставлении сведений о трудовой деятельности (RU-механизм ЭТК).
• Шаги пользователя: 1. В документе заполнить ЗаявлениеОПродолженииДата — если заявление о продолжении ведения трудовой книжки. 2. Либо ЗаявлениеОПредоставленииДата — если заявление о предоставлении сведений. 3. Записать.
• На что обратить внимание: оба поля необязательны (DontCheck); заполняется то, которое соответствует типу заявления.
• Проверки: специальных нет — (не определено).

3.4 Сценарий: «Просмотр/корректировка мероприятий выписки»

• Когда применяется: проверка состава кадровых мероприятий, попавших в СТД-Р.
• Шаги пользователя: 1. Открыть документ, перейти в ТЧ Мероприятия. 2. Анализировать строки по ИдМероприятия (UUID), флагу Отменено и колонке Организация — остальные колонки устарели и не используются. 3. При необходимости пометить мероприятие как отменённое (Отменено = Истина). 4. Записать.
• На что обратить внимание: НЕ заполнять Удалить*-колонки — они выведены из использования; источник наполнения ТЧ (автозаполнение по учётным данным) в карте не зафиксирован.
• Проверки: (не определено).

3.5 Сценарий: «Повторная выдача сведений»

• Когда применяется: работник повторно запросил СТД-Р (например, за новый период).
• Шаги пользователя: 1. Найти прежний документ по работнику в списке (отбор по ФизическоеЛицо/Организация). 2. Создать новый документ (нумерация непериодическая, строковый номер длиной 11) — либо скопированием, либо снова «на основании» сотрудника. 3. Актуализировать даты заявлений и состав мероприятий, записать.
• Проверки: обязательные реквизиты шапки.

4. Per-field reference

Обработчиков ПриИзменении в карте нет (bsl_static пуст) — взаимовлияние полей не зафиксировано.

• Организация (CatalogRef.Организации): работодатель; обязателен (ShowError).
• ФизическоеЛицо (CatalogRef.ФизическиеЛица): работник-получатель сведений; обязателен (ShowError); ключевое поле документа.
• Фамилия / Имя (Строка): персональные данные, зафиксированные в документе; обязательны (ShowError).
• Отчество (Строка): необязательно (DontCheck) — у работника может не быть отчества.
• ДатаРождения (ДатаВремя): обязательна (ShowError).
• СтраховойНомерПФР (Строка): СНИЛС; обязателен (ShowError); чисто российский идентификатор — в РК аналога не имеет (наследие типовой).
• РуководительКадровойСлужбы (CatalogRef.ФизическиеЛица): подписант выписки; обязателен (ShowError).
• ДолжностьРуководителяКадровойСлужбы (CatalogRef.Должности): должность подписанта; обязательна (ShowError).
• ОснованиеПодписиРуководителяКадровойСлужбы (тип не определён в карте): основание полномочий подписанта; необязателен.
• ЗаявлениеОПродолженииДата / ЗаявлениеОПредоставленииДата (ДатаВремя): даты заявлений работника по режиму ЭТК; необязательны; заполняется одно из двух по ситуации.
• УдалитьСотрудник (CatalogRef.Сотрудники): устаревший реквизит «(не используется) Сотрудник» — не заполнять; актуальная привязка идёт через ФизическоеЛицо.
• Ответственный (CatalogRef.Пользователи), Комментарий (Строка): служебные, необязательны.
• Мероприятия.ИдМероприятия (UUID): идентификатор кадрового мероприятия — единственный содержательный ключ строки ТЧ.
• Мероприятия.Отменено (Булево): пометка отмены мероприятия в выписке.

5. Бизнес-логика

• Обработчики событий: (не определено) — bsl_static: [], bsl_summaries: [].
• Проводки/ОбработкаПроведения: (не определено); register_records пуст — движений нет.
• Валидации: только стандартная проверка обязательности восьми реквизитов шапки с ShowError (Организация, ФизическоеЛицо, Фамилия, Имя, ДатаРождения, СтраховойНомерПФР, РуководительКадровойСлужбы, ДолжностьРуководителяКадровойСлужбы); ОбработкаПроверкиЗаполнения в карте не зафиксирована.
• Зависимости от других модулей: (не определено).

6. Связи с другими объектами

6.1 Документы-основания

based_on: Catalog.Сотрудники — документ вводится «на основании» элемента справочника Сотрудники; это основной способ создания: выбрать сотрудника и создать СТД-Р по нему.

6.2 Кто создаётся на основании этого

inverse_based_on пуст — на основании СТД-Р ничего не создаётся.

6.3 Регистры движения

register_records пуст — документ не формирует движений.

Косвенные ссылочные связи через реквизиты: Справочник.Организации, Справочник.Сотрудники, Справочник.ФизическиеЛица, Справочник.Должности, Справочник.Пользователи, Справочник.ПодразделенияОрганизаций (устар. колонка), Справочник.ТрудовыеФункции (устар. колонка), Перечисление.ВидыМероприятийТрудовойДеятельности (устар. колонка), ПланВидовХарактеристик.ДополнительныеРеквизитыИСведения.

7. Заметки для ИИ-агента

1. Это RU-объект (СТД-Р, электронные трудовые книжки РФ). В ЗУП КЗ 3.1 — наследие типовой; для кадровых задач Казахстана этот документ не предлагать (СНИЛС в РК отсутствует).
2. Создавайте документ «на основании» элемента справочника Сотрудники — единственная связь based_on в метаданных; после создания всё равно проверяйте восемь обязательных полей шапки.
3. Перед записью должны быть заполнены: Организация, ФизическоеЛицо, Фамилия, Имя, ДатаРождения, СтраховойНомерПФР, РуководительКадровойСлужбы, ДолжностьРуководителяКадровойСлужбы — все с ShowError; пропуск любого валит запись.
4. Игнорируйте все реквизиты/колонки с префиксом Удалить* (включая реквизит шапки УдалитьСотрудник и 19 колонок ТЧ Мероприятия) — они помечены «(не используется)».
5. В ТЧ Мероприятия рабочие колонки только ИдМероприятия (UUID), Отменено, Организация — содержимое мероприятий по UUID хранится вне документа; не пытайтесь вписывать детали мероприятия в устаревшие колонки.
6. Документ не проводится по регистрам (register_records пуст) — критерий успеха операции: документ записан без ошибок проверки заполнения.
7. Форм и команд в карте нет — селекторы UI строить по дословным именам метаданных из раздела 2.