Про наш финансовый отдел и собственную CRM
Это первая статья серии о том, как мы внедрили непрерывную интеграцию в процесс разработки CRM и облегчили жизнь финансовому отделу.
Прежде, чем описать технические подробности, расскажу о предпосылках к разработке системы и о том, как финансовый отдел работал раньше.
Раньше для автоматизации технических процессов в финансовом отделе мы использовали такую структуру.
Roninapp
Для создания счетов использовали Ronin.
С его помощью мы:
- хранили список услуг, в которые были прописаны макросы для 1С
- вручную и автоматически создавали счета
- фиксировали оплаты
Но у Ronin был ряд недостатков:
- это иностранный сервис, поэтому нет нужных шаблонов счетов
- он не знает про акты, сверки и банковские выписки
- данные о договоре и периоде оказания услуг не подставляются в позицию счета
- платежи к счетам приходилось привязывать либо вручную, либо другим способом (его мы также скоро упомянем)
1С
От части недостатков избавила 1С. Она может:
- создавать документы по российским стандартам
- генерировать PDF с подписью и печатью
- формировать пачку документов для печати
- печатать адрес получателя, попадая в окошко российского конверта
- быть бэкапом для Ronin (или наоборот)
- хранить данные о договорах и контрагентах
Чтобы 1С генерировала красивые счета с периодом оказания услуги и данными договора, в наименование товара на стороне Ronin приходилось дописывать макросы, которые потом на стороне 1С обрабатывались:
"Администрирование серверов Июня 2016 года<-- 1c -->Администрирование серверов {#month#+1} {#year_of_month#+1} по договору № #contract_num# от #contract_date\#{#act_month#+1}<-- artikul -->support"1С работала по следующей схеме:
- периодически загружались счета из Ronin
- сформированные на основе данных Ronin документы отправлялись клиентам по эл. почте
- на основе продублированных вручную данных клиентов заполнялись и формировались конверты и документы на печать
Админка сайта centos-admin.ru
1С решила не все проблемы — приходящие от клиентов платежи нужно как-то учитывать.
Недостающий функционал добавили в админку centos-admin.ru.
Следующие фичи легли на плечи Ruby on Rails, который используется в качестве бэк-енда для сайта:
- регистрация платежей эл. деньгами
- обработка банковских выписок и создание платежей на их основе
- графики для руководителя
- работа с дебиторской задолженностью — напоминания клиентам об оплате
Все платежи создавались не только в базе сайта, но и отправлялись в Ronin. С Ronin же брались данные о счетах и клиентах.
Зачем же было что-то менять, когда всё так здорово настроили?
В этой схеме главным узлом был Ronin, а с ним независимо синхронизировались 1С и сайт.
Был ряд недостатков:
- при любых изменениях в Ronin требовалось дорабатывать модули загрузки со стороны сайта и со стороны 1С
- приходилось поддерживать актуальность 1С для формирования отчетности
- сложность доработки, больше похожей на костыли
- с 1С работала бухгалтер — она хороший человек, но у нас довольно простая бухгалтерия, чтобы держать специалиста в штате
Решение
Работу бухгалтера передали сервисам «Эльба» и «Диадок» и теперь с радостью рекомендуем нашим клиентам.
Остальной функционал Ronin, 1С и сайта решили объединить в собственной CRM-системе. Сперва перенесли с сайта прием платежей, обработку выписок и графики. Потом реализовали у себя функционал Ronin так, чтобы обойтись без 1С .
По возможности писали тесты, но не всегда и не везде, так как хотелось поскорее избавиться от костылей и начать пользоваться своей полноценной системой. Для этого даже взяли дополнительного разработчика в команду.
Через пару месяцев после запуска системы стали периодически повторяться одни и те же грабли — то срочно нужно добавить какую-то фишку ради клиента, которому нужно выписать счет на английском, то решим упростить логику, убрать лишний код и поля из базы. Вроде всё учитываешь, выкатываешь в продакшен, всё работает как надо, но вдруг какая-то редко используемая функция вылетает с багом как раз тогда, когда она понадобилась.
На баг пишется тест, баг исправляется, и свежий код снова в продакшене. Так количество тестов росло. В настоящий момент все тесты прогоняются минут за 7.
Бывает, пренебрегаем тестами, когда несколько релизов в день. Иногда выяснялось — зря. Приходилось срочно фиксить то, что можно было пофиксить до деплоя, если бы запустили тесты.
После пары таких ситуаций и решили внедрить CI. Благо в Gitlab, который мы используем для хранения кода, эта фича подаётся из коробки.
В следующей статье расскажем, как настраивали Gitlab CI, а после поделимся тем, что из этого вышло.
