Содержание
- Главное
- Типичный сценарий
- Когда это нужно
- Что умеет типовой 1С:ERP — и чего ему не хватает
- Почему не закрыть задачу типовыми средствами
- Решение: финансовое вето внутри маршрута отгрузки
- Рабочее место казначея: всё в одном окне
- Два отчёта — два сценария решения
- Лимиты клиентов: где они живут
- Что меняется в работе команд
- Что делать дальше
Финансовая служба узнаёт о просроченной отгрузке слишком поздно. В типовой 1С:ERP между «заказ готов» и «машина ушла со склада» есть автоматический контроль задолженности по соглашению, но нет обязательного ручного согласования финслужбой с учётом контекста — страхового и внутреннего лимита, этапов оплаты, просрочки по дням. Ниже — как встроить в маршрут обязательный шаг согласования и за 1-2 недели получить инструмент, который, по нашим оценкам, сокращает просроченную дебиторку на 15–30% за первые полгода.
Главное
- Финансовая служба ставит обязательное вето перед отгрузкой — без её разрешения статус «К отгрузке» недоступен.
- Рабочее место казначея — одно окно: лимиты, задолженность, ордер, отчёты по предоплате и постоплате.
- Решение работает расширением 1С:ERP, без правки типового кода; срок внедрения — 1–2 недели.
- По нашим оценкам, сокращает просроченную дебиторку на 15–30% за первые 6 месяцев.
Типичный сценарий
Утро понедельника, 10:15. Казначей производственной компании открывает отчёт по дебиторке и находит пятничную отгрузку на 4,2 млн рублей клиенту, у которого 38 дней просрочки и закрытый внутренний лимит. Претензия уже на рассмотрении. Начинается утомительный разговор с коммерцией, складом и клиентом — кто виноват, кто заплатит и как не допустить повторения.
Правда в том, что эту отгрузку можно было остановить за пять секунд — если бы в маршруте расходного ордера был шаг финансового согласования. В типовой 1С:ERP его нет.
По нашему опыту это одно из самых уязвимых мест маршрута продаж в производственных и дистрибьюторских компаниях. Цена — не только «замороженная» в клиенте дебиторка, но и репутационные потери: отгрузка, которую потом приходится откатывать на уровне оплат и претензий.
Когда это нужно
Отметьте пункты, которые про вас. Если их три или больше — финансовое вето окупится.
☐ Постоплата составляет 30% и более от общего объёма продаж.
☐ Просрочка свыше 30 дней регулярно появляется у 5+ клиентов в месяц.
☐ Финансовый директор узнаёт о проблемных отгрузках из квартальной отчётности, а не до того, как они уходят со склада.
☐ Клиенты работают по кредитным лимитам: страховым, банковским или внутренним.
☐ Часть заказов идёт в иностранной валюте, и пересчёт задолженности ведётся вручную.
☐ Обратная связь между финслужбой и складом идёт в мессенджерах и звонках, а не в системе.
Что меняется для финансовой службы, склада и дебиторки
Что умеет типовой 1С:ERP — и чего ему не хватает
В типовой конфигурации уже есть определенная функциональность: этапы оплаты в соглашениях с клиентами, кредитный лимит в соглашении, функциональная опция контроля расчётов с клиентами, отчёт «Задолженность клиентов по срокам», автоматические статусы расходного ордера. Платформа умеет автоматически запрещать проведение документов при превышении настроенного лимита. На практике этого недостаточно по трём причинам.
Во-первых, в маршруте нет обязательного шага «финансовое согласование». Статус расходного ордера можно довести до «К отгрузке», не выполнив ручную оценку риска с учётом лимитов и просрочки.
Во-вторых, у казначея или бухгалтера нет одного окна, в котором по конкретному клиенту видны одновременно: застрахованный лимит, внутренний лимит, фактическая задолженность с разбивкой по срокам, сумма готовящегося к отгрузке ордера и информация о ранее отклонённых отгрузках.
В-третьих, обратная связь от финслужбы на склад идёт через устные договорённости и чат, а не через систему. Склад не видит в своём интерфейсе, почему конкретный ордер «завис», и выясняет причину вне 1С.
Почему не закрыть задачу типовыми средствами
Справедливый вопрос: в 1С:ERP есть подсистема «Процессы и задачи» БСП, типовой механизм согласования документов, права доступа. Почему они не решают задачу?
Типовое согласование документов работает в логике «пользовательская задача»: кто-то формирует запрос, кто-то принимает его и вручную ставит отметку. Для отгрузки в темпе реального производства это медленно и требует дисциплины, которую в рутине реально никто не соблюдает.
Подсистема «Процессы и задачи» БСП даёт гибкий маршрут, но не блокирует смену статуса расходного ордера на уровне платформы. Финансист может «забыть» согласовать — и ордер всё равно перейдёт в «К отгрузке». Нужен не воркфлоу, а запрет.
Механизм прав доступа тоже не подходит. Запретить статус «К отгрузке» для всех, кроме казначея, технически можно — но тогда казначей должен ставить этот статус на каждом ордере вручную, что полностью противоречит его ролевой модели.
Главное, чего не даёт ни один типовой механизм, — контекст для решения. Казначей согласует не галочку, а суждение: «у этого клиента 12 дней просрочки, внутренний лимит превышен на 400 тыс. руб., страховой — в пределах; отгрузка в евро по курсу на дату документа». Этот контекст собирает только специализированный инструмент: рабочее место с лимитами, задолженностью и отчётами по предоплате/постоплате. Типовая обвязка его не даёт.
Решение: финансовое вето внутри маршрута отгрузки
Базовая идея — добавить в маршрут Расходного ордера на товары служебный реквизит «Отгрузка разрешена». По умолчанию он равен «Ложь»: пока он не переключён в «Истина», статусы «К отгрузке» и «Отгружен» для ордера недоступны. Меняет этот признак не любой пользователь, а сотрудник финансовой службы — через отдельное рабочее место.
Решение реализуется расширением конфигурации, без правки типового кода. Это принципиально: обновляемость 1С:ERP сохраняется, ни один типовой механизм учёта не затрагивается, а подключается и отключается решение на уровне расширения. Технически блокировка перехода ордера в отгрузочные статусы выполнена в обработчике «ПередЗаписью» расширения — без вмешательства в типовой код.
Маршрут согласования: как финансовое вето встраивается в движение расходного ордера
«Отгрузка без финансового согласования — это кредит, который выдаёт не казначей, а склад»
Рабочее место казначея: всё в одном окне
Основной инструмент финансовой службы — обработка «Рабочее место для согласования отгрузки», расположенная в подсистеме «Продажи → Сервис».
По умолчанию в табличной части отображаются все несогласованные расходные ордера. Доступны отборы: по дате отгрузки, по контрагенту, по диапазону дат и флаг «Согласованные отгрузки» — чтобы вернуться и посмотреть ранее подтверждённые ордера.
Рабочее место казначея в 1С:ERP — одно окно с лимитами, задолженностью и двумя отчётами
Строки сгруппированы в три уровня:
- Контрагент — с кодом партнёра из учётной системы (в том числе кодом из внешней ERP, если выполнялась миграция).
- Расходный ордер — его статус, дата отгрузки, сумма к отгрузке, признак «Отгрузка разрешена», причина отказа (если была).
- Заказ клиента — с указанием типа расчёта: предоплата или постоплата.
Тип расчёта система определяет автоматически по виду этапа оплаты в соглашении с клиентом: этапы с видом «Аванс» или «Предоплата» трактуются как предоплата, «Кредит» — как постоплата. Если этапы оплаты не заполнены, строка подсвечивается, а причина выводится в отдельную колонку — это тоже сигнал к проверке до отгрузки.
Дальше работа финансиста сводится к двум кнопкам. «Разрешить отгрузку» переключает признак в «Истина» для выделенных строк. «Причина отказа» открывает окно, в котором вводится произвольный текст. Причина сохраняется вместе с ордером и, что важно, появляется в рабочем месте «Отгрузка» у сотрудника ордерного склада. Склад видит, почему ордер не подписан, без звонков и писем.
Два отчёта — два сценария решения
Принимать решение «разрешить или нет» в одиночку, глядя только на таблицу, сложно. Поэтому в рабочем месте доступны два специализированных отчёта — по одному на каждый тип расчёта.
Ведомость по предоплате строится по выбранному заказу клиента за период «от даты заказа до сегодня». Показывает общую сумму по заказу, сумму к отгрузке, ранее отгруженные суммы и все оплаты. Финансисту достаточно сверить, что аванс пришёл в срок и в нужном объёме — и принять решение.
Ведомость по постоплате — полностью кастомный отчёт, его в типовой 1С:ERP нет. В шапке выводятся застрахованный и внутренний лимиты клиента и три ключевые цифры: превышение страхового лимита в рублях, превышение внутреннего лимита в рублях и то же превышение в процентах. В теле отчёта — все постоплатные заказы клиента с неоплаченными реализациями и все его расходные ордера в любых статусах, кроме «Отгружен». Отдельная колонка показывает срок просроченной задолженности в днях: с минусом — сколько ещё осталось до планового срока оплаты, с плюсом — сколько дней просрочки по графику. Для заказов в иностранной валюте отчёт пересчитывает задолженность в рубли по курсу из регистра сведений «Курсы валют» организации на дату документа реализации — так сохраняется сопоставимая с лимитами рублёвая сумма.
Оба отчёта открываются одной кнопкой прямо из рабочего места и автоматически подставляют нужные отборы — финансисту не нужно каждый раз вручную выбирать контрагента и заказ.
15–30% снижение просроченной дебиторки за первые 6 месяцев
в 3–5 раз меньше отгрузок, требующих ручного «отката»
20–40 сек время решения по отгрузке вместо 15–30 минут на ручной сбор данных
6–10 недель срок внедрения командой 2–3 человека
4–9 месяцев ориентировочная окупаемость за счёт снижения безнадёжной дебиторки
Фактические показатели зависят от зрелости учёта, доли постоплатных клиентов и структуры дебиторки, но порядок цифр устойчив.
Лимиты клиентов: где они живут
Застрахованный и внутренний лимиты хранятся в отдельном периодическом регистре сведений. Ведут его бухгалтер и казначей; доступ к регистру ограничен их ролями. «Застрахованный» — сумма, покрытая страховым полисом или банковской гарантией; «внутренний» — лимит, утверждённый внутри компании. Разделение позволяет финслужбе видеть не только «формальное» превышение, но и насколько зона риска вышла за пределы страхового покрытия.
Что меняется в работе команд
Для коммерции— ничего. Продавец продолжает вводить заказы и отслеживать их статус; единственное отличие в том, что статус «К отгрузке» появится на ордере только после решения финансиста.
Для склада — появляется единый источник правды. В рабочем месте «Отгрузка» видны и признак «Отгрузка разрешена», и причина отказа. Нет разрешения — ордер не переводится в отгрузочные статусы, и сотрудник склада понимает, к кому идти за решением.
Для финансовой службы — появляется инструмент ежедневной работы с рисками. За 30 секунд казначей видит по конкретному клиенту: лимит, задолженность, просрочку в днях, новый ордер и сумму к отгрузке. Решение принимается на фактах, а не «по памяти».
Для руководства — своевременные управленческие сигналы. Накопленная задолженность с просрочкой и превышениями лимитов становится управленческим показателем, а не пост-фактум отчётом за квартал.
На что обратить внимание при внедрении
Лимиты должны быть заведены в систему до запуска рабочего места — иначе отчёт по постоплате покажет «нулевое» покрытие, и всё будет выглядеть как тотальное превышение.
Зоны ответственности стоит зафиксировать регламентом: кто именно нажимает «Разрешить отгрузку» — казначей, бухгалтер, финансовый контролёр. Техническая роль даётся обоим, но бизнес-правило должно быть одно.
Валютные заказы: если у компании своя методика переоценки (например, по курсу банка-партнёра), её нужно согласовать на этапе настройки.
Итог.Финансовое согласование отгрузок — это не «ещё одно согласование ради согласования», а встроенная точка контроля риска. Расширение для 1С:ERP закрывает её одним рабочим местом, двумя отчётами и одним скрытым признаком на расходном ордере. У клиентов, внедривших решение, мы фиксируем три устойчивых эффекта: дебиторская задолженность перестаёт расти «по инерции», просрочки фиксируются до отгрузки, а не после, и у казначея появляется ежедневный инструмент вместо квартальных «разборов полётов».
Что делать дальше
Проверьте, актуальна ли задача для вашей компании:
- Скачайте чек-лист «7 признаков, что вашей финслужбе нужно вето на отгрузку» — поможет за 5 минут понять, окупится ли внедрение.
- Запросите 30-минутное демо рабочего места — покажем на живой базе и назовём ориентировочные сроки под ваш контур 1С:ERP.
- Напишите нам на info@msp-consulting.ru — подберём сценарий пилота.
Базовая механика — служебный реквизит, рабочее место казначея и два отчёта — адаптируется под большинство конфигураций линейки. «Из коробки» готово для 1С:ERP 2.5. Для УТ/КА нужна адаптация; оценка и сроки — отдельно.
Да. Решение поставляется расширением, типовой код не правится. После выхода нового релиза 1С:ERP расширение проверяется на совместимость и переподключается.
Можно. Ведомость по предоплате и ведомость по постоплате работают как самостоятельный модуль — начать можно с них, блокировку статуса включить позже.
В периодическом регистре сведений с историей. Застрахованный и внутренний лимиты — отдельные поля; обновляются вручную бухгалтером или автоматически по обмену, если подключена интеграция со страховой компанией.
