Про наш фінансовий відділ і власну CRM

Це перша стаття з серії про те, як ми впровадили безперервну інтеграцію в процес розробки 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, а після поділимося тим, що з цього вийшло.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.