Контроль дебиторской задолженности — одна из ключевых задач торгового предприятия. В конфигурации «1С:Управление торговлей» версии 11.4 (а также в родственных ERP 2 и КА 2) для этого предусмотрен специализированный отчет «Задолженность клиентов по срокам». Однако пользователи и аналитики часто сталкиваются с ситуацией, когда отчет выводит некорректные плановые даты оплаты, путает интервалы просрочки или вовсе не реагирует на платежи.
В этой статье мы подробно разберем, почему программа может искажать данные по срокам долга, как на это влияют настройки договоров, почему «зависают» фоновые расчеты и как технически отладить динамический запрос этого отчета.
---
Первое, на что необходимо обратить внимание при анализе конкретной «просроченной» накладной, — это дата платежа, зафиксированная в самом документе продажи или заказе.
Рассмотрим стандартную логику программы. В соглашении с клиентом может быть жестко прописана отсрочка платежа в 5 дней. Логично ожидать, что для реализации от 05.08.19 плановый срок оплаты должен установиться на 10.08.19. Однако менеджер при оформлении документов имеет возможность изменить дату оплаты вручную непосредственно в форме заказа или накладной (вкладка «Правила оплаты» или гиперссылка выбора условий оплаты).
Если в заказе клиента от 30 июля была вручную установлена дата оплаты 4 августа, то программа будет считать задолженность просроченной начиная именно с 5 августа, полностью проигнорировав общие 5 дней отсрочки из соглашения. Всегда проверяйте фактические реквизиты документов расчетов.
---
Это одна из самых частых методологических ошибок настройки системы. Проанализируем, как взаимосвязаны соглашения, договоры и правила оплаты.
Если в информационной базе используются договоры с контрагентами, то именно Договор имеет наивысший приоритет при определении правил расчетов. Настройки соглашения в этом случае отходят на второй план.
В договоре доступно несколько вариантов детализации расчетов:
Если в вашем договоре установлена детализация «По договорам», то система ведет учет взаиморасчетов в рамках единого «пула» по договору. При этом графики платежей конкретных заказов или накладных системой игнорируются при распределении оплат. Зачет авансов и долгов происходит строго по методу ФИФО (First In, First Out).
Давайте разберем на примере, к чему это приводит:
Решение: Если вам жизненно важно отслеживать точные сроки оплаты по конкретным заказам или накладным, измените детализацию расчетов в договоре на «По заказам» или «По накладным». При такой настройке каждый документ будет выступать отдельным объектом расчетов со своим жестким графиком платежей.
---
Если методология настроена верно, но отчет все равно показывает некорректные данные, дело в техническом механизме распределения оплат.
В 1С:УТ 11.4 долгое время использовалась **офлайн-архитектура взаиморасчетов**. При этой схеме проведение накладной или платежного поручения не выполняет мгновенного распределения по ФИФО и не рассчитывает просрочку в транзакции проведения. Вместо этого система делает быструю запись в регистр сведений РегистрСведений.ЗаданияКРаспределениюРасчетовСКлиентами.
Непосредственный расчет выполняется фоновым регламентным заданием «Выполнение отложенных движений по расчетам с клиентами».
Если в регистре заданий скопилось много записей (например, 1300 или более), это свидетельствует о том, что:
Пока очередь заданий не будет обработана до конца (то есть регистр сведений не очистится), отчет по срокам долга будет показывать устаревшие и заведомо неверные данные.
Включение константы АктуализироватьВзаиморасчетыПриФормированииОтчетов обязывает систему запустить расчет прямо в момент формирования отчета. Но если база файловая или объем данных большой, этот процесс может «отваливаться» по таймауту, оставляя отчет неактуальным. Для обхода этого ограничения можно использовать отчет по задолженности клиентов по срокам в реальном времени, который не требует ожидания фоновых заданий или закрытия периода.
Решение в новых версиях: В современных релизах (начиная с УТ 11.5) фирма 1С полностью отказалась от офлайн-взаиморасчетов в пользу **Онлайн-архитектуры**. В этом режиме распределение происходит мгновенно при проведении документов через регистр накопления РегистрНакопления.РасчетыСКлиентамиПоСрокам. Рекомендуется выполнить переход на онлайн-взаиморасчеты через меню НСИ и администрирование -> Настройка НСИ и разделов -> Взаиморасчеты.
---
Иногда возникают технические расхождения между оперативным регистром РегистрНакопления.РасчетыСКлиентами и специализированным регистром РегистрНакопления.РасчетыСКлиентамиПоСрокам. Такие ситуации называются «разрывами взаиморасчетов».
Для исправления подобных коллизий используйте обработку исправления разрывов в рамках процедуры «Закрытие месяца». Она автоматически сверяет остатки по регистрам и корректирует движения документов расчетов; при наличии расхождений после обмена или миграции можно автоматически сравнить проводки между базами 1С.
---
Если вы решите разобраться, как именно отчет собирает данные, вы столкнетесь со сложностью: в схеме компоновки данных (СКД) отчета вы не найдете привычного SQL-подобного запроса.
Разработчики 1С применили динамическое построение текстов запросов. В зависимости от выбранной архитектуры расчетов (онлайн или офлайн), валюты отчета и настроек классификации долга, итоговый текст запроса собирается программно прямо в коде конфигурации.
Давайте разберем по шагам, как локализовать и отладить этот процесс:
ТекстЗапроса(ВалютаОтчета) или обратитесь к процедуре ПриКомпоновкеРезультата(), где вызывается построение временных таблиц.ВзаиморасчетыСервер или ОперативныеВзаиморасчетыСервер).Для включения отладки фоновых заданий выполните следующие действия в конфигураторе:
ПриКомпоновкеРезультата().Пример программного перехвата сформированного текста запроса для последующего анализа в консоли запросов:
// Примерный фрагмент отладки в процедуре ПриКомпоновкеРезультата()
ТекстЗапросаДляАнализа = ЭтотОбъект.ПолучитьТекстЗапросаДляАнализа(); // Вызываем внутренний метод
ЗаписатьТекстВЛог(ТекстЗапросаДляАнализа); // Записываем в текстовый файл для дальнейшего копирования
Изучив сформированный запрос, вы увидите, из каких именно регистров (РегистрНакопления.РасчетыСКлиентамиПоСрокам или РегистрНакопления.РасчетыСКлиентамиПоДокументам) система берет данные и почему плановые даты платежей могут замещаться фактическими.