Документ «Депонирование зарплаты»

Фиксирует факт депонирования не полученной сотрудниками заработной платы: если по ведомости на выплату через кассу или через раздатчика часть людей деньги не получила, документ переводит невыплаченные суммы на учёт расчётов с депонентами и отмечает оплату ведомости. Вводится строго на основании ведомости и содержит список физлиц-депонентов. Документ контура выплат зарплаты в ЗУП для Казахстана 3.1.

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

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

Зарплату выплатили по ведомости через кассу или раздатчика, но часть сотрудников за деньгами не пришла — эти суммы нельзя оставить «висеть» в кассе. В учёте их депонируют: задолженность перед сотрудником закрывается, а сумма ставится на отдельный учёт расчётов с депонентами до момента, когда человек её всё-таки получит. Именно это и делает документ «Депонирование зарплаты» — переносит невыплаченное на депонентов и помечает ведомость-основание как закрытую.

Ключевая особенность объекта: документ вводится только «на основании» ведомости — реквизит Ведомость обязателен и имеет составной тип ровно из двух видов: «Ведомость на выплату зарплаты в кассу» и «Ведомость на выплату зарплаты раздатчиком». Состав депонентов и суммы берутся из этой ведомости; в самой табличной части сумм нет — только список физлиц. Раздел меню в выгрузке конфигурации не определён; по составу движений документ относится к контуру выплат зарплаты.

Кто работает: бухгалтер по расчётам, кассир. Документ эпизодический — создаётся только тогда, когда по закрытой ведомости остались неполученные суммы.

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

Отдельный пункт меню для этого документа в выгрузке не указан. Практически документ создаётся из самой ведомости: открываем проведённую «Ведомость на выплату зарплаты в кассу» (или раздатчиком) и вводим на её основании «Депонирование зарплаты».

📌 Заметка. Журнал документов «Депонирование зарплаты» (нумерация в пределах года, длина номера 11) можно открыть и через «Все функции» либо из подсистемы выплат зарплаты. Ориентироваться в списке удобно по колонке-представлению «Сотрудники» — это строковый реквизит КраткийСоставДокумента, сводка по составу депонентов.

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

Проходим по шагам: от закрытой ведомости до проведённого депонирования неполученных сумм.

Урок 1. Депонирование по ведомости в кассу

Когда: ведомость «на выплату зарплаты в кассу» закрыта, и часть сотрудников зарплату не получила. Это основной сценарий.

  1. Находим и открываем проведённую «Ведомость на выплату зарплаты в кассу», по которой есть неполученные суммы.
  2. Вводим на её основании документ «Депонирование зарплаты» (объект объявлен как вводимый на основании этой ведомости).
  3. Проверяем, что автоматически заполнились Организация и Ведомость — это два обязательных поля.
  4. Смотрим табличную часть «Депоненты»: в ней список физлиц. Оставляем только тех, кто деньги не получил — лишние строки удаляем.
  5. При необходимости заполняем Комментарий и Ответственного (на проведение не влияют).
  6. Проводим документ.
📷 Скриншот: шапка документа «Депонирование зарплаты»
Шапка документа: Организация и Ведомость-основание, ниже — табличная часть «Депоненты» со списком сотрудников.
💡 Подсказка. В табличной части сумм нет — депонируемые суммы определяются по ведомости-основанию. Не ищите колонку с суммой и не пытайтесь её ввести: вы корректируете только состав физлиц.
⚠️ Важно. Обязательны поля Организация и Ведомость (проверка ShowError) — без них документ не проведётся. Организация должна соответствовать организации ведомости-основания. Остальные реквизиты шапки (подписанты, ответственный, комментарий) на проведение не влияют.

Урок 2. Депонирование по ведомости раздатчика

Когда: зарплату выдавали через раздатчика по документу «Ведомость на выплату зарплаты раздатчиком», и раздатчик вернул невыплаченные суммы.

  1. Открываем проведённую «Ведомость на выплату зарплаты раздатчиком».
  2. Вводим на её основании документ «Депонирование зарплаты» — всё аналогично Уроку 1, но основанием служит второй вид составного реквизита Ведомость.
  3. Проверяем Организацию и Ведомость, выверяем состав «Депонентов» и проводим.
⚠️ Важно. Тип реквизита Ведомость допускает ровно два вида документов: ведомость в кассу и ведомость раздатчика. Другие ведомости (например, на выплату в банк) основанием для депонирования не являются — деньги на счёт зачисляются и не депонируются.

Урок 3. Корректировка списка и подписанты

Когда: автозаполнение по ведомости включило лишнего сотрудника или пропустило нужного; либо документ нужно подготовить к печати.

  1. Корректировка состава. Откройте документ и в табличной части «Депоненты» добавьте или удалите строки, выбирая Сотрудника (колонка по метаданным — ФизическоеЛицо). После правки перепроведите документ.
  2. Подписанты для печати. Заполните тройки реквизитов: Главный бухгалтер / Должность / Основание подписи, аналогично Бухгалтер и Кассир. Эти поля нужны только печатным формам.
  3. Проведите документ (или просто запишите, если меняли лишь подписантов).
