Suministro Inmediato de Información (SII)

For example when you send a tax identifier that is not yet in the tax authority database, when the tax identifier is empty and the invoice should have one or when the country code is invalid.

Once the data is fixed you must send a modification to the existing invoice.

It should be possible to resend the same invoice if not accepted and the webservice expects that we send the same invoice number and a flag to indicate that is a modification of an existing invoice. So i do not thing it will be enought with one flag.

For example to specify the tax identifier of the invoice.

If the invoice is cancelled we inform the tax authorities if the invoice has been sent already.

I thought the same but if exists a cron job with a frequency of 15 minutes, do you still think it is worth to add the button? Why?

Yes I do. IMHO the user should have the option to send manually at least in some scenarios. As an example, the cron job has sent an invoice and the result is rejected. So user checks the state and proceed to fix data (wrong party country, or sii identifier, etc). The next action will be to send invoice again but without “button” he only can re schedule the job and wait x minutes (undetermined for him) to the result. As conclusion, the user cannot finish the process by himself.
Indeed the module account_payment_clearing adds a cron job to post clearing moves; but user always can post at any time.

So what is the point of such state?

And what will be the problem? The invoice must be sent.

Indeed only in invoice so this is a problem. I guess there should be another model for this kind of operation.

WTF? Why is such call accepted in the first place?
Then if the authorities are not capable of provide correctly behaving service, we have to check everything before call so no update should be needed.

This is the worst design possible. An invoice should be accepted or not. It should be simple, anything else is too complex and error prone.

No there is no need for such button. It will only confuse user with something it should not care about. Having useless button is not the way we design in Tryton.

This is not the reason. There is a button because some journal may have no delay so the user choose to post manually.
Here there is no choice.

The invoice is registered on the sevice but user must fix some errors and resend as modification. In last 3 pages of this document is explained.

Yes it must be sent but only after user fix the errors.

I’m afraid this is for accepted with errors state. For rejected state the invoice is not registered on the service so must be resent as new.

Is it not possible to request failure on bad data like any normal service?

What happen if it is resent with errors? The same error and/or new errors?

Thats the rejected state. You should fix and resend them.

They only report the first error, if there are multiple errors on the same invoice you must resend them and fix error by one by untill all of them are fixed and the invoice is accepted.

No I mean to request from the service to always reject in case of error.
So it is never needed to update.

Despite this terrible behavior, I mean what happen if you resend the exact same invoice? And what happen if you do that every 15 minutes.

I have never tried but I expect them to return always the same error for the invoice.

I think it is important to know because it will have impact on the design like if we have a single task cron that retries to post/update every pending records no matter if there are changes or not.

Yes this is the result.

So as long as the state is not “Accepted” or “Canceled”, the cron task should post the invoice to the service. Like that it is a “self-healing” workflow that does not require user intervention to happen and it guarantee that no invoice is forgotten.

Maybe we have to take into account that for this implementation a better design could consist in split the general part of the tryton side.

Like relatorio or GooCalendar does.

I unknow the up to date state of this two projects, just for the record:

Why? Which are the benefits?

I do not know about the former but I do know about the later and what it does is convert a dict representing an invoice into a dict the the webservice accepts. I think this is an unneceary layer of abstraction and I will prefer that our module creates directly the data to be sent to the webservice in a customizable way to ease the customization by custom modules if needed.

Well it’s all about implementation details that we can discuss later. I only expect at this moment not discard the idea.

I think it would be possible to split part of the development in a way on law changes does not affect to the tryton part.

The intention of the indirection layer would be to become Tryton as agnostic as we can of SII. Moreover, if we would continue working in a general SII python package maybe we can get help from another developers to be up to date with all the SII law changes.

1 Like

I agree with @pokoli, I do not see the benefit of separate it into two projects.

Regarding authentication against the SII webservice:

Certs generated with a password are indeed insecure from the point of view of “how certificates should work”. FNMT provides this mechanism to lower the usability threshold for its diverse users. But if we go for that we’d have to store a private key, force the users to share their secret passwords with the Tryton system (which they were already forced to share with the FNMT), and so on. Rather bad solution (but it’s working right now).

Another path is using the certs embedded in the physical electronic national ID documents. Users must have a special keyboard capable of reading the document and Tryton should integrate with that. But the private key can’t be extracted so, either the Tryton client should be the process communicating with the SII, or either the asymmetric steps of the TLS handshake should be solved by the client and then share the symmetric session secrets with the Tryton server who would upload the invoices. Any of this means comms can’t be scheduled nor queued but must be actively signed by the users. Rather complex solution (unfeasible, if you ask me).

But fear not. SII has yet another authentication method! (It’s actually an authorization method because authentication will always be a client TLS layer) Essentially the users must tell the spanish tax office that they authorize a third party to report their invoices to the SII webservice. The third party would be the company operating the Tryton server, who would use their own cert (and not users’) to authenticate the comms against the webservice. That certificate should be in disk and stated in the configuration. Staging, testing or development deployments can use any cert (developer’s personal cert, for example) because the test webservice endpiont does not check authorization. No secrets are ever shared. A company deploying a Tryton server as a Service for N companies can report all their invoices to SII only requiring a small manual authorization on their side. This path is simpler, more secure and more rigorous on how certs are used. I’d say we go for that.

I guess it is about giving the public key to the tax office.
In this case, I think also it is the way to go with a single configuration option (like I asked on Suministro Inmediato de Información (SII) - #2 by ced).
We could have the public key showed to the end-user via the client form.

Ok, but where do you want to show the public key? On the account configuration form?

Yes, why not. It will be a little bit like webhook_identifier of stripe account.