Получение предоплаты по заказу
Что это за процесс
Этот процесс описывает путь от заключения сделки до фактического получения или потери предоплаты. Он начинается с события «Заключена сделка» и завершается одним из двух исходов: «Предоплата получена» или «Предоплаты не будет». Схема покрывает все этапы взаимодействия с клиентом: выставление счёта, ожидание оплаты, контроль сроков и финальное отражение движения денежных средств.
Как читать эту схему
В основе процесса лежит эксклюзивный шлюз, который проверяет, будет ли клиент оплачивать счёт. Если ответ «Нет», процесс завершается событием «Предоплаты не будет». Если «Да», запускается цепочка действий по оформлению счёта и отправке документов клиенту. Далее включается событийный шлюз, который ждёт одного из трёх триггеров: поступления сообщения об оплате, истечения срока действия счёта или таймера «За 2 дня до истечения срока». Таймер «Каждые N часов в течении рабочего дня» используется для периодических проверок или напоминаний. Финальное решение принимается на основе условного события «Оплата поступила на счёт», после чего запускается смежный процесс «Отражение движения ден. средств по счетам».
Кому подойдёт
Схема актуальна для отделов продаж, бухгалтерии и финансовых контролёров, работающих с B2B-клиентами. Она подходит компаниям, где оплата по предоплате является обязательным условием начала работ или отгрузки товара, и где важно строго контролировать сроки действия счетов.
Как адаптировать под свою компанию
- Замените абстрактные таймеры «Каждые N часов» и «За 2 дня» на реальные значения, соответствующие вашим договорным срокам.
- Добавьте конкретные роли исполнителей к задачам «Оформить счёт» и «Отразить поступление», чтобы избежать путаницы в ответственности.
- Уточните каналы коммуникации в задаче «Отправить документы клиенту» (email, личный кабинет, мессенджер).
- Настройте интеграцию с банковской системой для автоматического запуска события «Оплата поступила на счёт», исключив ручной ввод выписки.
- Определите, кто именно принимает решение в случае истечения срока действия счёта: продлевать его или закрывать сделку.
Типичные ошибки
Частая ошибка — игнорирование сценария «Предоплаты не будет», из-за чего процесс висит в воздухе, если клиент молчит. Другая проблема — отсутствие чёткого разделения между отправкой документов клиенту и внутренним отражением движения средств, что приводит к рассинхронизации данных в CRM и бухгалтерии. Также часто забывают про таймер напоминания «За 2 дня до истечения срока», теряя возможность спасти сделку до её закрытия.
Какие элементы BPMN здесь использованы
Нажмите на элемент, чтобы разобраться, что он означает и когда его применяют.
Где этот процесс в архитектуре
Отраслевые реестры, в деревьях которых встречается этот процесс — полезно, если описываете компанию целиком, а не одну схему.
Частые вопросы
Что происходит, если клиент не отвечает на счёт?
Процесс ждёт события таймера «Истёк срок действия счёта». После этого срабатывает ветка «Предоплаты не будет», и сделка закрывается без оплаты.
Как система узнает, что оплата прошла?
Используется условное событие «Оплата поступила на счёт». В идеале оно должно триггериться автоматически из банковской выписки, но в схеме также есть шаг ручной загрузки выписки.
Зачем нужен таймер «Каждые N часов»?
Он служит для периодического контроля статуса оплаты или отправки напоминаний клиенту в рабочее время, пока счёт ещё действителен.
Кто отвечает за отражение движения денежных средств?
Это задача смежного процесса «Отражение движения ден. средств по счетам». Обычно её выполняет бухгалтер или финансовый аналитик после подтверждения поступления.
Можно ли продлить срок действия счёта?
В текущей схеме нет явного шага продления. При истечении срока процесс завершается неудачей. Для продления нужно добавить ветку с созданием нового счёта.
Что значит событийный шлюз в этом процессе?
Это точка, где процесс ждёт одно из нескольких событий: сообщение от клиента, таймер напоминания или фактическое поступление денег. Как только происходит одно из них, процесс идёт дальше по соответствующей ветке.



