Сценарии постобработки платежей в МоемСкладе через BankSklad
BankSklad закрывает первый слой рутины: получает платеж из банка, создает входящий или исходящий платеж в МоемСкладе, находит контрагента, расчетные счета и связанные документы. Но настоящая автоматизация начинается на следующем шаге, когда платеж не просто появился в учете, а запустил цепочку действий: получил правильную статью, статус, владельца, отдел, задачу, резерв или изменение связанного документа.
Для этого удобно использовать связку двух механизмов:
- статусы BankSklad — решение присваивает платежу нужный статус после создания, проведения, экспорта или по условию;
- сценарии МоегоСклада — штатный механизм автоматизации, который выполняет действия при наступлении заданных условий.
Сценарии — это платная опция МоегоСклада, но их функционал намного шире простого заполнения реквизитов платежа. По сути, это роботы внутри учета: они могут менять поля, статусы, владельца и отдел, создавать задачи, уведомлять сотрудников, работать со связанными документами и помогать контролировать процесс без разработчиков.
BankSklad усиливает этот механизм там, где штатным сценариям не хватает контекста банковской выписки. Например, сценарий МоегоСклада не умеет самостоятельно разобрать назначение платежа как текст банка, а BankSklad может поставить платежу уточненный статус по вхождению фразы в назначении. После этого сценарий уже работает не с длинным банковским текстом, а с понятным статусом: Дивиденды, Эквайринг, Комиссия банка, Перевод между счетами, Проверить.
Так банковский платеж превращается из строки выписки в триггер управляемого процесса.
Почему не стоит делать все вручную
Когда платежей мало, кажется, что бухгалтеру или менеджеру проще открыть документ и руками выбрать статью расходов. Но с ростом оборота ручная обработка быстро ломается:
- один и тот же контрагент каждый раз получает разные статьи;
- платежи по аренде, связи, рекламе и логистике размазываются по учету;
- менеджеры забывают менять статус заказа после оплаты;
- директор видит деньги в банке, но не видит, какие платежи уже обработаны;
- аналитика в LensSklad, DataLens или другой BI-системе строится на грязных данных.
Если правила повторяются, их лучше описать один раз. Тогда BankSklad создает платеж, при необходимости ставит промежуточный статус, а сценарий МоегоСклада выполняет уже ваши учетные правила.
Уровень 1. Сценарии МоегоСклада
Первый уровень автоматизации — обычные сценарии МоегоСклада без дополнительной логики BankSklad.
Они подходят, когда нужное условие уже есть в самом документе:
- контрагент равен конкретной компании;
- договор равен договору с отсрочкой;
- организация, склад, проект или отдел равны заданному значению;
- статус документа изменился;
- поле Оплачено (руб) изменилось;
- сумма или другое поле попадает под нужное условие.
Самый простой пример — заполнение полей платежа по стабильным контрагентам. Если одному контрагенту всегда платят за одно и то же, сценарий может работать только по контрагенту:
- арендодатель — статья расходов Аренда;
- рекламная площадка — Реклама;
- оператор связи — Телефония и интернет;
- охранная компания — Охрана;
- бухгалтерская компания — Бухгалтерия;
- курьерская служба — Логистика.
То же самое работает с входящими платежами. Если выручка от одного и того же контрагента всегда относится к понятному направлению, ее можно сразу распределять по статьям доходов, проектам или каналам продаж. Например, оптовый покупатель — Оптовые продажи, маркетплейсы по реальным названиям контрагентов вроде Интернет Решения для Ozon или РВБ для Wildberries — Маркетплейсы, отдельная сеть или дилер — свой проект или направление.
Еще один простой пример — переводы между своими счетами. Если организация и контрагент равны, это финансовая операция между счетами компании. Для нее сценарий может поставить техническую статью, проект или дополнительное поле Внутренний перевод.
Если договор у поставщика равен договору с отсрочкой 14 дней, сценарий может заполнить планируемую дату оплаты или поставить задачу на контроль оплаты к нужному сроку.
Это уже полезно: не надо каждый раз вручную выбирать статьи, проекты, отделы, владельцев и другие поля. Но у этого уровня есть ограничение: сценарии хорошо работают с полями МоегоСклада, но не решают задачу разбора банковского назначения платежа. А именно в назначении часто спрятан реальный смысл операции.
Если смысл операции меняется внутри одного и того же контрагента или договора, простого условия уже не хватает. Например, одному и тому же физлицу или сотруднику можно перечислить зарплату, премию, подотчет, компенсацию или дивиденды. Банку можно платить и тело долга по кредиту, и проценты. По одному контрагенту сценарий не поймет разницу. Нужен дополнительный слой классификации.
Уровень 2. Статусы BankSklad как слой классификации
Второй уровень — использовать BankSklad для первичной классификации платежей.
В BankSklad можно задать стандартные статусы для типовых событий:
- создание входящего платежа;
- создание исходящего платежа;
- проведение исходящего платежа;
- экспорт исходящего платежа в банк.
Дополнительно можно настроить статусы с условием: BankSklad смотрит на тип платежа, поле платежа, оператор и значение. Если условие выполняется, платеж получает уточненный статус.
Общая логика получается такой:
- BankSklad получает операцию из банка.
- Создает или проводит платеж в МоемСкладе.
- Проставляет основной статус или статус по условию.
- Сценарий МоегоСклада реагирует уже на статус платежа.
- Сценарий заполняет поля, меняет права доступа, создает задачи или переводит платеж в финальный статус.
Статусы могут быть не только финальными, но и временными. Это нормально. Например, BankSklad ставит промежуточный статус Дивиденды, а сценарий после этого:
- заполняет статью ДДС Финансовая деятельность;
- меняет владельца-сотрудника и владельца-отдел;
- ограничивает видимость платежа для лишних сотрудников;
- очищает или заполняет дополнительные поля;
- переводит платеж в окончательный статус Обработан или Закрыт.
Это сильно расширяет сценарии. Сам сценарий не умеет читать назначение платежа, но он умеет реагировать на статус, который BankSklad поставил по назначению.
Примеры таких промежуточных статусов:
| Что нашел BankSklad | Промежуточный статус | Что делает сценарий |
|---|---|---|
Назначение содержит дивиденды | Дивиденды | Заполняет финансовую статью, меняет владельца и отдел, переводит в закрытый статус |
Назначение содержит погашение основного долга | Тело кредита | Относит платеж к финансовой деятельности |
Назначение содержит проценты по кредиту | Проценты по кредиту | Относит платеж к операционным расходам |
Назначение содержит эквайринг | Эквайринг | Ставит задачу на сверку, заполняет статью доходов |
Назначение содержит комиссия банка | Комиссия банка | Заполняет статью расходов Банковские комиссии |
Назначение содержит возврат или уточнение | Проверить | Ставит задачу бухгалтеру или ответственному менеджеру |
Назначение содержит перевод между счетами | Перевод между счетами | Дополнительно уточняет внутренний перевод, если одного сравнения организации и контрагента недостаточно |
Уровень 3. Платеж как триггер цепочки действий
Третий уровень — когда платеж запускает изменения не только в самом платеже, но и в связанных документах.
Например, BankSklad создал входящий платеж, привязал его к заказу покупателя или счету. После этого в связанном документе изменилось поле Оплачено (руб). Сценарий МоегоСклада может сработать уже на этом документе:
- изменить статус заказа на Оплачен;
- заполнить дату начала производства;
- зарезервировать товар;
- создать задачу складу на сборку;
- создать задачу закупщику на закупку недостающих позиций;
- отправить уведомление менеджеру;
- подготовить следующий документ в цепочке.
В итоге банковский платеж становится событием, которое запускает продажи, закупки, производство или контроль документов. Деньги пришли — заказ перешел дальше. Деньги ушли поставщику — закупка взята в работу. Платеж попал в Проверить — сотрудник получил задачу. И все это работает по правилам, которые можно изменить без разработки.
Такой механизм точнее ручной работы: он выполняется каждый раз по одинаковым условиям, не устает, не забывает проверить платеж и не зависит от того, кто сегодня вышел на смену. А если бизнес-процесс изменился, правило можно поправить в сценарии или статусах без программиста.
Пример 1. Статьи доходов и расходов по контрагенту
Самый частый сценарий — автоматическое заполнение статьи доходов или расходов для регулярных контрагентов.
Примеры правил:
| Условие | Что поставить |
|---|---|
Контрагент содержит Ростелеком | Статья расходов: Телефония и интернет |
Контрагент содержит Яндекс или VK | Статья расходов: Реклама |
Контрагент содержит СДЭК или Деловые линии | Статья расходов: Логистика |
Контрагент содержит Арендодатель | Статья расходов: Аренда |
Контрагент содержит Охрана | Статья расходов: Охрана |
Контрагент содержит Бухгалтерия | Статья расходов: Бухгалтерия |
Контрагент содержит МойСклад | Статья расходов: Сервисы и подписки |
| Контрагент содержит название оптового покупателя | Статья доходов: Оптовые продажи |
Контрагент содержит Интернет Решения, РВБ или название другого юрлица маркетплейса | Статья доходов: Маркетплейсы |
| Контрагент содержит название дилера или сети | Проект или направление продаж этого контрагента |
| Статус BankSklad равен Комиссия банка | Статья расходов: Банковские комиссии |
Такой набор правил особенно полезен, если дальше вы строите управленческий отчет ДДС или отчет о прибылях и убытках. Данные попадают в аналитику уже нормализованными, без ручной доразметки.
Пример 2. Разделение входящих оплат
Входящие платежи тоже не одинаковые. Это могут быть оплаты покупателей, возвраты поставщиков, займы, переводы между счетами или компенсации.
Примеры:
| Условие | Статус BankSklad | Действие сценария |
|---|---|---|
Назначение содержит оплата по счету | Оплата клиента | Поставить статью доходов Выручка, изменить статус заказа на Оплачен |
Назначение содержит возврат | Возврат от поставщика | Поставить статью доходов Возвраты поставщиков, поставить задачу бухгалтеру |
| Контрагент равен организации | Перевод между счетами | Поставить техническую статью или исключить из операционной аналитики |
Назначение содержит займ | Займ | Поставить статью ДДС Финансовая деятельность |
Если платеж привязан к заказу, счету или отгрузке, сценарий может менять статус связанного документа. Например, заказ покупателя после оплаты переходит в Оплачен, а ответственному ставится задача на сборку или отгрузку.
Пример 3. Задачи для сотрудников
Не каждый платеж должен просто закрыться в учете. Иногда после оплаты нужно запустить работу.
Примеры:
- клиент оплатил счет — поставить задачу менеджеру подготовить отгрузку;
- поставщику отправили предоплату — поставить задачу закупщику проконтролировать поставку;
- пришел возврат — поставить задачу бухгалтеру проверить документы;
- прошла оплата аренды — поставить задачу приложить закрывающие документы;
- платеж попал в статус Проверить — поставить задачу ответственному разобрать назначение.
Так платеж становится не только финансовой операцией, но и триггером бизнес-процесса.
Пример 4. Эквайринг и дубли платежей
Эквайринговые поступления часто требуют отдельной логики. Если у вас уже есть решение, которое создает розничные оплаты с привязкой к физическому лицу или заказу, BankSklad может увидеть банковскую выписку и создать платеж от банка как оператора эквайринга.
Есть два рабочих подхода:
- исключить такие платежи в BankSklad, если они вообще не нужны в МоемСкладе;
- создать статус Эквайринг и сценарий сверки, если платежи нужны для контроля поступления денег на счет.
Для второго варианта можно настроить условие: назначение содержит эквайринг, оплата по картам, торговая выручка или другую стабильную фразу банка. После этого сценарий ставит статью доходов Эквайринг, ответственного и статус На сверку.
Пример 5. Переводы между своими счетами
Переводы между счетами часто засоряют уведомления и аналитику, хотя сами платежи в учете нужны.
Практичный вариант:
- В BankSklad оставить создание платежей между счетами.
- В исключениях отключить уведомления по таким операциям.
- В статусах поставить условный статус Перевод между счетами.
- В сценарии заполнить техническую статью и дополнительное поле Внутренний перевод.
Так деньги остаются в движении денежных средств, но не мешают менеджерам и не попадают в операционную выручку или расходы.
Пример 6. Дивиденды, налоги и комиссии
Некоторые платежи лучше сразу отделять от операционной деятельности.
Примеры:
| Условие | Статус | Поля |
|---|---|---|
Назначение содержит дивиденды | Дивиденды | Статья ДДС: Финансовая деятельность |
Назначение содержит НДФЛ | Налоги | Статья расходов: Налоги и взносы |
Назначение содержит страховые взносы | Налоги | Статья расходов: Налоги и взносы |
Назначение содержит комиссия банка | Комиссия банка | Статья расходов: Банковские комиссии |
Назначение содержит погашение основного долга | Тело кредита | Статья ДДС: Финансовая деятельность |
Назначение содержит проценты по кредиту | Проценты по кредиту | Статья расходов: Проценты по кредитам |
Если такие операции не нужны в МоемСкладе, их можно убрать через исключения. Если нужны для ДДС, лучше оставить платежи, но разметить их отдельными статусами и статьями.
Пример 7. Контроль ошибок и ручная проверка
Не все платежи стоит автоматически считать обработанными. Для спорных операций полезно завести статус Проверить.
Он может ставиться, если:
- контрагент не найден или создан впервые;
- назначение не содержит номера счета, заказа, договора или накладной;
- платеж пришел от неизвестного контрагента;
- сумма крупнее обычного лимита;
- назначение содержит слова
возврат,корректировка,ошибочно,уточнение.
Дальше сценарий ставит задачу бухгалтеру или ответственному менеджеру. После проверки сотрудник вручную переводит платеж в финальный статус.
Как не усложнить правила
Лучше начинать не с десятков условий, а с самых повторяемых операций:
- 5-10 регулярных поставщиков;
- переводы между счетами;
- комиссии банка;
- эквайринг;
- налоги;
- платежи клиентов по счетам;
- операции, которые нужно отправлять на ручную проверку.
Когда эти правила стабильно работают, можно добавлять более тонкие сценарии: разные статьи по проектам, ответственным, торговым точкам, складам и группам контрагентов.
Рекомендуемая структура статусов
Для большинства компаний достаточно такого набора:
- Новый платеж — платеж создан, но еще не проверен.
- Оплата клиента — входящая оплата от покупателя.
- Оплата поставщику — исходящий платеж поставщику.
- Экспортирован в банк — платеж отправлен в банк, но еще не проведен.
- Проведен банком — банк подтвердил проведение.
- Перевод между счетами — техническое движение денег.
- Эквайринг — поступления по картам.
- Комиссия банка — банковские комиссии.
- Налоги — налоги и взносы.
- Проверить — платеж требует ручного разбора.
Этот список не универсальный, но он хорошо разделяет ежедневный поток платежей на понятные очереди.
Что получится в итоге
Хорошо настроенная постобработка дает три результата:
- платежи автоматически появляются в МоемСкладе и сразу получают правильную разметку;
- сотрудники работают не с хаотичной банковской выпиской, а с понятными статусами и задачами;
- управленческая аналитика получает чистые данные без долгого восстановления истории задним числом.
BankSklad забирает на себя импорт, экспорт и первичную классификацию платежей. Сценарии МоегоСклада превращают эту классификацию в действия: заполнить поля, сменить статус, поставить задачу, подготовить документ или отправить платеж на проверку.