Построение единого операционного контура лизинговой компании на базе коробочной версии Pyrus

Ситуация на старте
Основные сведения о договорах, клиентах и предметах лизинга уже находились в 1С.
Однако наличие данных в учётной системе само по себе не решало операционную задачу.

Сотрудникам необходимо было:

• запускать процессы по конкретному договору;
• передавать работу между подразделениями;
• собирать документы;
• проводить согласования;
• контролировать оплату и поставку;
• подключать юридический отдел;
• видеть другие процессы по тому же лизингополучателю;
• сохранять историю принятых решений.

Если каждый процесс существует отдельно, информация быстро начинает дублироваться. Один и тот же ИНН, номер договора, предмет лизинга и реквизиты приходится переносить из 1С вручную в разные задачи.

При этом в работе с одним клиентом может одновременно участвовать несколько подразделений, а у самого лизингополучателя может быть несколько действующих договоров.

Поэтому задача проекта заключалась не просто в настройке форм.

Необходимо было построить в Pyrus единый операционный контур лизинговой компании, связанный с учётными данными 1С.

Почему использовали коробочную версию Pyrus
Для проекта была выбрана коробочная версия Pyrus, развёрнутая внутри инфраструктуры «МК Лизинг».
Доступ к системе и интеграциям организован через защищённый контур заказчика: VPN, двухфакторную аутентификацию и белые списки IP-адресов.

Это повлияло на всю архитектуру проекта.

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

• особенности коробочной версии Pyrus;
• требования внутренней инфраструктуры;
• порядок доступа внешних специалистов;
• ограничения конкретной версии системы;
• размещение интеграционных обработчиков;
• совместимость форм, скриптов и ботов.

В результате компания получила не облачный набор разрозненных автоматизаций, а внутреннюю систему, работающую в её корпоративном контуре.

Pyrus как операционный слой над 1С
В новой архитектуре системы получили разные зоны ответственности.
1С хранит учётные данные: договоры, реквизиты лизингополучателей, статусы, суммы и номенклатуру.
Pyrus управляет работой сотрудников с этими данными: запускает процессы, назначает ответственных, проводит согласования и сохраняет историю действий.

Такое разделение позволило не создавать в Pyrus вторую учётную систему и не заставлять сотрудников вручную дублировать сведения из 1С.

Pyrus получает необходимые данные и превращает их в рабочий процесс.

Синхронизация справочников из 1С
Для интеграции были созданы справочники Pyrus, которые автоматически наполняются данными из 1С.

Основными стали:

• «Все активные договоры»;
• «Договоры: статусы и суммы»;
• «Номенклатура»;
• «Активные договоры».

Из 1С передаются:

• уникальный идентификатор договора;
• номер и дата договора;
• ИНН, КПП и ОГРН лизингополучателя;
• полное наименование клиента;
• предметы лизинга;
• место поставки;
• место стоянки;
• статус и сумма договора;
• номенклатурные позиции.

Обмен построен через вебхуки.
Для каждого договора и элемента номенклатуры используется уникальный ключ. Если запись с таким ключом уже существует в Pyrus, интеграция обновляет её. Если нет — добавляет новую.

Благодаря этому сотрудники работают с данными, поступившими из учётной системы, а не создают собственные копии вручную.

Единая форма «Лизингополучатель»
Центральной сущностью системы стала форма «Лизингополучатель».
Её задача — объединить информацию о клиенте, его договорах и связанных процессах.
Ключом для сопоставления используется ИНН.

По указанному ИНН Pyrus находит все действующие договоры клиента и выводит их в таблицу:

• номер договора;
• дату договора;
• статус;
• сумму;
• предмет лизинга;
• место поставки;
• место стоянки.

При этом данные собираются не из одного источника.

Основные сведения о договоре поступают из справочника «Все активные договоры», а статус и сумма — из отдельного справочника «Договоры: статусы и суммы».

Связь между ними строится по уникальному идентификатору договора.

В результате Pyrus выполняет многоступенчатое сопоставление:
ИНН клиента → договоры лизингополучателя → идентификатор договора → статус и сумма → единая таблица в форме.

Так форма «Лизингополучатель» превращается в цифровой профиль клиента, собранный на основе актуальных данных 1С.

