About our finance department and our own CRM

This is the first article in a series about how we introduced continuous integration into the CRM development process and made life easier for the finance department.

Before describing the technical details, I’ll talk about the prerequisites for developing the system and how the financial department worked earlier.

Previously, we used such a structure to automate technical processes in the financial department.

Roninapp

To create accounts used Ronin .
With it, we:

• stored the list of services in which macros were registered for 1C
• manually and automatically created invoices
• fixed payment

But Ronin had a number of disadvantages:

• it is a foreign service, so there are no required invoice templates
• he does not know about acts, reconciliations and bank statements
• data on the contract and the period of the provision of services are not substituted in the account position
• payments to accounts had to be linked either manually or in another way (we will also mention it soon)

1C

1C saved some of the shortcomings. She can:

• create documents according to Russian standards
• generate PDF with signature and stamp
• to form a stack of documents for printing
• print the recipient's address, getting into the window of the Russian envelope
• be a backup for Ronin (or vice versa)
• store data on contracts and counterparties

In order for 1C to generate beautiful accounts with a period of service and contract data, macros were added to the product name on the Ronin side, which were then processed on the 1C side:

"Администрирование серверов Июня 2016 года<-- 1c -->Администрирование серверов {#month#+1} {#year_of_month#+1} по договору № #contract_num# от #contract_date\#{#act_month#+1}<-- artikul -->support"

1C worked according to the following scheme:

• billing from Ronin periodically
• documents generated based on Ronin data were sent to customers by email. mail
• based on manually duplicated customer data, envelopes and print documents were filled and formed

Site admin centos-admin.ru

1C did not solve all the problems - payments from customers need to be taken into account somehow.

The missing functionality was added to the centos-admin.ru admin panel .

The following features fell on the shoulders of Ruby on Rails, which is used as a back-end for the site:

• registration of payments e-mail money
• processing bank statements and making payments based on them
• schedules for the head
• work with receivables - reminders to customers about payment

All payments were created not only in the database of the site, but also sent to Ronin. With Ronin, data on accounts and customers was taken.

Why was there something to change when everything was so cool set up?

In this scheme, the main node was Ronin, and 1C and the site were independently synchronized with it.

There were a number of disadvantages:

• with any changes to Ronin it was required to modify the loading modules from the site and from 1C
• I had to maintain the relevance of 1C for reporting
• complexity of refinement, more like crutches
• an accountant worked with 1C - she is a good person, but we have fairly simple bookkeeping to keep a specialist on staff

Decision

The work of the accountant was transferred to the services of Elba and Diadoc, and now we are happy to recommend it to our clients.

The rest of the functionality of Ronin, 1C and the site decided to combine in their own CRM-system. First, we transferred payments, processing statements and schedules from the site. Then they implemented the Ronin functionality in such a way as to do without 1C.

If possible, they wrote tests, but not always and not everywhere, because I wanted to get rid of crutches as soon as possible and start using my full-fledged system. For this, they even took an additional developer to the team.

A couple of months after the system started up, the same rake began to be repeated periodically - we urgently need to add some kind of chip for the client who needs to write an account in English, then we decide to simplify the logic, remove the extra code and fields from the database. It seems that you take everything into account, roll it out into production, everything works as it should, but suddenly some rarely used function crashes with a bug just when it was needed.

A test is written on the bug, the bug is fixed, and the fresh code is back in production. So the number of tests grew. Currently, all tests run in about 7 minutes.

It happens that we neglect the tests when several releases a day. Sometimes it turned out - in vain. I had to urgently fix what could have been fixed before the deployment, if they had run the tests.

After a couple of such situations, we decided to implement CI. Fortunately, in Gitlab , which we use to store code, this feature comes out of the box.

In the next article we will tell you how to configure Gitlab CI , and then share what came of it.