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

Конфигурация: «Зарплата и управление персоналом для Казахстана 3.1» (ZupKZ31). ⚠️ RU-наследие типовой ЗУП 3.1: документ пишет в регистры с «НДФЛ» в именах (НДФЛПеречисленный, РасчетыНалогоплательщиковСБюджетомПоНДФЛ и др.) — это российский подоходный налог; в Казахстане его аналог — ИПН. Сами регистры в KZ-конфигурации сохранены из типовой; казахстанская отчётность по ИПН/ОПВ/СО/ВОСМС строится на других механизмах. Комментарий из метаданных: «АПК:93 представления объекта и списка совпадают». В JSON-карте нет форм, BSL-модулей и сводок (forms=[], bsl_static=[], bsl_summaries=[]) — карточка построена строго на метаданных.

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

Документ «Сведения о незачисленной зарплате» регистрирует факт, что банк не зачислил перечисленную зарплату (или прочий доход) на счета отдельных сотрудников по конкретной платёжной ведомости. Шапка жёстко привязана к документу-ведомости (Ведомость — один из трёх видов: «…ПеречислениемВ», «…ВБанк», «ВедомостьПрочихДоходовВБанк»), а табличная часть Сотрудники перечисляет физлиц, чьи суммы не дошли. Проведение документа корректирует взаиморасчёты с сотрудниками и регистры перечисленного налога (см. раздел 6.3) — выплата по этим людям перестаёт числиться состоявшейся. Используется расчётчиком зарплаты эпизодически — только при возвратах/незачислениях из банка. Место в меню по данным карты не определено.

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

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

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

Все 6 реквизитов из metadata.attributes, без пропусков.

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

ТЧ Сотрудники — список физлиц, чьи суммы по ведомости не были зачислены банком.

ТЧ ДополнительныеРеквизиты — стандартный механизм доп. реквизитов (подсистема «Свойства» БСП).

2.3 Формы

В metadata.forms и секции forms JSON-карты формы отсутствуют — (не определено). Судя по комментарию метаданных («представления объекта и списка совпадают»), используются стандартные представления; ключевую форму по карте указать нельзя.

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

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

3.1 Сценарий: «Регистрация незачисления зарплаты из банковской выписки/возврата»

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

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

• Когда применяется: контроль ранее зафиксированных незачислений.
• Шаги: открыть список документов → ориентироваться по номеру (уникален в пределах года), Организация, Ведомость и строке КраткийСоставДокумента (в списке показывает состав сотрудников).
• Внимание: представления объекта и списка совпадают (комментарий метаданных АПК:93).

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

• Когда применяется: в документ попал не тот сотрудник или добавились новые незачисления по той же ведомости.
• Шаги: открыть документ → отредактировать строки ТЧ Сотрудники → перепровести.
• Внимание: движения по регистрам будут переформированы при перепроведении; Ведомость менять на другую ведомость = по сути новый документ.
• Проверки: обязательность Организация/Ведомость (ShowError); остальное — (не определено).

3.4 Сценарий: «Повторная выплата незачисленных сумм»

• Когда применяется: после регистрации незачисления деньги нужно выплатить сотруднику повторно (на новые реквизиты или через кассу).
• Шаги: документ проведён → суммы по указанным физлицам возвращаются в состояние «к выплате» (в составе движений есть регистры ЗарплатаКВыплате и ЗарплатаКВыплатеАвансом) → сформировать новую ведомость на выплату обычным порядком.
• Внимание: сам документ повторную выплату не создаёт (inverse_based_on пуст — «создать на основании» не предусмотрено по карте); новая ведомость делается стандартным механизмом выплат.

3.5 Сценарий: «Отмена ошибочно введённого незачисления»

• Когда применяется: незачисление зарегистрировано ошибочно (платёж на самом деле прошёл).
• Шаги: отменить проведение документа (движения по всем 10 регистрам удаляются) → при необходимости пометить на удаление.
• После отмены проведения: взаиморасчёты и данные о перечисленном налоге возвращаются к состоянию «выплата состоялась».

