Invoice Tool & Service

Generating invoices from templates

If you are self-employed and offer your services, you also need to write invoices for it and sent them to your client. In my personal environment I know someone which needed to be self-employed (sprot trainer) to offer his work for sport studios.
The important problem was, that this person is not fit at the computer. Writing invoices and sent them to the clients was a big chellange. The editing of a template was a big problem as it was sometimes not known which key on the keyboard does what. Often the layout of the template was changed because for example not the date of the invoice was removed, but the text around.
There are professional applications to make invoices for your activities, but possible the using of such a program is also or much more difficulty. To ask a other person to do the task is on the one hand time-consuming for the person and on the other hand not good schedulable, because the jobs are random.
So the task was to make it possible for the person self to make invoices and not change the template on each time. And every time if a new invoice was wrote only some key points needed to be changed. A professional application is not possible to make this so easy as required.
I thought about that it should be possible to create a special software solution for this problem to solve it. The target platform was Windows. And of my work I know it is possible to instrument application of Microsoft Office using thier COM interfaces to create / edit documents programatically. But I had no experiences with it. But at the same time I got some experiences in LaTeX and had ideas how to create invoices using a new template.

Concept of the application system

The user needs to do everything on a Windows computer. So it was a requirement to develop a application for Windows. I can make applications using VB.NET for Windows without research (it should be completed very fast).
For using LaTeX I had experinence on Linux environments. There are also LaTeX compiler for Windows, but I had no experience with any of them. Another reqirement of the process was, that the compile of the LaTeX must be done in background as a subprocess of the application. This can easy be done using a makefile, but I have no experiences how this can be used for the Windows platform. Also I had no idea, how I can make the creation of PDF files from the output on Windows.
Another requirement was to persistent store informations about the created invoces and the used addresses.
So I personally tend to a build in Linux. One possible solution for this could be to install LaTeX into a WSL environment on the Windows system. But the maintenence will get more difficulty to realize with any more software component on this computer, as I don't have access to this computer all times. So I decide that the components of the service will be installed inside of a LXC container on my Proxmox server und on the computer of the user only a client application.
So on the container there is the "Invoice Service" installed, a Python Flask based application server. This service has API calls to query or update data on the database. Also does ths service run the "make" process for LaTeX. To have the template variable in the required data fields, the service writes "\newcommand" statements into a Tex include file, which it got from the database. A webserver is in the middle as a proxy and allows to download the PDF files from a HTTP path from this server.
On the Windows PC is only the so called "Invoice Tool" installed. It excanges data between it self and the server using the API calls, sometimes in JSON format. The "build" of a invoice is realised in mutiple steps by calling the API and after that downloading the file from the webserver.

Invoice Service

The Invoice Service is developed using Flask and hosts the API calls for the Invoice Tool. It is installed inside of a Linux container together with the LaTeX environment. The database is installed on a other system.
For mainenance of the system all components of the service are installed on a LXC, instead of installing them into WSL.
The service allows transparent access to the data in the database through the API calls. This makes it possible to do all query and update operations on the data by calling the functions on the service (and provide the required data / arguments). The execution of the actions are invoked by the service. As the Windows tool all time need to excange data with the service and the service also requires to access data on the database, all accesses are encapsulated through the service. Some combined data structures are excanged in the JSON format.
By the API it is possible to have access to the addressbook and the table of created invoices.
If a new invoice should be "build", the Windows tool transmits the data for the invoice. The service stores the data in the database and confirms this with a text status. The tool calls in the second step the "make" API call which writes the given data from the invoice into a Tex file. After that, "make" will bo executed as a subprocess to build the PDF file "Makefile controlled". The build file will be copied to webserver home. The tool should get the PDF file, by downloading it from the webserver.
A logfile is created for the whole make process, including the logfile content from the LaTeX compiler logfile to have details if a error correction is required.

Invoice Tool

On startup of the Invoice Tool there is a table with all older created invices. From there it is possible to open the addressbook, where it is possible to add, update or delete addresses.
A address includes the postal address and also a E-Mail address field if the client requests to sent the invoice in as a PDF file via E-Mail.
If the user whants to generate a new invoice, he comes to the dialog shown in Picture 2Picture 2. In the left half of the form the user sees a virtual implied invoice sheet. The values of this invoice are setted in the right half of the form. If a setting on the right is changed then on the left half of the virtual invoice the change is applied. The total price of the invoice is recalculated and written to the virtual invoice if the number of trainings or the price per unit changes.
Anything in the UI of the Invoice Tool is made magnified to prevent reading problems. The labels give hints for the user how to edit the data as this is sometimes not clear (not only because of the Invoice Tool). Also the application uses a logfile to trace what happens when using the application, because the user will not be capable to describe the error.
If the user clicks on the save button, the user gets presented a dialog which reminds the user to have the reqired fields edited. If this dialog gets confirmed then the Invoice Service gets called in the reqired steps, to generate the invoice. After the generation was done by the service the file will be downloaded by the tool from the webserver and stored to a static path.

After the build process is completed all dialog boxes are closed and the other dialog of Picture 3Picture 3 is shown to the user. It's purpose is to show the PDF file to the user and can also be opened for a invoice from the main window. From this form and also from the main form with the table the user can print out and send the invoice via E-Mail (if a mailaddress is setup for the client).

End of development

The work on the Invoice Service and the Invoice Tool ended because at this time the person, which is the only one user of the application, makes the decision to end working in his job. Unfortunately this decision was at the point were the application was after the first milestone.
In the first milestone the application should just be able to build invoices, so it would be possible to agree upon the development of the application with the user and make tests.
The next milestone should include the support to print out the build invoice and/or send it using Microsoft Outlook. In this case the use of Outlook was planned because it is on the one hand the default mail client and on the other hand the sending mail a mail by Outlook results that the mail is copied into the "sent" folder of the mailbox. Another way to send the mail was to use the SMTP client from the .NET Framework, but then the mail is not copied to the "sent" folder. So I enabled the tool to access Outlook, create a new mail object as a tamplate (as long as there is a mail address set) and add sender address, recipient address, subject, a mail text and also the PDF file as a attachment. If this presetting is ok, the user must then only click on the "send" button in the Outllok window.
All of these developments were done and tested in my test environment (IDE and a virtual machine including the required dependencies) and they seem to work. Now I waited for a test with a real world invoice and a real mail address. But at this time there was the decision to end the work that was the source for the development of the Invoice Service. So I needed to stop also the work on this system without having tested the functions of the second milestone outside of my test environment.