Почему неверно заполняется отчет «Задолженность клиентов по срокам» в УТ 11.4 и как это исправить?

Программист 1С v8.3 (Управляемые формы) 1С:Управление торговлей Управленческий учет Торговля и дистрибуция
← На главную

Контроль дебиторской задолженности — одна из ключевых задач торгового предприятия. В конфигурации «1С:Управление торговлей» версии 11.4 (а также в родственных ERP 2 и КА 2) для этого предусмотрен специализированный отчет «Задолженность клиентов по срокам». Однако пользователи и аналитики часто сталкиваются с ситуацией, когда отчет выводит некорректные плановые даты оплаты, путает интервалы просрочки или вовсе не реагирует на платежи.

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

---

Причина 1. Ручное изменение дат оплаты в документах

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

Рассмотрим стандартную логику программы. В соглашении с клиентом может быть жестко прописана отсрочка платежа в 5 дней. Логично ожидать, что для реализации от 05.08.19 плановый срок оплаты должен установиться на 10.08.19. Однако менеджер при оформлении документов имеет возможность изменить дату оплаты вручную непосредственно в форме заказа или накладной (вкладка «Правила оплаты» или гиперссылка выбора условий оплаты).

Если в заказе клиента от 30 июля была вручную установлена дата оплаты 4 августа, то программа будет считать задолженность просроченной начиная именно с 5 августа, полностью проигнорировав общие 5 дней отсрочки из соглашения. Всегда проверяйте фактические реквизиты документов расчетов.

---

Причина 2. Настройка детализации взаиморасчетов в договоре

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

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

В договоре доступно несколько вариантов детализации расчетов:

  1. По договорам (так называемый «котловой» метод).
  2. По заказам.
  3. По накладным.

Если в вашем договоре установлена детализация «По договорам», то система ведет учет взаиморасчетов в рамках единого «пула» по договору. При этом графики платежей конкретных заказов или накладных системой игнорируются при распределении оплат. Зачет авансов и долгов происходит строго по методу ФИФО (First In, First Out).

Давайте разберем на примере, к чему это приводит:

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

---

Причина 3. Офлайн-архитектура взаиморасчетов и очередь распределения

Если методология настроена верно, но отчет все равно показывает некорректные данные, дело в техническом механизме распределения оплат.

В 1С:УТ 11.4 долгое время использовалась **офлайн-архитектура взаиморасчетов**. При этой схеме проведение накладной или платежного поручения не выполняет мгновенного распределения по ФИФО и не рассчитывает просрочку в транзакции проведения. Вместо этого система делает быструю запись в регистр сведений РегистрСведений.ЗаданияКРаспределениюРасчетовСКлиентами.

Непосредственный расчет выполняется фоновым регламентным заданием «Выполнение отложенных движений по расчетам с клиентами».

Если в регистре заданий скопилось много записей (например, 1300 или более), это свидетельствует о том, что:

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

Включение константы АктуализироватьВзаиморасчетыПриФормированииОтчетов обязывает систему запустить расчет прямо в момент формирования отчета. Но если база файловая или объем данных большой, этот процесс может «отваливаться» по таймауту, оставляя отчет неактуальным.

Решение в новых версиях: В современных релизах (начиная с УТ 11.5) фирма 1С полностью отказалась от офлайн-взаиморасчетов в пользу **Онлайн-архитектуры**. В этом режиме распределение происходит мгновенно при проведении документов через регистр накопления РегистрНакопления.РасчетыСКлиентамиПоСрокам. Рекомендуется выполнить переход на онлайн-взаиморасчеты через меню НСИ и администрирование -> Настройка НСИ и разделов -> Взаиморасчеты.

---

Причина 4. Разрывы взаиморасчетов

Иногда возникают технические расхождения между оперативным регистром РегистрНакопления.РасчетыСКлиентами и специализированным регистром РегистрНакопления.РасчетыСКлиентамиПоСрокам. Такие ситуации называются «разрывами взаиморасчетов».

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

---

Техническая отладка: Где находится запрос отчета?

Если вы решите разобраться, как именно отчет собирает данные, вы столкнетесь со сложностью: в схеме компоновки данных (СКД) отчета вы не найдете привычного SQL-подобного запроса.

Разработчики 1С применили динамическое построение текстов запросов. В зависимости от выбранной архитектуры расчетов (онлайн или офлайн), валюты отчета и настроек классификации долга, итоговый текст запроса собирается программно прямо в коде конфигурации.

Давайте разберем по шагам, как локализовать и отладить этот процесс:

  1. Запрос генерируется в модуле объекта отчета. Найдите функцию ТекстЗапроса(ВалютаОтчета) или обратитесь к процедуре ПриКомпоновкеРезультата(), где вызывается построение временных таблиц.
  2. Основной сбор данных и подготовка структуры «Платежи» часто вынесены в функции общих модулей (например, ВзаиморасчетыСервер или ОперативныеВзаиморасчетыСервер).
  3. Чтобы перехватить и проанализировать итоговый SQL-запрос в файловой базе, вам потребуется настроить отладку фоновых заданий, так как отчет формируется в отдельном фоновом потоке.

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

Пример программного перехвата сформированного текста запроса для последующего анализа в консоли запросов:


// Примерный фрагмент отладки в процедуре ПриКомпоновкеРезультата()
ТекстЗапросаДляАнализа = ЭтотОбъект.ПолучитьТекстЗапросаДляАнализа(); // Вызываем внутренний метод
ЗаписатьТекстВЛог(ТекстЗапросаДляАнализа); // Записываем в текстовый файл для дальнейшего копирования

Изучив сформированный запрос, вы увидите, из каких именно регистров (РегистрНакопления.РасчетыСКлиентамиПоСрокам или РегистрНакопления.РасчетыСКлиентамиПоДокументам) система берет данные и почему плановые даты платежей могут замещаться фактическими.

← На главную