В практике бухгалтерского учета нередко возникает ситуация, когда сотрудник просит перечислять заработную плату не на одну банковскую карту, а распределять ее между двумя разными счетами. Это может быть связано с погашением кредитов, разделением личных и семейных накоплений или использованием зарплатных проектов разных банков. В типовых конфигурациях 1С, таких как «Зарплата и управление персоналом» (ЗУП) 3.1, логика выплаты по умолчанию ориентирована на одно «основное» место выплаты, указанное в карточке сотрудника.
Разберем подробно, как реализовать механизм разделения выплат, используя штатные средства программы и программные доработки, если типового функционала оказывается недостаточно.
Прежде чем приступать к программному изменению кода, проанализируем возможности современных релизов 1С:ЗУП 3.1. Начиная с определенных версий (старше 3.1.9), разработчики добавили возможность автоматического распределения сумм к выплате.
Рассмотрим по шагам, как настроить это в интерфейсе:
Проанализируем работу этого механизма: при создании документа Ведомость в банк и выборе конкретного зарплатного проекта, программа автоматически проверит настройки распределения. Если сотруднику положена сумма, превышающая фиксированный лимит для первого проекта, остаток будет ожидать выплаты по второму проекту. Таким образом, бухгалтер просто создает две ведомости по разным проектам, и суммы распределяются автоматически.
Если используется старый релиз программы или штатный механизм по каким-то причинам не подходит, выясним причину, по которой сотрудники не попадают в ведомость. Основная проблема заключается в том, что стандартный запрос при заполнении ведомости ориентируется на реквизит МестоВыплаты справочника Сотрудники, игнорируя наличие других записей в регистре сведений ЛицевыеСчетаСотрудников.
Для решения этой задачи программным способом нам потребуется изменить логику заполнения. Настоятельно рекомендуем использовать расширение конфигурации, чтобы сохранить возможность типового обновления.
Проанализируем ситуацию: нам нужно изменить запрос, который собирает данные о сотрудниках, имеющих лицевые счета по выбранному в ведомости зарплатному проекту. Основная логика подбора сосредоточена в общих модулях, связанных с выплатой зарплаты. Обратим внимание на функции в модуле ВыплатаЗарплатыПеречисления или ЗарплатаКадрыСоставОбъектов.
Пример логики, которую необходимо внедрить в запрос (используя аннотацию &Вместо или &ИзменениеИВыбора):
// В типовом запросе обычно стоит связь:
// ГДЕ Сотрудники.МестоВыплаты = &ЗарплатныйПроект
// Нам нужно изменить условие на проверку наличия записи в регистре:
ВЫБРАТЬ
ЛицевыеСчетаСотрудников.Сотрудник
ИЗ
РегистрСведений.ЛицевыеСчетаСотрудников КАК ЛицевыеСчетаСотрудников
ГДЕ
ЛицевыеСчетаСотрудников.ЗарплатныйПроект = &ВыбранныйЗарплатныйПроект
И ЛицевыеСчетаСотрудников.Действует
При таком подходе программа будет видеть сотрудника в контексте выбранного зарплатного проекта, даже если в его основной карточке указан другой банк. Однако помните о важном риске: без контроля остатков программа может попытаться выплатить полную сумму долга в обе ведомости. Поэтому обязательным условием является интеграция с механизмом проверки задолженности по регистру ЗарплатаКВыплате.
Рассмотрим более «безопасный» способ, который не требует вмешательства в программный код документа — создание внешней обработки. Это позволит добавить в документ кнопку «Заполнить по доп. счетам».
Алгоритм работы обработки может быть следующим:
ВедомостьВБанк зарплатный проект.ЛицевыеСчетаСотрудников есть запись по данному проекту.Состав документа ВедомостьВБанк.Пример кода для получения лицевого счета сотрудника программно:
Функция ПолучитьЛицевойСчет(Сотрудник, ЗарплатныйПроект, ДатаДокумента)
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ЛицевыеСчета.НомерЛицевогоСчета
|ИЗ
| РегистрСведений.ЛицевыеСчетаСотрудников.СрезПоследних(&ДатаДокумента,
| Сотрудник = &Сотрудник И ЗарплатныйПроект = &ЗарплатныйПроект) КАК ЛицевыеСчета";
Запрос.УстановитьПараметр("Сотрудник", Сотрудник);
Запрос.УстановитьПараметр("ЗарплатныйПроект", ЗарплатныйПроект);
Запрос.УстановитьПараметр("ДатаДокумента", ДатаДокумента);
Выборка = Запрос.Выполнить().Выбрать();
Если Выборка.Следующий() Тогда
Возврат Выборка.НомерЛицевогоСчета;
КонецЕсли;
Возврат Неопределено;
КонецФункции
Если бюджет на доработку ограничен, разберем методы, которые позволяют решить задачу силами пользователя, хотя они и более трудоемки:
Проанализируем основные опасности, с которыми можно столкнуться при реализации выплаты на два счета:
Контроль сальдо: Самая большая сложность — не допустить переплаты. Типовой механизм 1С при заполнении ведомости «забирает» всю сумму долга перед сотрудником. Если вы программно заставите сотрудника попадать в две разные ведомости, нужно четко прописать логику: какая сумма идет в первый банк, а какая — во второй. Без этого бухгалтер может случайно выплатить зарплату дважды.
Актуальность счетов: Регистр ЛицевыеСчетаСотрудников является периодическим. При программном поиске счета всегда используйте срез последних на дату документа ведомости, чтобы не отправить деньги на старый, уже закрытый счет сотрудника.
Выгрузка в банк: Проверьте, корректно ли формируется файл выгрузки (электронный обмен с банком). При программных манипуляциях с ведомостью важно, чтобы структура файла соответствовала требованиям конкретного банковского модуля, иначе банк отклонит реестр из-за несоответствия данных сотрудника и номера счета.
Подводя итог, наиболее правильным и современным путем является переход на актуальный релиз 1С:ЗУП и использование настройки «Распределять по счетам». В случае невозможности обновления, оптимальным выбором станет использование расширения конфигурации с корректировкой запроса подбора сотрудников, учитывающего все записи регистра лицевых счетов.