Про наш финансовый отдел и собственную CRM

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

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

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

Roninapp

Для создания счетов использовали Ronin ^[1].
С его помощью мы:

• хранили список услуг, в которые были прописаны макросы для 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</-- artikul --></-- 1c -->"

1С работала по следующей схеме:

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

Админка сайта centos-admin.ru

1С решила не все проблемы — приходящие от клиентов платежи нужно как-то учитывать.

Недостающий функционал добавили в админку centos-admin.ru ^[2].

Следующие фичи легли на плечи Ruby on Rails, который используется в качестве бэк-енда для сайта:

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

Все платежи создавались не только в базе сайта, но и отправлялись в Ronin. С Ronin же брались данные о счетах и клиентах.

Зачем же было что-то менять, когда всё так здорово настроили?

В этой схеме главным узлом был Ronin, а с ним независимо синхронизировались 1С и сайт.

Был ряд недостатков:

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

Решение

Работу бухгалтера передали сервисам «Эльба» и «Диадок» и теперь с радостью рекомендуем ^[3] нашим клиентам.

Остальной функционал Ronin, 1С и сайта решили объединить в собственной CRM-системе. Сперва перенесли с сайта прием платежей, обработку выписок и графики. Потом реализовали у себя функционал Ronin так, чтобы обойтись без 1С .

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

Через пару месяцев после запуска системы стали периодически повторяться одни и те же грабли — то срочно нужно добавить какую-то фишку ради клиента, которому нужно выписать счет на английском, то решим упростить логику, убрать лишний код и поля из базы. Вроде всё учитываешь, выкатываешь в продакшен, всё работает как надо, но вдруг какая-то редко используемая функция вылетает с багом как раз тогда, когда она понадобилась.

На баг пишется тест, баг исправляется, и свежий код снова в продакшене. Так количество тестов росло. В настоящий момент все тесты прогоняются минут за 7.

Бывает, пренебрегаем тестами, когда несколько релизов в день. Иногда выяснялось — зря. Приходилось срочно фиксить то, что можно было пофиксить до деплоя, если бы запустили тесты.

После пары таких ситуаций и решили внедрить CI. Благо в Gitlab ^[4], который мы используем для хранения кода, эта фича подаётся из коробки.

В следующей статье расскажем, как настраивали Gitlab CI ^[5], а после поделимся тем, что из этого вышло.

Автор: Centos-admin.ru

Источник ^[6]