The last few months we have been going on the huge task of billing automation in  

In fact, this task is even more extended:

  • We have long needed a place that takes into account all client entities in service, and it should not be Salt, which was not suitable for this (pillar parsing is complicated, pillars are not available without a minion, etc.).
  • In addition to sending by mail, invoices still need to be printed on a printer.
  • It was necessary to automate the calculation of the hourly share of employees.
  • There was no accounting system for the occupied space on backup servers, which also needed to be done.
  • We should be able to use the accounting system for further automation.
  • Documents that are created should be based on a clear template appearance.
  • There was no direct connection between the servers in real technical accounting and the billing account for the client.

Also, this issue was one of the key ones for the possibility of further expansion.

Basically the task was completed successfully:

  • Three types of invoices are issued to clients: prepayment for a monthly subscription, hourly, for the storage occupied on our servers.
  • It takes about an hour to generate all invoices and send letters and documents to the printer. Unless, of course, there are no specific accounting questions from clients.
  • Templates based on Google Docs are used.
  • An additional document has appeared in addition to invoices and acts: details – a table that gives customers details about servers, hourly work, storage occupied.
  • Changes in the technical accounting of servers are automatically reflected in the invoices for clients.
  • All information about client servers is finally taken into account with 100% accuracy.

Here are some interesting facts about the project:

  • Part of the project logic for working with the GSuite API has been moved to the open source repository
  • The generated invoices are automatically added into the Google accounting table, where, incl. the performer’s share is automatically calculated.
  • The document goes through the following chain: the necessary Google Doc template is copied to the client’s folder, it is given the necessary name, the lines of the table are filled in, the details are filled in, pdf is generated, the pdf is sent for printing to a remote printer, a draft letter is created to the client with an attachment with documents.
  • It supports work with different merchants, a merchant can have payment with a card and create orders through the WooCommerce API on our website.
  • In the course of the script, hundreds of requests are generated to the Google api, but it seems that as long as this happens in one thread, this does not lead to any problems. For many months of development and already work in the production, the timeout occurred literally once.
  • The system generates a tab in the mail envelope window to indicate the recipient’s address.
  • The system looks at unpaid invoices by client/account type and, if any, modifies the text of the letter, indicating that there are unpaid invoices + adds archives with these documents.
  • Since some clients pay much in advance, you can specify in the yaml for which period invoices can be generated.
  • The system calculates a partial coefficient for servers that appeared in the middle of the month.
  • In the customer’s yaml, you can indicate whether it is necessary to send an invoice / act to the post office / in paper form.
  • All remnants of billing information have been removed from the pillars in salt.
  • The cron script once a day goes via ssh to the necessary servers and collects the occupied storage with the du command.
  • Occupied storage can be collected several times a day – the information will be averaged.
  • The storage occupied by not a full month will be calculated in proportion to the number of days occupied.
  • In the process of storage billing, we put things in order in client backups on our servers.
  • Hourly time can now be collected from several client projects in our gitlab (for example, tasks and a project with code).
  • In the global yaml, at the merchant level, even such subtleties as the currency symbol and symbols for dividing thousands and cents, date formats are played up.
  • The task consisted at the time of development of 12 pages of sub-items.
Share this post