Документ «Заявления о предоставлении сведений о трудовой деятельности»

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

Примечание метаданных: comment = «АПК:93 Представления объекта и списка совпадают с синонимом».

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

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

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

Нумерация: тип номера — String, длина 11, периодичность — Nonperiodical.

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

ВСЕ реквизиты из metadata.attributes (7 шт.), имена дословно:

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

Сотрудники («Сотрудники») — основная содержательная ТЧ: кто и какое заявление подал.

ФизическиеЛица («Физические лица») — вспомогательный список физлиц; назначение по карте не определено (формы/BSL отсутствуют).

ДополнительныеРеквизиты («Дополнительные реквизиты») — стандартная ТЧ механизма доп. реквизитов БСП.

2.3 Формы

(не определено) — metadata.forms и forms в карте пусты; ключевую форму указать нельзя.

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

Команды и BSL в карте отсутствуют; сценарии синтезированы из метаданных и регистра движения. Все сценарии — РФ-контур.

3.1 Сценарий: «Регистрация поступивших заявлений работников (Create)»

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

3.2 Сценарий: «Просмотр зарегистрированных заявлений (Read)»

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

3.3 Сценарий: «Исправление вида заявления / состава сотрудников (Update)»

• Когда применяется: ошиблись в виде заявления или в составе работников.
• Шаги пользователя: 1. Открыть проведённый документ. 2. Исправить ВидЗаявления в строке сотрудника, добавить/удалить строки ТЧ Сотрудники. 3. Перепровести документ.
• На что обратить внимание: документ — регистратор записей регистра сведений; перепроведение обновляет записи ЗаявленияОВеденииТрудовыхКнижек.
• Проверки: обязательность Организация, Руководитель, ДолжностьРуководителя.
• Результат: регистр отражает исправленные сведения.

3.4 Сценарий: «Смена подписанта работодателя»

• Когда применяется: в печатной/учётной части нужно отразить другого руководителя (например, действующего по доверенности).
• Шаги пользователя: 1. В документе изменить Руководитель (CatalogRef.ФизическиеЛица) и ДолжностьРуководителя (CatalogRef.Должности). 2. Указать ОснованиеПодписиРуководителя (тип в карте не определён — составной). 3. Записать/перепровести.
• Проверки: обязательность всех трёх полей подписанта, кроме основания подписи.
• Результат: документ хранит актуального подписанта; печатные формы в карте не определены.

3.5 Сценарий: «Аннулирование зарегистрированных заявлений»

• Когда применяется: документ создан ошибочно.
• Шаги пользователя: 1. Отменить проведение документа (стандартная команда платформы; собственных команд у объекта нет). 2. При необходимости пометить на удаление.
• На что обратить внимание: устаревший флаг УдалитьЗаявлениеОтозвано в ТЧ не использовать — он помечен «(не используется)»; отзыв оформляется средствами актуального механизма (в карте не определено, каким).
• Результат: записи регистра сведений ЗаявленияОВеденииТрудовыхКнижек по регистратору удаляются.

4. Per-field reference

Обработчиков ПриИзменении в карте нет (bsl_static: []); влияние и валидация описаны по метаданным.

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

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

• Обработчики событий: (не определено) — bsl_static и bsl_summaries пусты.
• Проводки: бухгалтерских проводок нет; при проведении документ пишет в регистр сведений ЗаявленияОВеденииТрудовыхКнижек (см. 6.3); логика ОбработкаПроведения в карте не представлена.
• Валидации: стандартная проверка заполнения Организация, Руководитель, ДолжностьРуководителя (ShowError); программная ОбработкаПроверкиЗаполнения в карте отсутствует.
• Зависимости от других модулей: (не определено) по BSL; по типам реквизитов — справочники Организации, ФизическиеЛица, Должности, Пользователи, перечисление ВидыЗаявленийОПредоставленииСведенийОТрудовойДеятельности, ПВХ ДополнительныеРеквизитыИСведения (подсистема «Свойства» БСП).

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

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

(не определено) — based_on: [], ввод на основании не предусмотрен.

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

(не определено) — inverse_based_on: [].

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

Из metadata.register_records: - InformationRegister.ЗаявленияОВеденииТрудовыхКнижек — регистр сведений, в который документ пишет при проведении: хранит по работникам факт и вид поданного заявления о ведении трудовой книжки / предоставлении сведений о трудовой деятельности. Это единственное движение документа.

Косвенные ссылочные связи по типам: Организации, ФизическиеЛица (и в шапке, и в двух ТЧ), Должности, Пользователи, Сотрудники (только в устаревшей колонке УдалитьСотрудник).

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

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