Как исправить зависание и задвоение сумм при отражении сдельной оплаты в 1С:ERP 2.6?

При переходе на новые релизы 1С:ERP Управление предприятием 2.6 многие технические специалисты столкнулись с критической проблемой в механизме отражения зарплаты в финансовом учете. Система либо «намертво» зависает на этапе проведения документа Отражение зарплаты в финансовом учете, либо формирует некорректные суммы по 20 счету (в некоторых случаях наблюдается пятикратное увеличение итогов). Рассмотрим подробнее, почему это происходит и как решить данную проблему.

Проанализируем причину возникновения проблемы

Корень проблемы кроется в тексте запроса, который система генерирует для сопоставления данных о трудозатратах и финансовых записях. В версиях 2.5.15 и выше, а также в ветке 2.6, разработчики 1С значительно усложнили логику «построчного» отражения зарплаты. Основная цель была благой — привязать каждую копейку налогов и взносов к конкретным видам работ и партиям производства. Однако реализация через сложные внутренние соединения физических таблиц регистров привела к серьезным потерям производительности.

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

ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.ТрудозатратыНезавершенногоПроизводства КАК СтрокиДт
    ПО ДокументыКОтражению.Ссылка = СтрокиДт.Регистратор
        И (СтрокиДт.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход))
        И (СтрокиДт.Активность)
        И (НЕ СтрокиДт.Сторно)
ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.ДвиженияПоПрочимАктивамПассивам КАК СтрокиКт
    ПО ДокументыКОтражению.Ссылка = СтрокиКт.Регистратор
        И (СтрокиКт.Организация = СтрокиДт.Организация)
        И (СтрокиКт.Период = СтрокиДт.Период)
        И (СтрокиКт.НастройкаХозяйственнойОперации = СтрокиДт.НастройкаХозяйственнойОперации)
        И (СтрокиКт.ИдентификаторФинЗаписи = СтрокиДт.ИдентификаторФинЗаписи)
        И (СтрокиДт.ИдентификаторФинЗаписи <> "")

Выясним причину зависания: запрос обращается напрямую к основным таблицам регистров, минуя виртуальные таблицы оборотов. Когда в базе накоплены миллионы записей, ВНУТРЕННЕЕ СОЕДИНЕНИЕ по нескольким полям, включая строковый ИдентификаторФинЗаписи, создает колоссальную нагрузку на SQL-сервер. Если ИдентификаторФинЗаписи заполнен некорректно или дублируется, возникает «картезианское произведение», которое и множит суммы в проводках.

Решение №1: Откат логики запроса к версии 2.5

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

1. Необходимо найти в общем модуле или процедуре проведения текста запроса переменную, отвечающую за начисление сдельной оплаты (например, ТекстЗапросаНачисленоСдельно).
2. Заменить текст этого запроса на аналогичный из релиза ERP 2.5 (до глобального изменения механизма отражения).
3. Добавить необходимые технические колонки, которые появились в версии 2.6 (например, пустую колонку для совместимости структур), чтобы не нарушить работу последующего кода.

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

Решение №2: Предварительная свертка данных при интеграции с ЗУП

Если вы используете обмен между 1С:ЗУП и 1С:ERP, проблема может усугубляться избыточным количеством строк в документе отражения. Посмотрим на ситуацию: часто из ЗУП выгружаются детальные строки по каждому сотруднику и виду работ, которые в ERP в итоге падают на одни и те же аналитики. Чем больше строк со сделкой, тем медленнее работает запрос из-за «лапши» соединений.

Разберем алгоритм оптимизации:

• После загрузки документа Отражение зарплаты в финансовом учете из внешней системы необходимо программно свернуть табличную часть.
• Свертку следует проводить по ключевым полям: Подразделение, СтатьяРасходов, ГруппаПродукции, ВидРабот, НаправлениеДеятельности.
• Это значительно сокращает количество записей, по которым SQL-серверу придется выполнять соединения с регистрами ТрудозатратыНезавершенногоПроизводства.

Важно: будьте осторожны при свертке, если вы используете сложную аналитику по Направлениям деятельности или детальный учет по этапам производства. Если ключевые поля различаются, сворачивать их нельзя.

Решение №3: Контроль версий и патчи от 1С

Проанализируем текущую ситуацию с релизами. Ветка 2.6 на этапе своего появления содержала ряд критических ошибок в закрытии месяца и отражении зарплаты. Некоторые релизы (например, ранние 2.6) даже отзывались разработчиками из-за ошибок в расчете себестоимости и задвоения проводок.

Рекомендуется выполнить следующие действия:

1. Проверить наличие официальных патчей (исправлений) в разделе поддержки 1С. Ищите исправления с префиксами EF_, в описании которых упоминается «Отражение зарплаты» или «Трудозатраты».
2. Если вы обновились на «проблемный» релиз, который позже был отозван, рассмотрите возможность перехода на актуальную стабильную версию.
3. Если обновление невозможно, используйте расширение для корректировки текста запроса, как описано в Решении №1.

Технические выводы

Использование подобных «монструозных» запросов в типовых конфигурациях — это следствие автоматической генерации кода из схем компоновки данных. Для программиста это означает, что нужно крайне внимательно следить за индексами в регистрах ДвиженияПоПрочимАктивамПассивам и ТрудозатратыНезавершенногоПроизводства. Если в ваших данных поле ИдентификаторФинЗаписи часто оказывается пустым или неуникальным, это верный признак того, что типовой механизм будет давать сбои. В таком случае единственным выходом остается кастомизация запроса через расширение с оптимизацией соединений.