Бот для обновления договоров
На этапе реализации возникло техническое ограничение: стандартные скрипты форм Pyrus не могли полноценно работать с таблицами.

Но именно в таблице необходимо было показывать все договоры лизингополучателя.
Вместо упрощения процесса мы разработали отдельного бота.

В форме появилась кнопка «Обновить». По её нажатию бот:

1. Получает ИНН из карточки лизингополучателя.
2. Находит соответствующие записи в справочнике активных договоров.
3. Определяет все договоры клиента.
4. По идентификаторам обращается ко второму справочнику.
5. Получает актуальные статусы и суммы.
6. Перезаписывает таблицу в форме Pyrus.

Такой подход позволил сотруднику в любой момент обновить цифровой профиль клиента и получить актуальную информацию без ручной сверки с 1С.

Кнопка была выбрана осознанно: карточка лизингополучателя может долго находиться на одном этапе, поэтому обновление только при переходах не обеспечивало бы актуальность данных.

Данные из разных процессов собираются в одном профиле
Работа с лизингополучателем не ограничивается основным договором.

В течение жизненного цикла могут запускаться отдельные процессы:

• передача предмета лизинга;
• реструктуризация;
• цессия;
• отмена пеней;
• инкассо;
• изъятие;
• внесудебное изъятие;
• другие юридические и операционные процедуры.

Каждый такой процесс существует как самостоятельная форма Pyrus со своим маршрутом и участниками.
Но его результат должен попадать в общую карточку клиента.

Для этого была спроектирована передача данных из связанных форм в форму «Лизингополучатель». Система сопоставляет записи по ИНН и обновляет соответствующие поля.

При этом учитывается тип данных:

• если поле множественное, новое значение дополняет существующую информацию;
• если поле одиночное, актуальное значение заменяет предыдущее.

Например, из процесса отмены пеней можно передать номер договора и зафиксировать принятое решение. Из инкассо — результат работы. Из процесса цессии — решение комитета и данные нового лизингополучателя. Из процедуры изъятия — способ и результат возврата имущества.

В результате отдельные процессы не распадаются на независимые задачи. Их итоги постепенно формируют единую историю работы с клиентом.

Полный маршрут лизинговой сделки
Одной из наиболее объёмных форм стал процесс продажи и оформления лизинговой сделки.

В Pyrus был выстроен маршрут, охватывающий основные этапы:
Запуск → Заполнение информации → Сбор необходимых документов → Согласование условий с лизингополучателем → Сбор дополнительных документов → Утверждение поставщика → Подготовка документов → Согласование с юристами → Получение аванса → Подписание документов → Оплата поставщику → Поставка предмета лизинга → Подготовка к передаче → Страхование → Передача предмета лизинга → Передача документов → Проведение сделки в бухгалтерии → Перевод в статус «Лизинг» → Закрытие формы.

Маршрут не является строго линейным.
Он меняется в зависимости от параметров сделки:

• согласованы ли условия;
• требуются ли дополнительные документы;
• необходимо ли подключать юристов;
• внесён ли аванс;
• находится ли предмет лизинга в наличии;
• требуется ли страхование.

Pyrus направляет заявку по нужной ветке и подключает соответствующих участников: автора, юристов, бухгалтерию, коммерческого директора и другие роли.

Сотрудник видит не абстрактный статус договора, а конкретный этап фактической работы.

Зависимые формы вместо перегруженной карточки
Для отдельных действий были созданы связанные процессы:

• «Заявка на согласование»;
• «Заявка на оплату»;
• другие зависимые формы.

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

Аналогично работает согласование договора при продаже через интернет или Avito:
основной процесс → заявка на согласование → рассмотрение документа → возврат согласованного файла → продолжение сделки.

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

Двусторонняя синхронизация связанных форм
При создании зависимой формы данные передаются из основной задачи автоматически.
После завершения подпроцесса результат возвращается обратно.

Таким образом работает двусторонняя связка:
основная форма передаёт исходные данные → подразделение выполняет свою часть процесса → итоговые поля и документы возвращаются в основную форму.

Сотрудникам не приходится повторно вводить номер договора, данные клиента и другие уже известные параметры.

