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

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

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

Документ «Уведомление о прекращении полномочий представителя» отзывает (прекращает) полномочия уполномоченного представителя страхователя, ранее заявленные в ПФР документом «Уведомление о предоставлении полномочий представителю» (УПУП) — связь задана реквизитом ДокументОснование типа cfg:DocumentRef.УведомлениеОПредоставленииПолномочийПредставителю. Используется при смене или отзыве доверенности на представителя, который сдавал отчётность/взаимодействовал с органом ПФР от имени организации. Документ формирует файл выгрузки для фонда (ИмяФайлаВыгрузки, ФайлВыгрузки) и фиксирует даты отзыва и отправки. Движений по регистрам не делает (register_records пуст) — это документ электронного документооборота с фондом, а не учётный. Частота применения — эпизодическая (по событию отзыва доверенности); место в меню по выгрузке не определено (commands/forms пусты).

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

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

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

ВСЕ реквизиты из metadata.attributes. Примечательно: ни один реквизит не обязателен на уровне метаданных — у всех fill_value_required = DontCheck; контроль заполнения, если есть, реализуется кодом (в выгрузке BSL отсутствует).

Итого 13 реквизитов шапки, обязательных по метаданным — 0.

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

Во всех трёх ТЧ есть колонка Владелец типа cfg:EnumRef.СубъектыДоверенностиСтрахователя — она указывает, к какому субъекту доверенности (страхователь или представитель) относится строка; данные обоих субъектов хранятся в одних и тех же ТЧ и различаются значением «Владелец».

ФИО («ФИО») — ФИО и должности подписантов/контактных лиц субъектов доверенности.

КонтактнаяИнформация («Контактная информация») — контакты субъектов.

РеквизитыСубъектов («Реквизиты субъектов») — регистрационные реквизиты страхователя и представителя для пакета ПФР.

2.3 Формы

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

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

Сценарии синтезированы из metadata (реквизиты, ТЧ, тип ДокументОснование); BSL-логика и команды в выгрузке отсутствуют.

3.1 Сценарий: «Отозвать полномочия представителя, заявленные ранее (основной)»

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

3.2 Сценарий: «Сформировать и выгрузить файл для ПФР»

• Когда применяется: документ заполнен, нужно передать уведомление в фонд (через оператора ЭДО или файлом).
• Шаги: 1. Открыть проведённый документ. 2. Выполнить формирование выгрузки штатным механизмом (конкретная команда в выгрузке не определена — commands пуст). 3. Результат фиксируется в ИмяФайлаВыгрузки (имя файла) и ФайлВыгрузки (ValueStorage с содержимым). 4. После фактической отправки проставляется ДатаОтправки.
• Внимание: полнота ТЧ РеквизитыСубъектов (РегистрационныйНомерПФР, Наименование, ИНН, КПП, СНИЛС по каждому Владелец) критична для корректного файла.

3.3 Сценарий: «Просмотр истории отзывов (Read)»

• Когда применяется: нужно выяснить, отзывались ли полномочия конкретного представителя и когда.
• Шаги: открыть журнал документов; найти документ по номеру (строковый, 11 символов, нумерация сквозная — Nonperiodical) или по организации; открыть; проверить ДокументОснование (какое УПУП отозвано), ДатаОтзыва, ДатаОтправки, Получатель.

3.4 Сценарий: «Исправление и повторная отправка (Update)»

• Когда применяется: в отправленном уведомлении обнаружена ошибка (неверные реквизиты субъекта, не тот орган ПФР).
• Шаги: открыть документ; исправить реквизиты шапки или строки ТЧ (выбрав правильное значение Владелец); перепровести; заново сформировать файл выгрузки (поля ИмяФайлаВыгрузки/ФайлВыгрузки перезаполнятся); отправить повторно и актуализировать ДатаОтправки.
• Внимание: ФайлВыгрузки — служебное хранилище, руками не редактируется; меняются исходные данные, файл переформируется.

3.5 Сценарий: «Создание без документа-основания»

• Когда применяется: исходное УПУП в базе отсутствует (велось в другой системе), а отзыв подать нужно.
• Шаги: создать документ; ДокументОснование оставить пустым (DontCheck позволяет); вручную заполнить организацию, субъектов, все три ТЧ по обеим сторонам (Владелец), получателя, РегНомерПФР, ДатаОтзыва; провести и выгрузить.
• Внимание: при ручном вводе никакого автозаполнения из УПУП не будет — все ФИО/контакты/реквизиты субъектов вносятся вручную.