4. Per-field reference

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

• Организация (cfg:CatalogRef.Организации): организация-работодатель; обязателен (fill_value_required = ShowError); логически должна совпадать с организацией выбранной ведомости (автоконтроль в карте не определён).
• Ведомость (составной DocumentRef: ВедомостьНаВыплатуЗарплатыПеречислением / ВедомостьНаВыплатуЗарплатыВБанк / ВедомостьПрочихДоходовВБанк): документ-источник выплаты, по которому фиксируется незачисление; обязателен (ShowError); определяет, каких сотрудников можно указать в ТЧ; типичное значение — последняя банковская ведомость периода.
• Подразделение (cfg:CatalogRef.ПодразделенияОрганизаций): необязательная аналитика «Структурное подразделение».
• КраткийСоставДокумента (xs:string): служебная строка-представление состава сотрудников для списка (синоним «Сотрудники»); заполняется системой (порядок формирования в карте не определён) — вручную не редактировать.
• Ответственный (cfg:CatalogRef.Пользователи): стандартный реквизит; обычно подставляется текущий пользователь (автозаполнение в карте не определено).
• Комментарий (xs:string): свободный текст — рекомендуется фиксировать причину незачисления (возврат банка, закрытый счёт и т.п.).
• ТЧ Сотрудники.ФизическоеЛицо (cfg:CatalogRef.ФизическиеЛица): ключевое поле табличной части; перечисляет тех, чьи суммы из ведомости не зачислены.

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

• Обработчики событий: (не определено) — bsl_static и bsl_summaries пусты.
• Движения при проведении: документ пишет в 10 регистров накопления (полный список в 6.3). Состав регистров показывает, что проведение корректирует: взаиморасчёты с сотрудниками (ВзаиморасчетыССотрудниками, БухгалтерскиеВзаиморасчетыССотрудниками, ВзаиморасчетыСКонтрагентамиАкционерами), состояние сумм к выплате (ЗарплатаКВыплате, ЗарплатаКВыплатеАвансом) и учёт перечисленного подоходного налога (НДФЛПеречисленный, НДФЛКПеречислению, РасчетыНалогоплательщиковСБюджетомПоНДФЛ, РасчетыНалоговыхАгентовСБюджетомПоНДФЛ, СведенияОДоходахНДФЛ). Конкретная логика записей (сторно/приход/расход) в карте не представлена — (не определено).
• Валидации (ОбработкаПроверкиЗаполнения): по метаданным — обязательность Организация и Ведомость (ShowError); серверный код — (не определено).
• Зависимости от других модулей: (не определено) по карте; по типам реквизитов задействованы подсистемы выплат (три вида ведомостей) и доп. реквизитов (БСП).

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

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

metadata.based_on пуст — ввод на основании не предусмотрен; связь с ведомостью реализована реквизитом шапки Ведомость, а не механизмом «на основании».

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

metadata.inverse_based_on пуст — ничего не создаётся (по данным карты).

6.3 Регистры движения (metadata.register_records, имена дословно)

1. AccumulationRegister.РасчетыНалогоплательщиковСБюджетомПоНДФЛ — RU-наследие (НДФЛ; в КЗ аналог — ИПН)
2. AccumulationRegister.ВзаиморасчетыССотрудниками
3. AccumulationRegister.НДФЛПеречисленный — RU-наследие
4. AccumulationRegister.БухгалтерскиеВзаиморасчетыССотрудниками
5. AccumulationRegister.ВзаиморасчетыСКонтрагентамиАкционерами
6. AccumulationRegister.НДФЛКПеречислению — RU-наследие
7. AccumulationRegister.ЗарплатаКВыплатеАвансом
8. AccumulationRegister.РасчетыНалоговыхАгентовСБюджетомПоНДФЛ — RU-наследие
9. AccumulationRegister.СведенияОДоходахНДФЛ — RU-наследие
10. AccumulationRegister.ЗарплатаКВыплате

6.4 Ссылочные связи через реквизиты (из типов метаданных)

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

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

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