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.
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.
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.
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.
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.
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.
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.
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.