Почему в 1С:УТ 10.3 документ реализации проводится при превышении суммы задолженности?

← На главную

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

Причина 1. Режим проведения документа (Оперативное vs Неоперативное проведение)

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

Выясним, из-за чего документ может проводиться неоперативно:

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

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

Причина 2. Права пользователя и кэширование параметров сеанса

Штатный механизм проверяет наличие специального права у текущего пользователя. Рассмотрим влияние этих настроек:

Откроем регистр сведений Настройки пользователей (через меню Сервис — Пользователи — Настройка дополнительных прав пользователей).
Найдем группу Документы и проверим флаг Разрешить проведение без контроля взаиморасчетов. Если флаг установлен, программа сознательно игнорирует любые лимиты по договорам контрагентов для данного пользователя.
Обратим внимание на кэш сеанса: если вы только что сняли этот флаг у пользователя, изменение не применится мгновенно в уже запущенной программе. Значения дополнительных прав считываются при старте клиентского приложения и кэшируются. Чтобы настройки вступили в силу, пользователь обязательно должен перезапустить 1С.

Причина 3. Способ ведения взаиморасчетов в договоре контрагента

Штатный алгоритм контроля анализирует данные регистра накопления Взаиморасчеты с контрагентами. Механизм тесно завязан на реквизиты договора контрагента:

Посмотрим на реквизит договора Ведение взаиморасчетов. Если в договоре установлено значение По заказам, а отгрузка оформляется сразу документом Реализация товаров и услуг без предварительного создания документа Заказ покупателя, типовой алгоритм не сможет сопоставить лимит долга с конкретным заказом.
Для прямой работы через накладные выберем в договоре способ ведения расчетов По договору в целом или По счетам.
Если используется флаг Вести по документам расчетов с контрагентами, проверьте также включение опции Контролировать число дней задолженности, если требуется отслеживать еще и сроки неоплаченных накладных по регистру Взаиморасчеты с контрагентами по документам расчетов.

Реализация жесткого контроля при любом режиме проведения

Если бизнес-процессы компании требуют блокировать проведение документов с превышением лимита даже при неоперативном проведении (например, при вводе накладных задним числом), штатных настроек будет недостаточно. В таком случае доработаем конфигурацию программно.

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

Разберем пример кода проверки остатка задолженности перед формированием движений документа:


// Проверяем необходимость контроля по договору контрагента
Если ДоговорКонтрагента.КонтролироватьСуммуЗадолженности Тогда

    Запрос = Новый Запрос;
    Запрос.Текст = 
    "ВЫБРАТЬ
    |	ВзаиморасчетыОстатки.СуммаВзаиморасчетовОстаток КАК ДолгОстаток
    |ИЗ
    |	РегистрНакопления.ВзаиморасчетыСКонтрагентами.Остатки(
    |			&МоментВремени,
    |			ДоговорКонтрагента = &ДоговорКонтрагента) КАК ВзаиморасчетыОстатки";

    Запрос.УстановитьПараметр("МоментВремени", МоментВремени());
    Запрос.УстановитьПараметр("ДоговорКонтрагента", ДоговорКонтрагента);

    РезультатЗапроса = Запрос.Выполнить();
    Если НЕ РезультатЗапроса.Пустой() Тогда
        Выборка = РезультатЗапроса.Выбрать();
        Выборка.Следующий();
        
        ТекущийДолг = Выборка.ДолгОстаток;
        ДопустимыйЛимит = ДоговорКонтрагента.ДопустимаяСуммаЗадолженности;
        СуммаПоДокументу = СуммаДокумента; // Сумма текущей реализации
        
        Если (ТекущийДолг + СуммаПоДокументу) > ДопустимыйЛимит Тогда
            Сообщение = Новый СообщениеПользователю;
            Сообщение.Текст = "Превышен лимит задолженности по договору! Лимит: " 
                + ДопустимыйЛимит + ", текущий долг с учетом накладной: " 
                + (ТекущийДолг + СуммаПоДокументу);
            Сообщение.Сообщить();
            
            Отказ = Истина;
            Возврат;
        КонецЕсли;
    КонецЕсли;

КонецЕсли;

Посмотрим, как работает этот алгоритм: запрос обращается к остаткам регистра накопления ВзаиморасчетыСКонтрагентами на точный МоментВремени документа. Если сумма текущего долга покупателя вместе с суммой создаваемой накладной превышает реквизит ДопустимаяСуммаЗадолженности, переменной Отказ присваивается значение Истина, выполнение процедуры прерывается, и документ не проводится независимо от режима проведения.