Invoice Gateway

Feature Ideas
1

Right now there is a emerging need to send and receive invoice to the national tax agency or other businesses (b2b).

Structure

I propose a similar design like in the Payment module:

  • Have a workflow that keep track of the invoice state
    • sending:
      • wainting (spooled for a batch send)
      • rejected (error, need user intervention)
      • done (invoiced accepted)
    • receiving:
      • waiting (user need to check the invoice)
      • done (the user accepted the invoice and is imported in tryton)
      • rejected (the user rejected the invoice)
  • The business logic need to be implement by other module (referred as from now “gateway”)
  • The list of available "gateway"s should be selectable in the invoice form, with some way to restrict the choice
  • The list of active “gateways” (for inbound invoices) should be configurable
  • The invoice (outbound) can be routed trough multiple gateways

Gateway

The gateway is what serialize an invoice so it can be sent, or de-serialize the invoice and create a invoice record in tryton without user intervention (if possible).
Each nation do it differently, so this is what the end user need to implement via a custom module (if none provided by the main project)
It’s in charge to advance the state of the workflow.
The gateway can implement both sending and receiving, or just one of them.

The benefits

Multi-nation multi-company

What if you want the benefit of a single tryton instance for multiple company, but one company is in another jurisdiction/nation? Right now you cannot do it with a single instance.

International invoicing

In italy (this is just an example), company outside italy can send invoice via the SDI(sistema di interscambio aka “invoice exchange system”) to italian companies. So the company need send a copy of the invoice via another system (but this is a niche case IMHO)

A little bit easier for module development

This will eliminate the need to implement a workflow,work queue and views for each “gateway”. In reality is not a huge amount the developer saves, but at least is code it can’t be “borked” (usually by me).

multiple comunication way

For example in Italy we can send the same invoice via certificate-email, SFTP and web/soap.
In this way the user can choose the gateway he prefers, and switch to another when needed (E.G. service outrage, or waiting the tax agency to release the credential for another communication way).

This post was inspired by the Suministro Inmediato de InformaciĂłn (SII) and my desire to one day make something similar for italy.

This is just a very rough idea, so please comment if this make some sort of sense.

2

I see no need to have a single model as central point. The payment case was different because it has business impact in many places invoice, sale etc. so we needed a common model.
Such central point/gateway adds always more complexity than solving any issue.

1 Like
3

I think we should start by having an italian chart of accounts which has all the invoices and taxes to be used by Italian companies.

I understand that this is a complex process and it requires some understanding of how the account modules are desinged, so feel free to ask any doubts you may have about it and if required I offer myself to organize a remote meeting (that will be recorded) in order to explain the concepts and how to create a chart of account for any country.

1 Like
4

Ugh, fine :stuck_out_tongue:
A bit off topic (I’ll open a new post to collect some info on this)
I already have a structure from that I found by digging around the italian legislature.
I already create a csv file and i have a script to convert it to xml, need only checking the varius flags(but i didn’t have the time).

The only thing missing is a template for tax codes and account types.

P.S.: this is the third time you nudge me to do this (one in person and one via IRC), the peer pressure is killing me :stuck_out_tongue:

1 Like
5

I’d like to help but I don’t get the point.
Since 2019 Italy tax authority enacted mandatory rules on e- invoicing regarding:

  • content
  • format (a proprietary XML)
  • platform (SDI, as you referred), and the “channels” to connect with
    So if you want to make invoices in Italy you must (sadly) comply to that.

Then in addition you have the other tax and statutory rules.
Whats the point/the opportunity?

6

Please start a new thread to discuss or make proposal for Italian e-invoice.