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

Когда организация начинает вести учёт в ЗУП для Казахстана 3.1, на дату перехода обычно уже есть «незакрытые» расчёты с сотрудниками: начисленная, но не выплаченная зарплата, либо, наоборот, переплата или неотработанный аванс за работником. Эти остатки нужно перенести в новую базу, иначе ведомости на выплату и отчёты по взаиморасчётам стартуют «с нуля» и не сойдутся. Документ «Начальная задолженность по зарплате» построчно по сотрудникам вводит такое сальдо, а направление долга задаёт реквизит «Способ ввода задолженности» — это главный переключатель смысла сумм.

Важная казахстанская оговорка: документ оперирует уже исчисленными суммами «к выплате». Полей для ИПН, ОПВ, ОПВР, СО, ВОСМС, ООСМС в нём нет — налоги и взносы РК этим документом не рассчитываются и не корректируются, единым платежом он тоже не оперирует. Для переноса самих налогов и взносов служат отдельные документы ввода остатков; здесь — только сальдо зарплатных взаиморасчётов.

Кто работает: бухгалтер-расчётчик, специалист по внедрению. Как правило, документ заводится однократно на старте эксплуатации (или при переносе с другой программы), а далее используется лишь для корректировки начальных данных. На основании других документов он не вводится — только вручную из списка либо сервисами переноса.

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

По назначению документ относится к блоку ввода данных на начало эксплуатации раздела «Кадры» (расчёт зарплаты). Открываем журнал документов «Начальная задолженность по зарплате» и создаём новый кнопкой «Создать».

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

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

Урок 1. Долг организации перед сотрудниками

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

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

Урок 2. Долг сотрудника и история выплат

Когда: на дату перехода сотрудник должен организации (излишне выплаченные суммы, неотработанный аванс), либо вместе с остатком нужно перенести фактические выплаты прошлых периодов.

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

Урок 3. Сверка и исправление остатков

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

1. Открываем список документов «Начальная задолженность по зарплате». Находим нужный документ по номеру (нумерация в пределах года) или по колонке «Сотрудники» (автоформируемое краткое содержание).
2. Открываем документ и исправляем суммы или строки в таблице «Задолженность по зарплате».
3. Перепроводим документ — движения по трём регистрам взаиморасчётов будут перезаписаны актуальными суммами.

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

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

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

Тип объекта — документ. Нумерация: тип номера String, длина 11, периодичность Year (в пределах года). В шапке 6 реквизитов, 3 табличные части. Комментарий разработчика в метаданных — служебная пометка стандартов разработки «АПК:93 представления объекта и списка совпадают» (на пользователя не влияет). Ниже — полный реквизитный состав шапки и состав табличных частей.

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

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

ЗадолженностьПоЗарплате («Задолженность по зарплате») — основная ТЧ построчного ввода остатков по сотрудникам:

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

ДополнительныеРеквизиты («Дополнительные реквизиты») — стандартный механизм БСП «Свойства»: колонки Свойство (ПланВидовХарактеристикСсылка.ДополнительныеРеквизитыИСведения), Значение (составной, в метаданных не типизирован) и ТекстоваяСтрока (Строка — текстовое представление значения).

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

Документ объявлен регистратором по трём регистрам накопления — это полный список приёмников движений из метаданных (register_records):

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

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

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

Схема проведения (реконструкция): суммы строк ТЧ ЗадолженностьПоЗарплате распределяются по трём регистрам-приёмникам — каждый «слой» учёта пишет свою часть сальдо.

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

    // Направление долга задаёт СпособВводаЗадолженности (трактовка сумм ТЧ),
    // а не знак суммы. Аналитика строки: Сотрудник, Подразделение,
    // СтатьяФинансирования, СтатьяРасходов, ВидДоходаИсполнительногоПроизводства.

    Для Каждого СтрокаТЧ Из ЗадолженностьПоЗарплате Цикл

        // 1. Расчётный (зарплатный) контур взаиморасчётов — из колонки Сумма.
        Движение = Движения.ВзаиморасчетыССотрудниками.Добавить();
        // Движение.Сотрудник = СтрокаТЧ.Сотрудник; Движение.Сумма = СтрокаТЧ.Сумма; ...

        // 2. Суммы к выплате — попадут в ведомости на выплату.
        Движение = Движения.ЗарплатаКВыплате.Добавить();
        // Движение.Сумма = СтрокаТЧ.Сумма; ...

        // 3. Бухгалтерский контур взаиморасчётов — из колонки СуммаПоБухучету.
        Если ЗначениеЗаполнено(СтрокаТЧ.СуммаПоБухучету) Тогда
            Движение = Движения.БухгалтерскиеВзаиморасчетыССотрудниками.Добавить();
            // Движение.Сумма = СтрокаТЧ.СуммаПоБухучету; ...
        КонецЕсли;

    КонецЦикла;

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

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

Зависимости

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

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

• Начисление зарплаты и взносов — как после ввода начальных остатков формируется текущий расчёт месяца, налоги и взносы РК.
• Ведомость в банк — куда подтягиваются перенесённые суммы к выплате из регистра ЗарплатаКВыплате.