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

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

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

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

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

Нумерация: number_type = String, number_length = 9, периодичность — Nonperiodical (сквозная нумерация). Табличных частей нет — вся содержательная «начинка» уведомления лежит в ДанныеУведомления.

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

ВСЕ реквизиты из metadata.attributes (ShowError = обязателен, DontCheck = необязателен):

Итого 15 реквизитов, из них 3 обязательных (ShowError): Организация, ВидУведомления, РегистрацияВИФНС.

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

(не определено) — metadata.tabular_sections пуст: табличных частей у документа нет. Все данные форм уведомления хранятся в реквизите ДанныеУведомления (ValueStorage).

2.3 Формы

(не определено) — в выгрузке metadata.forms и раздел forms пусты. Косвенно из реквизитов ИмяОтчета/ИмяФормы следует, что редактирование ведётся внешней по отношению к документу регламентированной формой, имя которой запоминается в этих полях; сами формы из данных не извлечены.

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

Сценарии синтезированы из metadata; BSL-логика и команды в выгрузке отсутствуют, поэтому программное поведение указано в объёме, выводимом из состава реквизитов.

3.1 Сценарий: «Создать уведомление о спецрежиме (Create)»

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

3.2 Сценарий: «Открыть и просмотреть ранее поданное уведомление (Read)»

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

3.3 Сценарий: «Исправить уведомление до подачи (Update)»

• Когда применяется: в сохранённом, но ещё не поданном уведомлении найдена ошибка (не тот вид, не та регистрация, опечатка в данных формы).
• Шаги: открыть документ; при смене ВидУведомления учитывать, что содержимое ДанныеУведомления относится к прежней форме (несоответствие вида и сохранённых данных — типовая ошибка); исправить данные в форме уведомления; обновить ДатаПодписи; записать.
• Проверки: те же три обязательных поля.

3.4 Сценарий: «Уведомление подаёт представитель»

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

3.5 Сценарий: «Подача по основанию»

• Когда применяется: уведомление подаётся в связи с другим документом/событием в базе.
• Шаги: заполнить реквизит Основание (составной тип, в выгрузке не типизирован) ссылкой на документ-основание; далее — как в 3.1. Штатного «Создать на основании» в метаданных нет (based_on пуст) — поле заполняется в форме.

4. Per-field reference

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

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

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

• Обработчики событий: (не определено) — bsl_static и bsl_summaries в выгрузке пусты, модули не проанализированы.
• Проводки: отсутствуют — register_records пуст; документ не делает движений по регистрам (хранилище регламентированного уведомления).
• Валидации: из метаданных — платформенный контроль заполнения трёх полей с fill_value_required = ShowError: Организация, ВидУведомления, РегистрацияВИФНС. Код ОбработкаПроверкиЗаполнения: (не определено).
• Зависимости от других модулей: по составу реквизитов — механизм регламентированной отчётности (поля ИмяОтчета, ИмяФормы, хранилище ДанныеУведомления), справочник РегистрацииВНалоговомОргане, перечисление ВидыУведомленийОСпецрежимахНалогообложения; конкретные общие модули: (не определено).

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

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

(не определено) — metadata.based_on пуст: штатный ввод «на основании» не заявлен. Связь с основанием возможна только через необязательный составной реквизит Основание.

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

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

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

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

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

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