Multi-platforms Centralized Invoicing Tool

Working as a technical provider for a client selling tyres at a B2B level, we manage more than 40 distinct web platforms generating orders. The users of these platforms are sometimes the same, sometimes different.

The invoicing made cross-platforms was thus a long and complicated way every month. As one can expect, we were quickly requested by our client to come with a proposition of tool, which we did.

The challenge was the following ; we had to create a Centralized Invoicing Tool (CIT) for all of these platform, knowing that :

  • Some of the users were registered on several of the websites.
  • We had to create the process to be legally compliant but still being able to fit with real life problems.
  • The platforms might have different types, information, structures, at business and technical level.
  • The platforms are base in several countries, so the CIT had to be multi-languages and multi-currencies.
  • Our client had to be as much as possible independent in case of any issues, as invoicing is always a tricky moment.

Portable and Generic

The very first main technical challenge was the communication between the CIT and the platforms, knowing that differences between these platforms can be found at every level of the structure :

  • Clients
  • Suppliers
  • Orders
  • Products

But that communication also had to be as generic as possible to be able to apply it easily and at low cost on every new potential website.

We thus created an API in JSON that had globally the same structure on every platform, except for the few possible differences. This fixed for the portable point of view.

At CIT level on the other side, a setup was given to administrator to be able to define for each entity at platform level (such as “Client”, “Order”, “Product”, “Supplier”, …) which field were available or used on the platform were the call had to be done. This way, we had a generic way to call the same API structure with different fields.

On the other side, as one user could be registered on different platforms, but with some differences on each platform (for example, the username), at each entity level some attributes setup was made possible to be able to fit at one place (the CIT) for several platforms.

Security

Of course when it’s about exchanging sensitive or private data, security is a concern. At the API level a private encrypted key is used for each call.

At CIT level, multiple users can be created with very specific rights, available per section and pages.

Legal Compliance

Invoices and credit notes and they data contained in it are official documents, which means that once created and sent to a client, they can’t be modified anymore. Our ICT was made to prevent any modifications once the document is officially acted.

However reality can bring some exceptions. For example, a manual invoice or a manual credit note could be done outside the tool, and the invoice or credit note number is then not similar on the tool itself. Some setup are available in the ICT to be able to manage such concrete cases.

To prove the origin of the data, every API call and import are saved into logs with the related platform, received data and date/time of the calls.

Global Management

Sometimes when doing a brand new application, unpredictable things happen. Here an idea popped up.

As this tool was centralizing every platforms of this client, connecting most of the data between them, with a few more lines of code, this application could become not only a centralized invoicing tool, but a global data management tool, which we did.

Every data edited on the CIT itself is now optionally sent to the related websites, allowing to edit one client, supplier or product one time only on several platforms. And with the way it was created, even specific data could be handled easily !

Conclusion

Our CIT, made with Symfony, now allows a lot more than it was requested at the start, and can at the same time manage mostly all possible scenario in national and international business, but also allow the platform owners, if wanted, to centralize all possible data in one point, and to still be able to edit it on the different origins of this data.