Как настроить субконто Работники организации на счете 76.04 при сводном учете зарплаты в 1С:Бухгалтерия 3.0?

← На главную

В практике работы с конфигурацией 1С:Бухгалтерия предприятия 3.0 (БП) часто возникает ситуация, когда требования бухгалтерии или управленческого состава входят в противоречие с жесткой архитектурой программы. Одной из таких задач является попытка вести детальный учет депонированной зарплаты по конкретным сотрудникам на счете 76.04, сохраняя при этом «обезличенный» (сводный) учет на основном счете 70.

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

Анализируем технические ограничения типового решения

Для начала проанализируем, как в 1С:БП 3.0 реализовано управление аналитикой по персоналу. В программе существует глобальная настройка, расположенная в разделе Зарплата и кадры — Настройки зарплаты — Порядок учета зарплаты. Здесь на закладке «Зарплата» выбирается способ ведения учета расчетов с персоналом:

В этой программе или Во внешней программе.
По каждому работнику или Сводно по всем работникам.

Важно понимать: переключатель «Сводно» или «Детально» управляет планом счетов программно. Когда мы выбираем «Сводно», система автоматически отключает (удаляет из видимости и использования) субконто Работники организаций на всех счетах, связанных с оплатой труда. Это касается не только счета 70, но и 76.04 (Депоненты), 76.41 (Исполнительные листы) и других.

Выясним причину такой жесткой связи: Программа обеспечивает единство аналитического учета. Если мы депонируем зарплату (проводка Дт 70 - Кт 76.04), система должна корректно перенести данные. Если на счете 70 учет ведется без сотрудников, а на 76.04 — с ними, возникает методологический разрыв: программе «неоткуда» взять конкретного сотрудника для кредитового оборота по депонентам, если в дебете по счету 70 фигурирует общая сумма по всей организации.

Последствия ручного изменения плана счетов

Рассмотрим ситуацию, когда программист решает вручную добавить субконто на счет 76.04 через конфигуратор или в режиме «1С:Предприятие» при включенном сводном учете. Разберем по шагам, с какими проблемами вы столкнетесь:

1. Отражение в документах. Даже если субконто появится в плане счетов, типовые формы документов Депонирование зарплаты и Списание с расчетного счета (с видом операции «Выплата депонированной зарплаты») не «увидят» это поле. Логика форм в БП 3.0 построена на проверке констант. Программа скроет колонку с сотрудником, так как считает, что учет ведется сводно.

2. Механизм выплаты без ведомостей. Если вы хотите проводить платежные поручения без документа Ведомость, вы столкнетесь с архитектурным барьером. В 1С:БП 3.0 документ Ведомость на выплату зарплаты является ключевым регистратором. Именно он делает записи в регистры накопления (например, Взаиморасчеты с сотрудниками), по которым потом программа понимает, закрыта задолженность или нет. Списание с расчетного счета без ссылки на ведомость при наличии аналитики по сотрудникам приведет к тому, что по бухгалтерскому счету 76.04 сальдо закроется, а во внутренних регистрах 1С долг перед сотрудником будет «висеть» вечно.

3. Обновление системы. Любое вмешательство в предопределенные счета через конфигуратор усложнит поддержку базы. При очередном обновлении 1С может попытаться вернуть стандартные настройки аналитики, что приведет к потере накопленных данных по субконто.

Вариант решения №1: Использование альтернативного счета (76.09)

Если нам нужно видеть сотрудников на депонентах, но категорически нельзя включать детальный учет на 70 счете, проанализируем возможность использования счета 76.09 («Прочие расчеты с разными дебиторами и кредиторами»).

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

Создаем в справочнике Контрагенты отдельную группу «Сотрудники (депоненты)».
Вместо типового документа Депонирование используем Операцию, введенную вручную: Дт 70 - Кт 76.09, где в качестве контрагента указываем сотрудника.
Выплату производим документом Списание с расчетного счета с видом операции «Прочее списание», указывая счет 76.09 и нужного сотрудника (контрагента).

Плюсы: Нет вмешательства в код, полная прозрачность для отчетов типа «Оборотно-сальдовая ведомость».
Минусы: Полное отсутствие автоматизации. Все суммы придется вводить и контролировать вручную.

Вариант решения №2: Разработка расширения (Путь программиста)

Если заказчик настаивает на автоматизации и использовании счета 76.04, нам потребуется создать расширение конфигурации. Посмотрим на примерный алгоритм действий для реализации этой задачи.

Нам необходимо модифицировать поведение системы в трех точках:

Шаг 1. План счетов. В расширении необходимо добавить субконто Работники организаций на счет 76.04. Важно установить признак использования этого субконто независимо от общих настроек зарплаты.

Шаг 2. Формы документов. Нам нужно перехватить процедуру ПриСозданииНаСервере для документов ДепонированиеЗарплаты и СписаниеСРасчетногоСчета. Рассмотрим пример логики:


&НаСервере
Процедура Расш1_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
    // Принудительно отображаем колонку Сотрудник, 
    // даже если в настройках стоит сводный учет
    Элементы.ДепонентыСотрудник.Видимость = Истина;
    Элементы.ДепонентыСотрудник.Доступность = Истина;
КонецПроцедуры

Шаг 3. Логика проведения. Это самый сложный этап. Нам нужно проанализировать ситуацию с регистрами накопления. Чтобы программа позволяла проводить выплату депонента без ведомости, придется вмешаться в модуль проведения Списания с расчетного счета.

Проанализируем примерный код для изменения контроля заполнения:


&Перед("ОбработкаПроверкиЗаполнения")
Процедура Расш1_ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
    // Исключаем Ведомость из обязательных полей, 
    // если вид операции - выплата депонента
    Если Объект.ВидОперации = Перечисления.ВидыОперацийСписаниеСРасчетногоСчета.ВыплатаДепонированнойЗарплаты Тогда
        ПорядковыйНомер = ПроверяемыеРеквизиты.Найти("Ведомость");
        Если ПорядковыйНомер <> Неопределено Тогда
            ПроверяемыеРеквизиты.Удалить(ПорядковыйНомер);
        КонецЕсли;
    КонецЕсли;
КонецПроцедуры

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

Выясним, стоит ли менять типовую логику?

Подведем итог наших изысканий. Желание пользователя иметь «детализацию здесь и тишину там» понятно с точки зрения человеческого восприятия, но деструктивно для архитектуры 1С.

Рекомендация:

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

Таким образом, мы проанализировали проблему отсутствия субконто Работники организаций на счете 76.04 при сводном учете. Мы выяснили, что это не ошибка, а системное ограничение, направленное на поддержание целостности данных. Выбирая между программированием «костылей» и изменением бизнес-процесса, всегда отдавайте предпочтение типовым механизмам платформы 1С:Предприятие 8.3.