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

Разберём, как выстроить систему жесткого контроля дебиторской задолженности, которая технически не даст менеджерам отгружать товар в минус.

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

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

Вот несколько рабочих архитектурных сценариев такой доработки:

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

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

🔐 Защита от «человеческого фактора». Чтобы менеджеры не могли сами себе снимать блокировки, в конфигуратор добавляются новые роли. Право включать/выключать галочку контроля долга и менять суммы лимитов выдается только администратору или финдиректору.

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

Итог: При внедрении такой доработки контроль денег встает до отгрузки, а не после 🛡. Компания перестает финансировать проблемных контрагентов, а менеджерам становится выгодно самим следить за оплатами: пока клиент не погасит старый долг, они просто не смогут провести новую сделку.

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