Документ «Заявление на формирование справки о расчетах с СФР (бывш. ФСС)»

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

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

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

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

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

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

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

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

Табличных частей нет (tabular_sections: []). Документ состоит только из шапки.

2.3 Формы

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

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

Формы, команды и BSL-модули в карте отсутствуют, поэтому сценарии синтезированы только из состава реквизитов; конкретные кнопки/команды не определены.

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

• Когда применяется: организации (РФ-контур) нужна официальная справка фонда о состоянии расчетов по взносам на определённую дату.
• Шаги пользователя: 1. Создать новый документ «Заявление на формирование справки о расчетах с СФР (бывш. ФСС)». 2. Указать Организация (обязательно — без неё документ не запишется с проверкой заполнения). 3. Установить флаг Страхователь_ЮридическоеЛицо = Истина. 4. Заполнить блок ЮЛ: СтраховательЮЛ_НаимОрг, СтраховательЮЛ_ИНН, СтраховательЮЛ_КПП, а также РегистрационныйНомерФСС и КодПодчиненностиФСС. 5. Указать ДатаЗадолженности — дату, на которую запрашиваются расчеты. 6. Записать документ.
• На что обратить внимание: блоки ЮЛ/ФЛ взаимоисключающие по смыслу флага Страхователь_ЮридическоеЛицо.
• Какие проверки сработают: стандартная проверка заполнения для Организация (fill_value_required = ShowError); прочие реквизиты не проверяются (DontCheck).
• После «Записать»: документ сохранён; проведения/движений по регистрам у объекта нет (register_records: []).

3.2 Сценарий: «Создание заявления страхователем-физлицом (ИП)»

• Когда применяется: страхователь — физическое лицо.
• Шаги пользователя: 1. Создать документ, указать Организация. 2. Снять/оставить флаг Страхователь_ЮридическоеЛицо = Ложь. 3. Заполнить СтраховательФЛ_Фамилия, СтраховательФЛ_Имя, СтраховательФЛ_Отчество, СтраховательФЛ_ИНН. 4. Заполнить данные удостоверяющего документа: СтраховательФЛ_ВидДокумента, СтраховательФЛ_СерияДокумента, СтраховательФЛ_НомерДокумента, СтраховательФЛ_ДатаВыдачиДокумента. 5. Указать ДатаЗадолженности, записать.
• Проверки: только обязательность Организация.
• После «Записать»: как в 3.1 — только запись, без движений.

3.3 Сценарий: «Отслеживание жизненного цикла обмена с фондом»

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

3.4 Сценарий: «Получение справки и работа с файлом ответа»

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

3.5 Сценарий: «Разбор отказа / ошибок контроля»

• Когда применяется: фонд вернул ошибки форматно-логического контроля.
• Шаги пользователя: 1. Открыть документ, прочитать поле ОшибкиКонтроля (текст ошибок). 2. Исправить данные страхователя (ИНН/КПП/рег.номер/код подчиненности — типовые причины отказов по смыслу полей). 3. Зафиксировать пояснения в Комментарий. 4. Сформировать и отправить заявление повторно (механизм отправки в карте не определён — команд нет).
• Результат: скорректированное заявление для повторной отправки.

4. Per-field reference

Обработчики ПриИзменении в карте отсутствуют (bsl_static: []), поэтому влияние полей друг на друга описано по семантике метаданных; программная валидация, кроме стандартной обязательности, не определена.

• Организация (CatalogRef.Организации): организация-страхователь; обязателен (ShowError — единственное поле со стандартной проверкой заполнения); от неё по смыслу зависят данные блока страхователя (наименование, ИНН/КПП, регистрационные данные ФСС). Типичное значение — основная организация базы.
• Страхователь_ЮридическоеЛицо (boolean): ключевой переключатель типа страхователя; определяет, какой блок полей актуален: Истина → СтраховательЮЛ_*, Ложь → СтраховательФЛ_*. Программная логика переключения видимости в карте не определена (форм нет).
• ДатаЗадолженности (dateTime): дата, на которую запрашивается состояние расчетов; содержательный параметр запроса.
• РегистрационныйНомерФСС (string): регистрационный номер страхователя в ФСС; идентифицирует страхователя в фонде.
• КодПодчиненностиФСС (string): код подчиненности — определяет территориальный орган ФСС.
• СтраховательЮЛ_НаимОрг / СтраховательЮЛ_ИНН / СтраховательЮЛ_КПП (string): реквизиты страхователя-юрлица для заявления; российские ИНН/КПП (RU-наследие).
• СтраховательФЛ_Фамилия / СтраховательФЛ_Имя / СтраховательФЛ_Отчество / СтраховательФЛ_ИНН (string): ФИО и ИНН страхователя-физлица.
• СтраховательФЛ_ВидДокумента / СтраховательФЛ_СерияДокумента / СтраховательФЛ_НомерДокумента (string) и СтраховательФЛ_ДатаВыдачиДокумента (dateTime): удостоверяющий документ физлица.
• ДатаОтправкиВФСС / ДатаДоставкиВФСС / ДатаПолученияСправки (dateTime): технологические отметки этапов обмена; заполняются по ходу цикла «отправлено → доставлено → получена справка».
• ИдентификаторСообщения (string): идентификатор, присвоенный ФСС; служит для трекинга запроса.
• Статус (string): строковый статус заявления; перечень значений в карте не определён.
• ВходящийФайл (CatalogRef.ЗаявлениеНаФормированиеСправкиОРасчетахПрисоединенныеФайлы): ссылка на полученный файл в выделенном справочнике присоединённых файлов.
• ИмяФайлаСправки / ИмяФайлаСправкиПредставление (string): техническое имя файла справки и его представление для пользователя.
• ОшибкиКонтроля (string): накопленный текст ошибок контроля от фонда; поле для диагностики отказов.
• Комментарий (string): свободный комментарий.

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

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

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

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

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

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

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

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

(не определено) — register_records: [], движений нет.

Косвенные связи по типам реквизитов: справочник Организации (реквизит Организация), справочник ЗаявлениеНаФормированиеСправкиОРасчетахПрисоединенныеФайлы (реквизит ВходящийФайл).

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

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