4. Per-field reference

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

• ДокументОснование (DocumentRef.УведомлениеОПредоставленииПолномочийПредставителю): исходное уведомление о предоставлении полномочий (УПУП), которое отзывается; необязателен по метаданным, но содержательно — ключ всего документа; типичное заполнение — выбором из проведённых УПУП организации. Автозаполнение зависимых полей по нему: (не определено из выгрузки).
• Организация (CatalogRef.Организации): организация-страхователь; источник рег. данных (РегНомерПФР, строки ТЧ РеквизитыСубъектов со стороны страхователя).
• ДатаОтзыва (xs:dateTime): дата прекращения полномочий — главная содержательная дата документа.
• ДатаОтправки (xs:dateTime): дата фактической отправки в фонд; заполняется по факту обмена.
• Страхователь (составной, не типизирован в выгрузке): субъект-страхователь; парный реквизит к Представитель.
• Представитель (составной, не типизирован): субъект, чьи полномочия прекращаются.
• СтраховательСотрудник / ПредставительСотрудник (CatalogRef.ФизическиеЛица или xs:string): контактные/подписывающие лица сторон; составной тип позволяет указать физлицо из справочника либо просто строкой.
• Получатель (CatalogRef.ОрганыПФР, синоним «Кому»): территориальный орган ПФР — адресат уведомления.
• РегНомерПФР (xs:string): регистрационный номер организации в ПФР; без него фонд не идентифицирует страхователя.
• ИмяФайлаВыгрузки (xs:string) и ФайлВыгрузки (v8:ValueStorage): служебная пара «имя + содержимое» сформированного файла обмена; заполняются программно при выгрузке.
• Комментарий (xs:string): произвольная пометка пользователя.

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

• Обработчики событий: (не определено) — bsl_static и bsl_summaries в выгрузке пусты.
• Проводки: отсутствуют — register_records пуст; документ не делает движений (документ ЭДО с фондом).
• Валидации: на уровне метаданных контроля заполнения нет (все реквизиты DontCheck); ОбработкаПроверкиЗаполнения: (не определено).
• Зависимости от других модулей: по составу реквизитов — механизм выгрузки/обмена с ПФР (файл в ФайлВыгрузки), справочник ОрганыПФР, перечисление СубъектыДоверенностиСтрахователя; конкретные общие модули: (не определено).

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

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

(не определено) — metadata.based_on пуст: штатного ввода «на основании» в метаданных не заявлено. При этом связь с исходным уведомлением реализована реквизитом ДокументОснование типа cfg:DocumentRef.УведомлениеОПредоставленииПолномочийПредставителю — заполняется выбором в форме.

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

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

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

(не определено) — metadata.register_records пуст: документ не пишет ни в один регистр.

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

1. RU-legacy: объект из российской типовой (ПФР/СНИЛС/ИНН/КПП). Клиентам в Казахстане его НЕ предлагать — отзыв полномочий представителя в РК оформляется другими средствами; документ держится в конфигурации ЗУП КЗ 3.1 как наследие.
2. Метаданные не защищают от пустого документа: все 13 реквизитов — DontCheck, платформа не остановит проведение с незаполненными полями. Агент обязан сам проверять минимум: Организация, ДокументОснование (или вручную заполненные субъекты), Получатель, РегНомерПФР, ДатаОтзыва, строки всех трёх ТЧ.
3. Связь с УПУП — через реквизит, не через «Создать на основании»: based_on пуст; отзыв привязывается выбором в поле ДокументОснование («Документ основание (УПУП)»).
4. ТЧ парные по Владелец: в ФИО, КонтактнаяИнформация, РеквизитыСубъектов данные страхователя и представителя лежат вместе и различаются колонкой Владелец (EnumRef.СубъектыДоверенностиСтрахователя). Заполняя/читая строки, всегда фильтровать по «Владелец».
5. Составные поля субъектов: СтраховательСотрудник и ПредставительСотрудник принимают либо ссылку на ФизическиеЛица, либо строку — при автозаполнении формой учитывать оба варианта.
6. Служебные поля не трогать: ИмяФайлаВыгрузки и ФайлВыгрузки (ValueStorage) заполняются механизмом выгрузки; правится исходное содержимое документа, затем файл формируется заново.
7. Проведение безопасно для учёта: регистров движения нет — документ не влияет на расчёты; его смысл только в формировании и отправке файла в фонд.