Pull to refresh
70.42
Слёрм
Учебный центр для тех, кто работает в IT

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

Reading time 3 min
Views 8.9K

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


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


image


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


Roninapp


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


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

Но у Ronin был ряд недостатков:


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


От части недостатков избавила 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.


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


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

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


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


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


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


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

Решение


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


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


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


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


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


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


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


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

Tags:
Hubs:
+11
Comments 5
Comments Comments 5

Articles

Information

Website
slurm.io
Registered
Founded
Employees
51–100 employees
Location
Россия
Representative
Антон Скобин