Как исправить ошибку Допустимое число дней задолженности в УТ 10.3

← На главную

В конфигурации 1С:Управление торговлей 10.3 пользователи часто сталкиваются с ситуацией, когда при попытке отгрузки товара система выдает ошибку: Допустимое число дней задолженности превышено, указывая дату самой старой задолженности из далекого прошлого (например, до момента свертки базы). Рассмотрим подробно причины возникновения этой проблемы и способы её решения.

Почему возникает фантомная задолженность

Ситуация, когда дата задолженности тянется из периодов, которые уже были «отрезаны» сверткой, обычно связана с некорректными остатками в регистрах накопления. Даже если общая сумма долга по контрагенту равна нулю, алгоритм контроля может видеть «незакрытые» документы. Проанализируем основные технические причины:

Разрез измерений: В регистре ВзаиморасчетыСКонтрагентамиПоДокументамРасчетов задолженность может «зависнуть» из-за разницы в значениях измерений. Например, если приход прошел по одной «Организации» или «Проекту», а расход — по другому. Визуально в отчете общая сумма будет нулевой, но по конкретной аналитике останется «плюс» с древней датой.
Регистр Расчеты с контрагентами: В УТ 10.3 контроль лимитов часто опирается не только на основной регистр взаиморасчетов, но и на вспомогательный — РасчетыСКонтрагентами. Если при свертке базы остатки по нему не были очищены, система будет брать дату именно оттуда.
Битые ссылки в итогах: После удаления старых документов в таблицах итогов могут остаться записи, ссылающиеся на Объект не найден. Стандартный пересчет итогов не всегда вычищает такие хвосты.
Микро-остатки: Из-за особенностей хранения чисел с плавающей точкой могут оставаться копейки вроде 0.0000001. В отчетах они округляются до нуля, но программный код видит их как задолженность.

Шаг 1. Диагностика через стандартные отчеты

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

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

Проанализируем результат. Если мы видим строки, где по одному документу расчетов висит положительный остаток, а по другому (или пустому) — отрицательный, значит, задолженность не «схлопнулась». Если отчет не показывает старых дат, переходим к расширенной диагностике.

Шаг 2. Анализ с помощью консоли запросов

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


ВЫБРАТЬ
    Взаиморасчеты.ДоговорКонтрагента,
    Взаиморасчеты.ДокументРасчетовСКонтрагентом,
    Взаиморасчеты.СуммаВзаиморасчетовОстаток
ИЗ
    РегистрНакопления.ВзаиморасчетыСКонтрагентамиПоДокументамРасчетов.Остатки(&Период, Контрагент = &Контрагент) КАК Взаиморасчеты
ГДЕ
    Взаиморасчеты.СуммаВзаиморасчетовОстаток <> 0

Если запрос вернул строки с датами 2012–2013 годов, значит, эти записи физически присутствуют в таблице итогов, даже если сами документы помечены на удаление или отсутствуют.

Шаг 3. Отладка программного кода

Выясним, какой именно алгоритм находит старую дату. В УТ 10.3 логика контроля сосредоточена в модуле регистра накопления ВзаиморасчетыСКонтрагентами. Найдем процедуру КонтрольОстатков. Именно здесь система выполняет запрос к виртуальным таблицам остатков. Рассмотрим, на что обратить внимание при отладке:

Посмотрим, какая временная таблица формируется в процессе проведения документа.
Проверим, учитываются ли записи с пустыми документами расчетов.
Обратим внимание на функцию СформироватьЗапросПоПервомуНеоплаченномуДокументу в общем модуле. Она часто используется для определения той самой «даты самой старой задолженности».

Шаг 4. Исправление проблемы

В зависимости от выявленной причины, выберем способ устранения ошибки:

1. Тестирование и исправление (ТиИ):

Выполним полное тестирование базы. В настройках ТиИ обязательно выберем пункты Очистка ссылок и Проверка логической целостности. Для параметра «При наличии ссылок на несуществующие объекты» установим значение Очищать ссылки или Удалять объект. Это поможет убрать фантомные записи из таблиц итогов, оставшиеся после свертки.

2. Корректировка записей регистров:

Если ТиИ не помогло, создадим документ Корректировка записей регистров. В нем выберем регистр Взаиморасчеты с контрагентами по документам расчетов и вручную «схлопнем» остатки. Нужно добавить две строки: одну с видом движения «Расход» для закрытия зависшего плюса, и вторую с видом движения «Приход» (или наоборот), чтобы итоговый баланс по контрагенту не изменился, но аналитика очистилась.

3. Технологический пересчет через SQL:

Если база работает на MS SQL Server, иногда помогает полная очистка таблиц итогов (таблицы с суффиксом _Totals) и последующий запуск пересчета итогов из конфигуратора. Внимание: эту операцию должен выполнять только опытный системный администратор или программист при наличии свежей архивной копии.

4. Очистка кэша:

Не забудем про очистку серверного кэша. Информация о старых остатках может кэшироваться на уровне сервера приложений 1С. После удаления битых записей рекомендуется перезапустить службу 1С:Предприятия и очистить папку snccntx.