We carry out the invoicing management as an extension of an application initiated by us and detailed in the section “Management for Occupational Risk Prevention Contracts” and also, in the section “Documentary management for Occupational Risk Prevention Contracts”.
Invoicing management was developed to invoice prevention contracts as automatically as possible. As we already have the contract and invoicing data for each client in the application, we only need to invoice the contracts that are renewed.
The contracts include the start and end date of each contract, so we can make a predictive work, to facilitate the renewals and consequently, invoice.
Therefore, the programme proposes which clients have to renew their contracts and which invoices have to be made. Then, as an administrative task, you must go over what the programme proposes and accept or not what is appropriate.
In addition, the programme allows for the independent billing of other contracts and/or services not related to occupational risk prevention.
Invoicing management is complicated because each client has different payment methods, and because our client, required us to make an invoice at each due date, in order to distribute the tax costs. This implies that each invoice details all related invoices (pending and paid).
The programme also allows for electronic invoicing, and all the complete management involved in the invoicing process (making pro-forma invoices, duplicating invoices, correcting invoices, making bank receipts to 19XML norm, etc.) and the monitoring process of collections/payments.
Finally, the programme links up with another Medical Prevention programme, in order to be able to invoice for health monitoring services, and carries out data transfers to our client’s SAP accounting programme.
Another important feature is that the contract and document management application is made as a web application, so that it is accessible to all delegations through any browser. However, the invoicing application was made as a desktop application, so that it was only installed on some computers. This means that in reality two applications coexist, interrelated to each other, sharing the same database. In this way, the web application does all the preparation for the billing process and the desktop application does all the billing process.
Here is the web application in detail:
For the new billing process, we had to completely remodel the existing application, making changes in all areas. By expanding fields, or restructuring the initial approach of each section, and changing the final design.
The Company Data sheet was extended with more fields, some of which are necessary for electronic invoicing:
The Delegations/Centres section was redesigned and extended, adding a new section for contracts which are not for the occupational risks prevention (No ORP). Below is an image with the file for a delegation or customer centre. That is, in this section, all the delegations or centres of each client are introduced, their contacts, their data for invoicing, the data relating to their prevention contracts and the data relating to the non prevention contracts:
The sub-formulary referring to the company’s Contacts, did not change so much. This section includes the contacts that will sign the contracts, as well as the people with whom you have a relationship, for the management of labour risks:
The Invoicing Data section was extended to establish up to four different forms of payment, which can be used for concepts related to Technical Specialities, Health Vigilance, Non-ORP concepts and Variable concepts.
This section also establishes the address to send the invoice, if it is a different address from the one we have in the Company Data section (fiscal address). You can also establish the way of printing the invoice (on paper, in PDF, by EDICOM file) and sending it (by normal mail, by email or by EDI):
The Contracts/Disciplines/Modalities section is used to enter all the occupational risk prevention contracts for each client. This section is one of the most complex, as it has a sub-section for Monitoring and another for Documentation.
In the Monitoring sub-section, we can see the history of prevention contracts that each client has and if there is an associated contributor:
Each monitoring line is extended by means of a pop-up sub-form, showing the list of contracted concepts to be invoiced:
Each concept to be invoiced is extended by means of another emerging sub-form, showing the detail of the concept to be contracted and how it is to be invoiced:
Returning to the section on Contracts/Disciplines/Modalities, in the Documentation sub-section we can generate the Certificate as the client has contracted the prevention service and see all their contracts. The program shows the list of documents stored on the server:
In order for a client to be billed for services that are not prevention services, we have created a new section called “Non-ORP contracts”. In this section we will find the same sub-sections explained for “Contracts/Disciplines/Modalities”. In order to avoid mixing services and/or contracts, we differentiate.
Finally, another improvement made in the implementation, was for the section of Observations. Previously, there was a field for observations in each subform, for the notes that were necessary. In this new version, all the observations have been placed in the same section, so that they can be consulted in the same form. However, in each observation you can specify for which section or area it corresponds:
In order not to go into more detail, the application has a large section of auxiliary files, in which data on banks, postal codes, payment methods, activities, NACE codes, preventive methods, concepts to be invoiced, VAT rates, tariffs, and a long etc. are specified. It also includes a large section of lists (companies according to NACE, new and old customers, customers by branch, customers by technician, customers with/without SEPA, customers with signed/unsigned contracts, etc.) and data export.
The desktop application is as follows:
As we have mentioned before, the program can make a predictive billing, depending on the renewed contracts. But if we prefer to do it by hand, then, we can visualize the list of renewed contracts, pending to be billed, with the objective of marking those we want to be billed:
If we want to see the details of a client’s contract, we can double-click on their line or record, and a screen will appear showing the details of the concepts to be invoiced:
As there are several payment methods and our client asked us to make an invoice for each due date, the program makes a pre-invoicing (pre-invoices). Whether the automatic invoicing process is executed or invoiced manually, the first step is to make a pre-invoice. In it, the program will warn you, according to the payment method and its different due dates, how many invoices you must make, on future dates. We show the pre-invoice search engine. There is a filter that allows you to show those that are pending and those that have already been invoiced:
In case it is necessary to make an invoice manually without using the contract circuit, the program has a form, in which it is possible to detail all the necessary data and concepts to be invoiced, plus the different forms of payment. Again, a pre-invoice will be generated, from which, depending on the form of payment, certain invoices will be created:
At the time of creating the pre-invoices, the program already knows how many invoices it has to make. If the invoicing process is executed, it will create an invoice for each due date. However, the program will have the invoices prepared in chronological order, without putting any invoice number on them. They will remain in a “lethargic” state, until the date of invoicing.
Every day, the people dedicated to invoicing, will review the list of outstanding invoices or to materialize and they will only have to accept their emission. At that time, the programme will insert the corresponding invoice number.
Invoices can be modified until they are issued. Afterwards, the process must be used to rectify invoices:
If the payment system is based on bank receipts, the application allows the management of receipts according to norms 19 and 58, i.e. SEPA view and SEPA discount:
The application has collection management, in which it is possible to distinguish if 100% is missing or there are partial collections. In the case of partial collections, partial amounts and bank commission charges are managed, motivated by the return of receipts:
The transfer to the SAP accounting program allows you to choose between dates, the data to be transferred and repeat previously transferred data:
The program has a very complete list management and the data can be exported to Excel at any time. Nevertheless, we offer a module to generate lists, at your own discretion, mixing the data that our client wants.
Application made with Visual.Net and SQL database. To use this application it is necessary to have the SQL Express database (minimum). The application is made in Spanish language. Note: The data inserted in the images are fictitious.
