Документ «Запрос на информационное обслуживание страхователя»

Позволяет организации-страхователю сформировать обращение к органу ПФР (Пенсионный фонд России) с запросом на информационное обслуживание или сверку по состоянию на выбранную дату. Объект унаследован из российской типовой конфигурации и в казахстанском учёте практического применения не имеет.

ЗУП для Казахстана, ред. 3.1 · v3.1.2.24 · обновлено 2026-06

🎯 Что это и зачем

Документ предназначен для оформления запроса организации («От кого») к органу Пенсионного фонда России («Кому») на информационное обслуживание страхователя (ИОС): запрашивается услуга/сверка определённого вида (ВидУслуги) по состоянию на дату (НаДату), при необходимости — по конкретным застрахованным лицам.

⚠️ Наследие РФ-типовой — в Казахстане не применяется. Реквизит «Кому» имеет тип CatalogRef.ОрганыПФР — это справочник органов российского Пенсионного фонда. Терминология «страхователь / застрахованные лица / страховой номер» относится к российскому персонифицированному учёту. Для задач РК (сверка с ЕНПФ, Государственная корпорация ГФСС, соцплатежи, ФНО) используйте казахстанские объекты конфигурации, а не этот документ.

В составе ЗУП для Казахстана 3.1 это фактически «спящий» объект: в карте нет форм, команд интерфейса и BSL-модулей. Движений по регистрам документ не формирует — register_records пуст. Нумерация — строковая, до 11 символов, непериодическая (номера не обнуляются по периодам). При открытии 1С автоматически генерирует форму по метаданным.

🧭 Где найти в программе

Раздел «Отчётность» → пункт «Запрос на информационное обслуживание страхователя». В журнале документов создаём новый кнопкой «Создать».

📌 Заметка. В карте объекта отсутствуют команды интерфейса (commands: []) и формы (forms: []). Точное расположение в меню зависит от версии интерфейса и прав. Если пункт отсутствует в «Отчётности» — воспользуйтесь «Все функции» → «Документы» → «ЗапросНаИнформационноеОбслуживаниеСтрахователя».

👤 Часть 1. Для пользователя

Сценарии охватывают только реальный состав метаданных — без движений по регистрам и без казахстанских налоговых задач.

Урок 1. Запрос на сверку по организации в целом

Когда: организации-страхователю нужна услуга или сверка от органа ПФР по состоянию на дату, без указания конкретных лиц. RU-наследие

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

⚠️ Важно. Все четыре поля шапки — «Вид сверки», «На дату», «От кого», «Кому» — обязательны (fill_value_required = ShowError). При попытке записать документ с незаполненным полем платформа выдаст ошибку и запись не пройдёт. Поля не зависят друг от друга — обработчиков ПриИзменении нет, автоподстановки нет.

💡 Подсказка. После нажатия «Записать» движений по регистрам не будет — документ не проводится. Признак успеха: сохранённый документ с присвоенным номером.

Урок 2. Запрос по списку конкретных лиц

Когда: услуга/сверка запрашивается адресно — по конкретным застрахованным лицам. RU-наследие

Выполните шаги 1–6 из Урока 1 (заполните шапку документа).
В табличной части «Сведения о застрахованных лицах» (ЗастрахованныеЛица) нажмите «Добавить» — появится новая строка.
Для каждого лица заполните вручную: «Фамилия» (Фамилия), «Имя» (Имя), «Отчество» (Отчество), «Страховой номер» (СтраховойНомер) — строковые поля, ссылки на справочник сотрудников нет.
Повторите шаг 2–3 для каждого лица в списке.
Нажмите «Записать».

Скриншот: табличная часть «Сведения о застрахованных лицах»

Табличная часть ЗастрахованныеЛица: колонки Фамилия, Имя, Отчество, Страховой номер — всё вводится текстом.

⚠️ Важно. Табличная часть не ссылается на справочник Сотрудники или ФизическиеЛица — ФИО и страховой номер вводятся текстом вручную. Никаких автопроверок на корректность данных нет: Страховой номер — строка, не ИИН. В РК это поле соответствует российскому СНИЛС и к казахстанскому учёту не относится.

Урок 3. Исправление и повторный запрос

Когда: в сохранённом запросе обнаружена ошибка, или нужен ещё один запрос другого вида.

Исправление. Откройте ранее сохранённый документ. Исправьте нужные поля шапки (ВидУслуги, НаДату, Получатель) или строки табличной части. Нажмите «Записать» — данные перезапишутся. Никаких движений не создаётся.
Повторный запрос. Создайте новый документ по сценарию Урока 1, изменив ВидУслуги и/или НаДату. Нумерация сквозная — новому документу присвоится следующий по порядку номер.
При необходимости скопируйте существующий документ стандартными средствами платформы (команда «Скопировать» в форме списка), скорректируйте поля и запишите.

📌 Заметка. Нумерация документа — непериодическая (Nonperiodical): номера не обнуляются при смене года. Поиск ранее созданных запросов — по номеру (строка до 11 символов) или дате документа в журнале. Форм и команд интерфейса в метаданных нет — журнал открывается через «Все функции» или, если настроено, через раздел «Отчётность».

🛠 Часть 2. Для программиста

Состав объекта по метаданным. Конфигурация ЗУП для Казахстана 3.1, релиз 3.1.2.24.

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

