Как исправить ошибку «Превышено допустимое число дней задолженности» в УТ 10.3 при наличии старых долгов после свертки базы?

В конфигурации 1С:Управление торговлей 10.3 пользователи часто сталкиваются с ситуацией, когда при попытке провести документ отгрузки система выдает ошибку: «Допустимое число дней задолженности: X, дата самой старой задолженности: [дата из далекого прошлого], превышение: Y дней». Это происходит даже в тех случаях, когда база была официально свернута, а реальная текущая задолженность контрагента находится в пределах нормы или вовсе отсутствует. Рассмотрим подробно, почему возникает эта проблема и как ее устранить.

Анализ механизма контроля задолженности

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

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

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

Почему проблема проявляется после обновления?

Часто пользователи замечают, что «раньше все работало», а после обновления конфигурации (например, до версии 10.3.43 и выше) внезапно посыпались ошибки. Рассмотрим причины этого явления:

1. Изменение логики запроса: В более свежих релизах алгоритм проверки может стать более строгим. Если раньше система могла игнорировать записи с помеченными на удаление объектами или проверять только общую сумму по договору, то теперь она жестко ориентируется на минимальную дату в разрезе ДокументРасчетовСКонтрагентом.
2. Производственный календарь: Алгоритм расчета дней может использовать функцию ЧислоРабочихДней. Если после обновления или в начале нового года не был заполнен Производственный календарь за старые периоды (те самые 2012–2013 годы), функция может возвращать некорректные значения, что приводит к странным цифрам в сообщении о превышении (например, 149 дней вместо фактических нескольких лет).

Проанализируем типовой алгоритм расчета просрочки:

Если Константы.СпособКонтроляДнейЗадолженности.Получить() = Перечисления.СпособыКонтроляДнейЗадолженности.ПоКалендарнымДням Тогда
    РазницаДатВСекундах = (ДатаТекущейСделки - Выборка.ДатаПервогоДокумента);
    РазницаДней = Цел(РазницаДатВСекундах/(24 * 60 * 60));
Иначе
    РазницаДней = ЗаполнениеДокументов.ЧислоРабочихДней(Выборка.ДатаПервогоДокумента, ДатаТекущейСделки);
КонецЕсли;

Способ 1: Исправление корректировок записей регистров

Это самый правильный с точки зрения чистоты данных метод. Нам необходимо найти документы Корректировка записей регистров, которые были сформированы в момент свертки базы (обычно это 31 декабря года, предшествующего началу работы в новой базе). Проанализируем ситуацию по шагам:

1. Откроем отчет «Ведомость по взаиморасчетам с контрагентами по документам расчетов».
2. Установим группировку по Контрагенту, Договору и Документу расчетов.
3. Найдем те самые «хвосты» за 2012 год, которые показывают положительный остаток.
4. Найдем документ-регистратор этих остатков. Скорее всего, это будет Корректировка записей регистров.
5. В табличной части корректировки по регистру Взаиморасчеты с контрагентами по документам расчетов заменим старые ссылки на документы 2012 года на сам документ корректировки или на специально созданный пустой документ Документ расчетов с контрагентом (ручной учет), датированный днем свертки.

Важно: После такой замены «точкой отсчета» для системы станет дата свертки, и старая задолженность перестанет считаться просроченной относительно 2012 года.

Способ 2: Создание новых договоров

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

1. Создадим для проблемных контрагентов новые договоры.
2. Перенесем остатки задолженности со старых договоров на новые с помощью документа Корректировка долга (операция «Перенос задолженности»).
3. При переносе в качестве документа-основания на новом договоре укажем актуальную дату или новый документ расчетов.

Это позволит «обнулить» историю взаиморасчетов в разрезе документов, сохранив при этом общую сумму долга клиента перед организацией.

Способ 3: Проверка заполнения календаря

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

1. Перейдем в меню «Операции» — «Регистры сведений» — «Графики работы» (или через настройку производственного календаря в интерфейсе).
2. Убедимся, что календарь заполнен начиная с 2012 года по текущий момент.
3. Если данные за старые годы отсутствуют, их необходимо заполнить и записать, даже если вы не ведете в этой базе учет за тот период. Это необходимо для корректной работы функции ЧислоРабочихДней.

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