💡 Подсказка. Контроль «депонирована ли зарплата» удобно вести из самого документа: откройте «Движения» и смотрите ключевой регистр «Взаиморасчёты с депонентами» — там видна задолженность перед каждым депонентом.
📌 Заметка. Поле со списком сотрудников в шапке/списке — это строковый реквизит КраткийСоставДокумента (заголовок «Сотрудники»). Это сводка-представление, а не табличная часть: редактировать состав депонентов через неё нельзя — только через ТЧ «Депоненты». Тройки подписантов на проведение не проверяются (DontCheck).

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

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

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

Тип объекта — документ. Нумерация: тип номера String, длина 11, периодичность Year (в пределах года). Шапка компактна: одно «рабочее» поле-основание (Ведомость) и сводка состава, остальное — подписанты для печати и служебные реквизиты. Две табличные части: Депоненты (прикладная, без сумм) и стандартные ДополнительныеРеквизиты БСП. Ниже — полный реквизитный состав шапки.

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

ИмяТипОбяз.Назначение
ОрганизацияСправочникСсылка.ОрганизацииДаОрганизация, по которой депонируется зарплата; должна соответствовать организации ведомости
ВедомостьДокументСсылка.ВедомостьНаВыплатуЗарплатыВКассу / …РаздатчикомДаВедомость-основание; составной тип из двух видов; задаёт состав депонентов и суммы — главное поле документа
ГлавныйБухгалтерСправочникСсылка.ФизическиеЛицаНетПодписант (главный бухгалтер) для печатных форм
ДолжностьГлавногоБухгалтераСправочникСсылка.ДолжностиНетДолжность подписанта-главбуха
ОснованиеПодписиГлавногоБухгалтера(тип в выгрузке не указан)НетОснование права подписи главбуха (приказ/доверенность)
БухгалтерСправочникСсылка.ФизическиеЛицаНетПодписант-бухгалтер для печатных форм
ДолжностьБухгалтераСправочникСсылка.ДолжностиНетДолжность бухгалтера
ОснованиеПодписиБухгалтера(тип в выгрузке не указан)НетОснование подписи бухгалтера
КассирСправочникСсылка.ФизическиеЛицаНетПодписант-кассир для печатных форм
ДолжностьКассираСправочникСсылка.ДолжностиНетДолжность кассира
ОснованиеПодписиКассира(тип в выгрузке не указан)НетОснование подписи кассира
КраткийСоставДокументаСтрока (синоним «Сотрудники»)НетСтрока-сводка по составу депонентов для списков и представления документа
ОтветственныйСправочникСсылка.ПользователиНетПользователь, ответственный за документ
КомментарийСтрокаНетПроизвольный комментарий
📌 Об обязательности. Только два реквизита помечены fill_value_required: ShowError — Организация и Ведомость; их платформа проверяет автоматически перед записью. Все прочие реквизиты шапки — DontCheck (на проведение не влияют). Тип трёх реквизитов ОснованиеПодписи… в выгрузке метаданных не указан.

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

ИмяНазначение
ДепонентыПрикладная ТЧ: список физлиц-депонентов. Единственная колонка ФизическоеЛицо (СправочникСсылка.ФизическиеЛица, синоним колонки в UI — «Сотрудник»). Сумм в ТЧ нет — суммы берутся из ведомости-основания
ДополнительныеРеквизитыСтандартный механизм доп. реквизитов БСП. Колонки: Свойство (ПланВидовХарактеристикСсылка.ДополнительныеРеквизитыИСведения), Значение (составной, тип не выгружен), ТекстоваяСтрока (Строка — для длинных значений)

Состав ТЧ Депоненты — одна колонка: ФизическоеЛицо (в метаданных — это имя, в интерфейсе подписана «Сотрудник»). Для DOM-поиска агенту полезны оба варианта. Сумм, периодов и видов расчёта в строках нет — корректируется исключительно состав физлиц.

📌 Формы. В JSON-карте список форм пуст (не определено) — используются автогенерируемые/типовые формы документа. Ключевая для пользователя — форма документа с шапкой (Организация, Ведомость) и табличной частью «Депоненты». Команды (commands) в выгрузке также пусты.

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

Документ объявлен регистратором по 10 регистрам. Содержательная часть — взаиморасчёты и отметка оплаты ведомости; значительная часть приёмников относится к НДФЛ российской типовой и в РК по делу не наполняется.

