About our financial department and our own CRM

This is the first article in the series on how we have implemented 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 finance department worked before.

Previously, we used this 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 for 1C were registered
• manually and automatically created accounts
• fixed payment

But Ronin had a number of flaws:

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

1C

From part of the deficiencies saved 1C. She can:

• create documents according to Russian standards
• generate signed and stamped pdf
• form a stack of documents for printing
• print the address of the recipient, 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 the period of the service and the contract data, the product name on the Ronin side had to add macros, 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</-- artikul --></-- 1c -->" 

1C worked as follows:

• periodically loaded accounts from Ronin
• The 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 in and formed

Admin site centos-admin.ru

1C solved not all problems - payments coming from customers need to be somehow taken into account.

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

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

• registration of payments e. in money
• processing bank statements and creating payments based on them
• executive schedules
• work with receivables - reminders to customers about payment

All payments were created not only in the base of the site, but also sent to Ronin. With Ronin, billing and customer data was taken.

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

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

There were a number of drawbacks:

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

Decision

The work of the accountant was transferred to the services of "Elba" and "Dyadok" and now we are happy to recommend to our clients.

The rest of the functionality of Ronin, 1C and the site decided to combine in its own CRM-system. First moved from the site accepting payments, processing statements and graphics. Then they implemented the Ronin functionality in order to do without 1C.

If possible, they wrote tests, but not always and not everywhere, as 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 launch of the system, the same rakes were periodically repeated - something urgently needs to be added for the sake of the client who needs to issue an invoice 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, you 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 again in production. So the number of tests grew. Currently, all tests are run in 7 minutes.

It happens, we neglect the tests, when several releases per day. Sometimes it turned out - in vain. We had to urgently fix what could be fixed before deployment, if we had run the tests.

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

In the next article, we’ll tell you how to set up Gitlab CI , and then we ’ll share what came of it.