Как программно создать и заполнить ведомость в банк в 1С:ЗУП 3.1?

← На главную

Программное создание платежных документов в конфигурации «1С:Зарплата и управление персоналом 8» (редакция 3.1) — задача, с которой часто сталкиваются разработчики при интеграции с внешними системами, переносе данных или автоматизации выплат. Однако документ ВедомостьНаВыплатуЗарплатыВБанк существенно отличается от простых документов ERP или УТ. В этой статье мы подробно разберем, почему стандартное ручное заполнение его табличных частей является грубой ошибкой, как правильно использовать типовые механизмы ЗУП 3.1 для автоматического расчета сумм и НДФЛ, а также особенности интеграции через COM-соединение и современные альтернативы.

В чем сложность внутренней структуры ведомости в ЗУП 3.1?

Привычный подход начинающих разработчиков — создать документ, заполнить реквизиты шапки и добавить строки в табличную часть — в случае с ведомостями ЗУП 3.1 приводит к фатальным ошибкам. Давайте разберем, почему это происходит. Документ содержит несколько тесно связанных табличных частей:

Состав — содержит перечень физических лиц, которым выплачиваются денежные средства.
Зарплата — детализирует суммы к выплате в разрезе сотрудников, подразделений, периодов действия и статей финансирования.
ФизическиеЛица — хранит информацию о номерах лицевых счетов сотрудников по зарплатному проекту.
НДФЛ — содержит информацию об удерживаемом налоге, которая рассчитывается в строгом соответствии с выплачиваемым доходом.

Ключевая особенность заключается в том, что строки этих табличных частей связаны между собой через уникальный идентификатор — реквизит ИдентификаторСтроки (тип УникальныйИдентификатор). Если вы попытаетесь заполнить эти таблицы вручную без генерации и точного сопоставления этих GUID, программа не сможет корректно провести документ. Кроме того, ручное заполнение ломает механизм учета НДФЛ, введенный в последних версиях платформы, что приведет к катастрофическим ошибкам в отчетах 6-НДФЛ и справках о доходах.

Правильный алгоритм программного создания ведомости

Для того чтобы ведомость заполнилась абсолютно корректно (так же, как если бы пользователь нажал кнопку «Заполнить» в интерфейсе программы), необходимо использовать встроенный программный интерфейс общего модуля ВедомостьНаВыплатуЗарплаты. Давайте разберем этот процесс по шагам.

Рассмотрим детальный пример кода для создания и заполнения ведомости в банк:


// Шаг 1. Инициализация и заполнение шапки документа
НовыйДок = Документы.ВедомостьНаВыплатуЗарплатыВБанк.СоздатьДокумент();
НовыйДок.Дата = ТекущаяДата();
НовыйДок.ПериодРегистрации = НачалоМесяца(ТекущаяДата()); // Месяц, за который выплачивается зарплата
НовыйДок.Организация = Справочники.Организации.НайтиПоРеквизиту("ИНН", "7701020304");
НовыйДок.СпособВыплаты = Справочники.СпособыВыплатыЗарплаты.Зарплата; // Также может быть Аванс или ВМежрасчетныйПериод
НовыйДок.ЗарплатныйПроект = Справочники.ЗарплатныеПроекты.НайтиПоНаименованию("Основной проект Сбербанк");
НовыйДок.Ответственный = Пользователи.ТекущийПользователь();
НовыйДок.ПеречислениеНДФЛВыполнено = Истина;

// Записываем документ-черновик, так как типовому менеджеру расчетов требуется ссылка
НовыйДок.Записать(РежимЗаписиДокумента.Запись);

// Шаг 2. Получение параметров заполнения
МенеджерВедомости = ОбщегоНазначения.МенеджерОбъектаПоСсылке(НовыйДок.Ссылка);
ПараметрыЗаполнения = МенеджерВедомости.ПараметрыЗаполненияПоОбъекту(НовыйДок);

// При необходимости можно ограничить заполнение конкретным списком сотрудников:
// Для каждого ТекСотрудник Из МассивСотрудников Цикл
//     ПараметрыЗаполнения.ОтборСотрудников.Сотрудники.Добавить(ТекСотрудник);
// КонецЦикла;

// Шаг 3. Расчет сумм к выплате
ТаблицаВыплат = ВедомостьНаВыплатуЗарплаты.ЗарплатаКВыплате(
    ПараметрыЗаполнения.ОписаниеОперации,
    ПараметрыЗаполнения.ОтборСотрудников,
    ПараметрыЗаполнения.ПараметрыРасчетаЗарплаты,
    ПараметрыЗаполнения.Финансирование,
    НовыйДок.Ссылка
);

// Шаг 4. Расчет НДФЛ к удержанию
ТаблицаНДФЛ = ВедомостьНаВыплатуЗарплаты.НалогиКУдержанию(
    ТаблицаВыплат,
    ПараметрыЗаполнения.ОписаниеОперации,
    ПараметрыЗаполнения.ПараметрыРасчетаНДФЛ,
    ПараметрыЗаполнения.Финансирование,
    НовыйДок.Ссылка
);

// Шаг 5. Загрузка данных в документ и проведение
НовыйДок.ЗагрузитьВыплаты(ТаблицаВыплат, ТаблицаНДФЛ);
НовыйДок.Записать(РежимЗаписиДокумента.Проведение);