РегистрТипНазначение
ВзаиморасчетыСДепонентамиНакопленияКлючевой: постановка невыплаченных сумм на учёт задолженности перед депонентами
БухгалтерскиеВзаиморасчетыССотрудникамиНакопленияСписание задолженности перед сотрудниками (бухгалтерский контур взаиморасчётов)
ОплатаВедомостейНаВыплатуЗарплатыСведенийОтметка статуса оплаты ведомости-основания (часть закрыта депонированием)
РасчетыНалогоплательщиковСБюджетомПоНДФЛНакопленияНаследие РФ-типовой — в РК не наполняется по делу
УплатаНДФЛНалоговымиАгентамиКРаспределениюНакопленияНаследие РФ-типовой
НДФЛКПеречислениюНакопленияНаследие РФ-типовой
РасчетыНалоговыхАгентовСБюджетомПоНДФЛНакопленияНаследие РФ-типовой
СведенияОДоходахНДФЛНакопленияНаследие РФ-типовой
ДокументыУчтенныеПриРасчетеНДФЛСведенийНаследие РФ-типовой
ДокументыОплаченныеБезУдержанияНДФЛСведенийНаследие РФ-типовой
📌 Наследие РФ-типовой. Семь из десяти регистров-приёмников — это блок НДФЛ российской типовой ЗУП 3.1 (РасчетыНалогоплательщиковСБюджетомПоНДФЛ, УплатаНДФЛНалоговымиАгентамиКРаспределению, НДФЛКПеречислению, РасчетыНалоговыхАгентовСБюджетомПоНДФЛ, СведенияОДоходахНДФЛ, ДокументыУчтенныеПриРасчетеНДФЛ, ДокументыОплаченныеБезУдержанияНДФЛ). В Казахстане подоходный налог — ИПН, а не НДФЛ; для казахстанской отчётности на эти регистры опираться не следует. По делу в РК работают ВзаиморасчетыСДепонентами, БухгалтерскиеВзаиморасчетыССотрудниками и ОплатаВедомостейНаВыплатуЗарплаты.

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

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

Структура обязательности (из fill_value_required: ShowError) — то, что проверяет типовая ОбработкаПроверкиЗаполнения на уровне платформы:

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

Схема проведения (реконструкция): набор движений распределяется по регистрам-приёмникам — «рабочая» часть пишет взаиморасчёты и оплату ведомости, НДФЛ-блок относится к российской типовой.

// Реконструкция по metadata.register_records (10 регистров). Не дословный код модуля.
Процедура ОбработкаПроведения(Отказ, РежимПроведения)

    // 0. Источник сумм — реквизит Ведомость (составной: в кассу / раздатчиком).
    //    Состав депонентов — ТЧ Депоненты (только ФизическоеЛицо, без сумм).
    //    Суммы по каждому депоненту берутся из ведомости-основания.

    // 1. Взаиморасчёты: закрыть долг перед сотрудником и поставить сумму на депонентов.
    Движения.БухгалтерскиеВзаиморасчетыССотрудниками; // списание задолженности перед сотрудниками
    Движения.ВзаиморасчетыСДепонентами;               // постановка на учёт расчётов с депонентами

    // 2. Отметить, что соответствующая часть ведомости закрыта депонированием.
    Движения.ОплатаВедомостейНаВыплатуЗарплаты;

    // 3. Блок НДФЛ — наследие РФ-типовой; в РК (ИПН) по делу не наполняется.
    Движения.РасчетыНалогоплательщиковСБюджетомПоНДФЛ;
    Движения.УплатаНДФЛНалоговымиАгентамиКРаспределению;
    Движения.НДФЛКПеречислению;
    Движения.РасчетыНалоговыхАгентовСБюджетомПоНДФЛ;
    Движения.СведенияОДоходахНДФЛ;
    Движения.ДокументыУчтенныеПриРасчетеНДФЛ;
    Движения.ДокументыОплаченныеБезУдержанияНДФЛ;

    // 4. Запись наборов записей всех регистров.
    Движения.Записать();

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

Зависимости

Дословный список общих модулей в выгрузке отсутствует. Структурно документ опирается на:

ЗависимостьЧто используется
Документы-основанияВедомостьНаВыплатуЗарплатыВКассу, ВедомостьНаВыплатуЗарплатыРаздатчиком — источник состава депонентов и сумм; ввод только «на основании»
СправочникиОрганизации, ФизическиеЛица (депоненты и подписанты), Должности (должности подписантов), Пользователи (ответственный)
Планы видов характеристикДополнительныеРеквизитыИСведения — для ТЧ ДополнительныеРеквизиты (механизм БСП)
Регистры-приёмникиВзаиморасчёты (ВзаиморасчетыСДепонентами, БухгалтерскиеВзаиморасчетыССотрудниками), оплата ведомостей (ОплатаВедомостейНаВыплатуЗарплаты); НДФЛ-блок — наследие РФ-типовой
📌 Заметка. Список «кто создаётся на основании этого» в выгрузке пуст (inverse_based_on — не определено): по карте на основании «Депонирования зарплаты» другие документы не вводятся. Обработчики событий ПриИзменении не определены (BSL-модули в карте отсутствуют).

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