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

ВАЖНО: RU-объект, наследие российской типовой ЗУП. Весь документ построен вокруг реквизитов Фонда социального страхования РФ (РегистрационныйНомерФСС, КодПодчиненностиФСС, ИНН, КПП, «прямые выплаты ФСС») — это механизм российского пилотного проекта «Прямые выплаты». В казахстанском учёте («Зарплата и управление персоналом для Казахстана 3.1») социальные выплаты идут через ГФСС/СО, ИПН/ОПВ/ВОСМС, и регистрационные номера ФСС/ИНН/КПП не применяются. Объект достался от российской базы и в практике РК не используется.

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

Документ «Опись заявлений сотрудников на выплату пособий» — сопроводительная опись, которой страхователь (организация) оформляет передачу в территориальный орган ФСС РФ пакета заявлений сотрудников на выплату пособий (механизм прямых выплат ФСС). Табличная часть Заявления собирает ссылки на документы ЗаявлениеСотрудникаНаВыплатуПособия с указанием состава приложенных документов и количества страниц. Документ не делает движений по регистрам (register_records пуст) — это чисто оформительский/передаточный документ со статусной моделью (СтатусДокумента). Пользователь — расчётчик зарплаты/бухгалтер по пособиям; периодичность — по мере передачи пакетов заявлений (нумерация сквозная, без периодичности). Расположение в меню по JSON-карте не определено (формы и команды отсутствуют). Для Казахстана — наследие типовой, в реальном документообороте РК не задействуется.

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

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

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

Все 17 реквизитов из metadata.attributes перечислены без пропусков.

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

ТЧ Заявления (синоним «Заявления»)

Основная ТЧ: перечень заявлений сотрудников, включённых в опись.

ТЧ ФизическиеЛица (синоним «Физические лица»)

Вспомогательная ТЧ — список физических лиц, чьи заявления входят в опись (используется для отбора/быстрого поиска по сотрудникам).

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

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

2.3 Формы

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

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

BSL-модули, формы и команды в карте отсутствуют — сценарии синтезированы из метаданных (реквизиты, ТЧ, статусная модель). Помни: для казахстанской базы это RU-наследие, сценарии носят справочный характер.

3.1 Сценарий: «Создание описи и включение заявлений (Create)»

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

3.2 Сценарий: «Указание уполномоченного представителя страхователя»

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

3.3 Сценарий: «Ведение статуса документооборота (Update)»

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

3.4 Сценарий: «Поиск описи по сотруднику (Read)»

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

3.5 Сценарий: «Корректировка состава пакета»

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

4. Per-field reference

Обработчики ПриИзменении в bsl_static отсутствуют (карта без BSL), влияние полей друг на друга по коду не задокументировано. Приоритет — обязательные и содержательные поля:

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

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

• Обработчики событий: (не определено) — bsl_static и bsl_summaries в карте пусты.
• Проводки: отсутствуют — metadata.register_records пуст, документ не формирует движений ни по одному регистру (оформительский документ).
• Валидации: из метаданных — только СтатусДокумента (ShowError); все остальные реквизиты DontCheck. ОбработкаПроверкиЗаполнения в карте не представлена.
• Зависимости от других модулей: (не определено) — по метаданным видна связь с документом ЗаявлениеСотрудникаНаВыплатуПособия (тип колонки ТЧ), перечислением СтатусыЗаявленийИРеестровНаВыплатуПособий и подсистемой «Дополнительные реквизиты и сведения».

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

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

(не определено) — metadata.based_on пуст: документ не вводится «на основании».

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

(не определено) — metadata.inverse_based_on пуст: на основании описи другие документы не вводятся.

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

(не определено) — metadata.register_records пуст: документ не делает движений по регистрам. Связи только ссылочные:

• Документ.ЗаявлениеСотрудникаНаВыплатуПособия — через колонку Заявление ТЧ Заявления (опись агрегирует заявления);
• Перечисление.СтатусыЗаявленийИРеестровНаВыплатуПособий — статусная модель (СтатусДокумента);
• справочники Организации, ФизическиеЛица, Должности, Пользователи, ПВХ ДополнительныеРеквизитыИСведения.

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

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