Как это работает изнутри? Разбор методов

Давайте подробно проанализируем, какие именно действия выполняют функции общего модуля в данном алгоритме:

Метод ПараметрыЗаполненияПоОбъекту считывает все настройки шапки нашей ведомости (организацию, период, зарплатный проект, способ выплаты) и формирует специальную структуру параметров для запросов расчета остатков взаиморасчетов.
Метод ЗарплатаКВыплате обращается к регистрам накопления (в частности, к регистру ВзаиморасчетыССотрудниками) и собирает все невыплаченные остатки начисления по указанному периоду и способу выплаты. Он автоматически группирует суммы по сотрудникам и подразделениям, а также генерирует те самые уникальные ИдентификаторСтроки.
Метод НалогиКУдержанию анализирует полученную таблицу выплат и сопоставляет ее с исчисленным ранее НДФЛ из регистра РасчетыНалогоплательщиковСБюджетомПоНДФЛ. Программа автоматически распределяет налог пропорционально выплачиваемым суммам и связывает строки табличной части НДФЛ со строками Зарплата по идентификаторам строк.
Метод ЗагрузитьВыплаты распределяет рассчитанные таблицы по всем внутренним табличным частям документа (Состав, Зарплата, ФизическиеЛица, НДФЛ), устанавливая правильные связи и автоматически подтягивая номера лицевых счетов из регистра сведений ЛицевыеСчетаСотрудниковПоЗарплатнымПроектам.

Особенности программного заполнения через COM-соединение

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

Если вам все же необходимо реализовать перенос именно через COM, используйте следующую архитектурную схему:

В базе-источнике соберите только ключевые параметры шапки ведомости (Организация, Дата, Период регистрации, Зарплатный проект, Способ выплаты).
Подключитесь к базе-приемнику через COM-соединение.
Создайте в базе-приемнике пустой документ ведомости и заполните только эти реквизиты шапки. Запишите его.
Вызовите в базе-приемнике одну-единственную экспортную процедуру (которую предварительно нужно создать в общем модуле приемника), передав в нее ссылку на созданный документ.
Вся логика расчета (заполнение таблиц выплат и НДФЛ) должна выполниться локально на сервере базы-приемника. Это гарантирует стабильность работы и высокую скорость выполнения операции без пересылки больших объемов данных через COM-интерфейс.

Почему стоит отказаться от COM в пользу современных механизмов?

Использование прямого COM-подключения для синхронизации данных в современных реалиях считается устаревшим и нерекомендуемым подходом по следующим причинам:

Платформенная зависимость — COM требует одинаковой разрядности клиента и сервера 1С, а также наличия зарегистрированных библиотек в операционной системе Windows. На серверах под управлением Linux COM-соединение вообще не поддерживается без сложных эмуляций.
Проблемы при обновлениях — при изменении метаданных или типовых процедур в новой версии ЗУП 3.1 ваш COM-код может сломаться, парализовав обмен.
Низкая скорость работы — передача каждого свойства объекта через COM-границу происходит крайне медленно из-за постоянных контекстных вызовов.

Вместо COM-соединения для переноса ведомостей рекомендуется использовать:

Синхронизацию данных через формат EnterpriseData. Это типовой механизм обмена, встроенный во все современные конфигурации 1С. Обмен происходит посредством XML или JSON файлов, либо напрямую через веб-сервисы. В ЗУП 3.1 уже встроены все необходимые правила для корректного переноса платежных документов.
HTTP-сервисы. Отличный вариант для онлайн-интеграции. В базе-приемнике создается простой HTTP-сервис, принимающий JSON-пакет с параметрами ведомости. На стороне приемника отрабатывает локальный код создания и автозаполнения документа, после чего база-источник получает HTTP-ответ с результатом проведения. Такой подход работает мгновенно, не зависит от операционной системы и разрядности платформы.

Типичные ошибки при программном создании ведомости и способы их решения

Давайте проанализируем основные проблемы, с которыми сталкиваются разработчики при внедрении данного кода:

Ошибка «Документ не записан» при вызове менеджера заполнения. Помните, что метод ПараметрыЗаполненияПоОбъекту требует, чтобы у переданного объекта ведомости уже существовала ссылка в базе данных. Обязательно вызывайте НовыйДок.Записать(РежимЗаписиДокумента.Запись) перед началом расчетов.
Пустые суммы к выплате. Если после выполнения кода ведомость создается пустой, проверьте следующие моменты:
1. Существует ли реальная задолженность перед сотрудниками по выбранному способу выплаты на дату ведомости.
2. Соответствует ли период регистрации ведомости периоду начисления зарплаты.
3. Настроены ли лицевые счета сотрудников по указанному зарплатному проекту. Если у сотрудника нет лицевого счета, система может исключить его из заполнения ведомости в банк.
Не сходится НДФЛ. Проверьте, чтобы в базе-приемнике уже были проведены документы начисления зарплаты (например, НачислениеЗарплатыИВзнос). Если налог еще не исчислен в регистрах учета НДФЛ, то и в ведомость удерживаемый налог не попадет, что приведет к нестыковкам в последующем учете.