It should not be a workflow. It’s the state of another system and its workflow should not affect ours.
In my experience, linking a communication to an external system to a Tryton transaction is always a bad idea. How will you deal with failed transactions that already made a call? How will you deal with successful transactions whose external call failed? How will you deal with retries due to DatabaseOperationalErrors? How will you deal with changes in the external system that have not been done by your system? A user can login to the SII web and report an invoice! (This crashes the nowadays aeat_sii module) Or invoices may come from an ETL from a former ERP system and might be already reported to the SII. Or not!
I’d say: just don’t. Just store the “last seen external state” so you know what to schedule and what to skip. Then we could use the “query” SII methods so users can manually update this state of some invoices. Invoices with no known state can be sent in batch. Invoices with errors will be managed by the users. Invoices needing modifications (not the very invoice, but metadata around tax keys, invoice line origins, party categories, could affect the SII invoice description) will be managed by the users.
And simply map all methods of the SII service (create, modify, cancel, query). Those methods exist so users can decide to use them. Don’t make a strong opinion or an enforcement to use either of those methods.
I’m not aware of the details. As far as I remember you only need to tell the VAT number. How the authorized third party authenticates is not relevant for the authorization, but we should check it out. It’s in the docs
I don’t agree. Probably this method implies law responsibilities on third party (Tryton integrators in this case).
If this is the same mechanism used to authorize third parties on aeat it is used to use by company legal representatives. Typically third account managers or people/companies like that.
The legal responsibility of any Tryton transactions must rely on user/company who is using it not to the Tryton integrator companies (technical side).
For obvious reasons (namely because precisely companies with lots of invoices are required to use this webservice), the happy path should be automated. That is: hundreds of valid invoices are posted --> then they are reported to the SII webservice as creation --> Tryton saves their external state.
But users should be able to control the communication of individual invoices. That includes the 4 webservice methods: create, modify, cancel, query. This should be a MUST. Most of the issues that arise from this webservice are due to bad data that must be fixed and resent by the user.
Regarding scheduling vs queuing: both feel equally valid to me. I think this should be left as a choice to the system operator and the module should not have an opinion about this. Depending on the data volume, for example, one or another way will present different issues the module could not foresee.
I do not understand what should be a must. Could you please clarify?
I do not see why we should support two options of sending invoices, it only adds unnecessary complexity to the system. For me all the invoices should be sent on the same way, no mather the number of invoices that are sent on a single day. If there are perfomance issues the module should be optimized to fix them.
Some context: the SII data spec is full of quirks. If “X” key value’s equals “A” then “Y” must be informed telling whatever and “Z” key should be equal “B” and whatnot. When I was put in charge of the SII communication and I started reading the specs I was afraid. I searched for inspiration in the Odoo SII integration and I found it: that was the “how not to do it” example. (I’m unaware of the evolution of that codebase, I’m talking about summer 2017?). The core objective that drove me was: mitigate the development pain.
That’s why I created a separate library agnostic of Tryton and I try to reject any development not including unittests. Because I think it is a necessary abstraction layer and safety net.
Also, as @josesalvador said, to potentially get help from other projects using the SII service. Sadly, that never got to be a priority, as you can see in the absence of documentation.
Precisely, thanks to the Tryton pool metaclass, custom modules can easily customize the data to be sent. Here you can see an example of a custom module that adds aggregated invoice from sale points’ bills. And I am aware of other projects that tune the SII invoice serialization in a similar fashion.
I’ve just had a call with the task authority asking about this process. There is an option on the tax authority website to add a third party as “apoderado”, giving access to a subset of formalities or to all of them. This form ask for the VAT number of the company you give access rights and an optional end date for the rights.
I think for the end user the relevant information is the VAT attached to the certificate. So i’m not sure if showing the certificate to the end user will be relevant as they will only see a bunch of random characters that they will probably do not understand.
From the user point of view, the important part is to properly show the errors on the SII record, so they can request the system administrator to fix the certificate if there is something wrong with this setup.
So after knowing how the process works, I do not think it is required to show the certificate to the end users.
So this is not at all a valid usage. A certificate can not be trusted based on a public data like VAT.
So I guess the “company” delegated must be registered and must retrieve a certificate like others.
As the model to hold all the sii information is a Tryton model it is possible to override it’s module without the need to register any Mapper, nor mixxin objects on the tryton detabase. So for me there is no benefit, only an additional layer of complexity.
You authenticate against service with the certificate they issued themselves! And they will issue you a cert only if you really own the VAT number. Only the spanish tax office should worry about their internal chain of trust, it is a valid usage for us!
Right now the mapper simply inherits a bare “Model” instead of “ModelView” nor any child of “ModelStorage”. This allows to customize the behavior of a model without field descriptors. I see no impact for the database.
What’s the drawback of registering a mixin from a module into a Tryton model? All models in all modules are doing it: it is Tryton’s main inheritance mechanism! It is what makes Tryton so easily customizable. Why is this even a point?
Precisely speaking about complexity. I can’t understand how the complexity of the module would be reduced if it does not use this library (or any other!). All that logic must be implemented. It must be tested. Ask yourself if removing and reimplementing any other library in use by your system would be a complexity reduction for your codebase. Quite the opposite, if you ask me! I honestly can’t understand any of your statements “for the sake of complexity”.
Ideally not even the SII service magic values would exist in Tryton, only library’s semantic values! But that is a battle I lost in 2017.
If you desing the models and functions correctly there is no point at all to decouple the logic to a separate mixin.
Yes, I’ve read the code several times, back in 2017 when you where developing this, today and probably I will come latter when implemeting this blueprint. I must adming that for me it’s hard to understand everything with the amount of functions and models that are currently involved in the transformation process.
For me the complexity is that there are two diferent codebases that are decoupled when they should be coupled. When some change needs to be introduced, you have to create a patch for both codebases, as if you add new parameters to Tryton that are not supported on the library it won’t be sent to the webservice.
Tryton has all the invoice’s information in order to generate the webservice values. We only need to test that the proper data is generated from an of invoice and everything else should be delegated to a library for interacting with SOAP webservices. This library is mature and already used on Tryton.
I’ve created Issue 9128: Send invoices to SII - Tryton issue tracker which implements main of the desings discussed here.
The module is not complete (see the issue for more details) but it allows to send basic invoices to the tax authority.
I will like to receive some feedback about it’s desing to see if it fits all the requirements.
If anyone has any special requirement or a special type of invoice that should be tested please drop a comment so we can ensure that they desing is flexible enougth to support all the corner cases.
pokoli
(Sergi Almacellas Abellana)
Split this topic
59
