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

в 4:50, , рубрики: 1c, agile, agile development, continuous integration, CRM, CRM-системы, finance, optimization, roninapp, бизнес-модели, Блог компании centos-admin.ru, управление разработкой, метки:

Это первая статья серии о том, как мы внедрили непрерывную интеграцию в процесс разработки 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, а после поделимся тем, что из этого вышло.

Автор: Centos-admin.ru

Источник


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js