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