Тип объекта — документ. Нумерация: тип номера String, длина 11, периодичность Nonperiodical. Форм нет (forms: []), команд нет (commands: []) — форма генерируется платформой автоматически по метаданным. BSL-модули в выгрузке отсутствуют (bsl_static: [], bsl_summaries: []).

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

Имя	Синоним (UI)	Тип	Обяз.	Назначение
`ВидУслуги`	Вид сверки	`EnumRef.ВидыУслугПриИОС`	Да (ShowError)	Вид запрашиваемой услуги/сверки при ИОС; выбирается из перечисления `ВидыУслугПриИОС`
`НаДату`	На дату	`xs:dateTime`	Да (ShowError)	Дата, по состоянию на которую запрашиваются сведения/сверка
`Организация`	От кого	`CatalogRef.Организации`	Да (ShowError)	Организация-страхователь, от имени которой формируется запрос
`Получатель`	Кому	`CatalogRef.ОрганыПФР`	Да (ShowError)	Орган ПФР — адресат запроса. RU-специфика: справочник органов Пенсионного фонда России.
`Комментарий`	Комментарий	`xs:string`	Нет (DontCheck)	Произвольный комментарий пользователя; ни на что не влияет

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

ЗастрахованныеЛица — синоним «Сведения о застрахованных лицах». Перечень конкретных застрахованных лиц, по которым запрашивается обслуживание/сверка; персональные данные вводятся строками, без ссылки на справочник сотрудников.

Имя	Синоним	Тип	Назначение
`Фамилия`	Фамилия застрахованного лица	`xs:string`	Фамилия застрахованного лица; вводится текстом
`Имя`	Имя застрахованного лица	`xs:string`	Имя застрахованного лица; вводится текстом
`Отчество`	Отчество застрахованного лица	`xs:string`	Отчество застрахованного лица; вводится текстом
`СтраховойНомер`	Страховой номер застрахованного лица	`xs:string`	Страховой номер (СНИЛС) — RU-персучёт; к казахстанскому учёту не относится

📌 Наследие РФ-типовой. Справочник ОрганыПФР, перечисление ВидыУслугПриИОС и колонка СтраховойНомер относятся к российскому персонифицированному учёту ПФР. В казахстанском законодательстве аналогов не имеют. Для задач РК: соцплатежи и пенсионные взносы — через ГФСС и Госкорпорацию; пенсионные взносы — в ЕНПФ; отчётность — ФНО 200/210/910 и т.д.

Движения по регистрам

Документ не формирует движений по регистрам: register_records пуст. После проведения/записи никаких накопительных, расчётных или регистров сведений не наполняется. Проводка в учёте не создаётся.

📌 Документ является «спящим». В карте объекта нет ни форм, ни команд, ни BSL-модулей, ни регистров-приёмников. Это рудимент российской типовой конфигурации, оставленный в составе ЗУП для Казахстана без адаптации к казахстанскому законодательству.

Как формируется проведение — реальный код (3.1.2.24)

⚠️ Важно об источнике. В использованной XML-выгрузке конфигурации модули объекта отсутствуют (секции bsl_static / bsl_summaries пусты). Дословный текст процедур ОбработкаПроведения / ОбработкаПроверкиЗаполнения привести нельзя. Ниже — реконструкция по метаданным: это не цитата исходного кода, а схема, отражающая реальный состав реквизитов и декларативную обязательность.

Платформенная проверка заполнения (из fill_value_required: ShowError) — срабатывает автоматически перед записью:

// Реконструкция по metadata: 4 реквизита шапки с обязательной проверкой (ShowError).
// Платформа проверяет их автоматически; имена — дословно из метаданных.
ПроверяемыеРеквизиты =
    "ВидУслуги, НаДату, Организация, Получатель";
// Собственной ОбработкаПроверкиЗаполнения в карте нет (bsl_static пуст).
// Комментарий — DontCheck, не проверяется.
// Колонки ТЧ ЗастрахованныеЛица обязательности не имеют.

Схема проведения (реконструкция по отсутствию register_records):

// Реконструкция: register_records = [] — движений нет.
// Документ ЗАПИСЫВАЕТСЯ, но НЕ ПРОВОДИТСЯ в смысле регистровых движений.
Процедура ОбработкаПроведения(Отказ, РежимПроведения)

    // Никаких записей в регистры: документу присваивается номер (String, 11 знаков),
    // данные шапки и ТЧ ЗастрахованныеЛица сохраняются в информационную базу.
    // Движений по регистрам расчёта зарплаты, налоговых регистров
    // или регистров взаиморасчётов — нет.

КонецПроцедуры

Зависимости

Зависимость	Что используется
Справочники	`Организации` (реквизит `Организация`), `ОрганыПФР` (реквизит `Получатель`) — RU
Перечисления	`ВидыУслугПриИОС` (реквизит `ВидУслуги`) — RU
Документы-основания	Нет (`based_on: []`) — документ не вводится на основании других объектов
Порождает документы	Нет (`inverse_based_on: []`) — на основании этого ничего не создаётся
Регистры-приёмники	Нет (`register_records: []`) — движений не делает

🔗 Связанные разделы

Регламентированный отчёт — раздел «Отчётность»: казахстанские формы ФНО 200/210/910 и прочие регламентированные отчёты.
Исполнительный лист — удержания из заработной платы сотрудников.