Ловушка дебиторки в 1С:УНФ: почему ваши менеджеры кредитуют клиентов и как это остановить

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

Знакомая ситуация? В оптовых компаниях с отсрочкой платежа это происходит постоянно. Клиент уже превысил все мыслимые лимиты долга, но менеджер всё равно проводит новую отгрузку. Мотив менеджера понятен — ему нужна премия с оборота. А вот компания в итоге по факту бесплатно кредитует должника из своих собственных оборотных средств.

В чём главная проблема типового функционала? В базовой 1С:УНФ отгрузка и оплата по умолчанию не имеют жесткой блокирующей связи. Да, менеджер видит долг клиента в карточке. Но технически программа никак не бьет его по рукам и позволяет спокойно провести расходную накладную.

В итоге весь контроль ложится на плечи финдиректора или РОПа, которым приходится вручную мониторить и согласовывать каждую отгрузку. Это долго, нервно и всегда оставляет лазейку для человеческого фактора.

🛠 Как эта задача решается технически (через доработку) Чтобы закрыть эту «дыру», нужно забрать решение у менеджера и отдать его алгоритму. Поскольку в стандартных настройках жесткого запрета нет, логика контроля программируется дополнительно (обычно в виде расширения).

Вот несколько рабочих архитектурных сценариев, как это можно реализовать:

🛑 Жёсткий запрет отгрузки (Удар по рукам) В карточке договора прописываются два железобетонных условия: лимит отсрочки (в днях) и лимит долга (в рублях). В систему внедряется алгоритм: если покупатель вовремя не оплатил прошлую поставку или превысил сумму, при создании «Расходной накладной» в документе появляется предупреждении о наличии задолженности сверх лимита и при попытке провести документ, программа жестко блокирует его. Менеджер может выставить новый счет, может общаться с клиентом, но физически отгрузить товар со склада — нет.

⛔️ Блокировка на этапе «Заказа покупателя» Для некоторых компаний контроль логичнее перенести на шаг раньше. Прямо внутри заказа выводится красное предупреждение о просрочке. Система просто не дает менеджеру перевести сделку по воронке дальше (например, в статусы «В сборку» или «На доставку»), пока старый долг не будет погашен.

🔐 Защита от самых хитрых Конечно, менеджер захочет сам зайти в настройки и снять галочку блокировки, чтобы провести свою любимую сделку. Чтобы этого не произошло, управление лимитами выводится в отдельные права доступа. Менять суммы и условия отгрузки может только администратор или финдиректор.

📩 Система автокасаний и пени Блокировка — это крайняя мера. Чтобы до нее не доводить, параллельно настраивается система уведомлений. За 2 дня до дедлайна клиенту и менеджеру уходит автоматическое письмо о предстоящей оплате. Если просрочка всё же случилась — робот начинает отправлять регулярные претензии, а на сумму долга автоматически начисляются пени.

Что бизнес получает в итоге? Контроль денег встает до отгрузки, а не после. Компания перестает работать бесплатным банком для проблемных контрагентов. Но самое интересное происходит с психологией отдела продаж: менеджерам теперь самим жизненно выгодно следить за оплатами. Пока их клиент не погасит старый долг, они просто не смогут провести новую сделку и получить за неё свою премию. Вчерашние нарушители превращаются в лучших контролеров дебиторской задолженности.

👇 А как в вашей компании контролируются лимиты по клиентам? Ваша учетная система может технически заблокировать отгрузку должнику или всё держится на ручном согласовании?