Это особенно важно для финансовых и юридических процессов, где ошибка при ручном переносе информации может повлиять на дальнейшую работу со сделкой.

Автозаполнение данных по договору
В нескольких формах была настроена автоматическая подстановка данных из справочников.
Сотрудник указывает ИНН, поставщика или другой ключевой параметр, после чего Pyrus находит связанные договоры и заполняет необходимые поля.

Отдельная логика потребовалась для ситуаций, когда у одного клиента или поставщика есть несколько договоров.

Пользователь указывает необходимое количество, система выводит соответствующее число договоров, после чего сотрудник выбирает нужный.

Такая автоматизация сокращает ручной ввод и помогает использовать единые значения во всех процессах.

Маршрутизация по инициатору и ролям
Часть маршрутов зависит не только от типа задачи, но и от того, кто её запустил.
Например, заявки разных подразделений могут направляться разным руководителям: генеральному или коммерческому директору.

Эта логика была реализована штатными средствами Pyrus.

Также в процессах используются:

• ответственные по умолчанию;
• роли подразделений;
• рабочие графики;
• контроль времени этапов;
• правила передачи между участниками.

Маршруты строятся вокруг функций, поэтому при изменении состава команды не требуется переделывать всю систему.

Юридические и проблемные процессы
Отдельный пласт работы связан с ситуациями, которые возникают уже после оформления основного договора.
Реструктуризация, цессия, отмена пеней, взыскание или изъятие имущества требуют участия разных подразделений и отдельной фиксации решений.

Для таких случаев в Pyrus были предусмотрены самостоятельные формы.

Менеджер по сопровождению или сотрудник отдела оформления запускает нужный процесс, указывает договор и заполняет исходную информацию. Далее задача проходит установленный маршрут, а результат передаётся в профиль лизингополучателя.

Также прорабатывалась отдельная форма для юридического отдела по подготовке исковых заявлений.
Таким образом Pyrus охватывает не только оформление новой сделки, но и дальнейшие события на всём жизненном цикле договора.

Работа в условиях технических ограничений
Проект потребовал учитывать ограничения коробочной версии Pyrus:

• максимальное количество этапов;
• отсутствие работы скриптов с таблицами;
• различия между облачной и коробочной версиями;
• необходимость доступа через защищённый контур;
• зависимость части возможностей от обновлений вендора.

Каждое ограничение рассматривалось как архитектурная задача.

Длинные процессы разделялись на основную и зависимые формы. Для работы с таблицей вместо скрипта использовался бот. Данные из нескольких справочников объединялись по уникальным ключам.

Это позволило сохранить бизнес-логику без попытки уместить всё в одну перегруженную форму.

Что получила компания
В результате «МК Лизинг» получила внутреннюю процессную систему, связанную с данными 1С.

В Pyrus были объединены:

• оформление лизинговой сделки;
• согласование условий и документов;
• заявки на оплату;
• работа с поставщиками;
• передача и страхование имущества;
• реструктуризация и цессия;
• отмена пеней;
• взыскание и изъятие;
• юридические процессы;
• единый профиль лизингополучателя.

Сотрудники используют актуальные сведения из 1С и не переносят одни и те же данные вручную в каждую задачу.

Руководители могут видеть, на каком этапе находится работа, кто отвечает за следующий шаг и какие решения уже принимались.

А отдельные процессы сохраняют связь с основным клиентом и договором.

Итог
Кейс проекта «МК Лизинг» показывает, как Pyrus может стать операционным слоем между учётной системой и сотрудниками компании.

1С продолжает хранить договорные и справочные данные. Pyrus превращает эти данные в управляемые процессы: согласования, оплаты, юридические процедуры, передачу имущества и сопровождение договора.
Центральная форма «Лизингополучатель» объединяет действующие договоры и результаты процессов по ИНН клиента. Интеграция со справочниками 1С поддерживает актуальность информации, а разработанный бот собирает данные из нескольких источников в единую таблицу.

Коробочное размещение позволило сохранить систему внутри инфраструктуры заказчика, а связка основных и зависимых форм — реализовать длинный маршрут сделки без перегрузки одной карточки.

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