Well, with this execution frequency you’re right. No need to put an extra action.
What I am wondering is if it is a good practice to have cron jobs with this type of execution frequency…
Sorry I missed this point which is important.
No normalized format is used, indeed no format at all is used. The tax authority only accepts comunication with the SOAP webserivce and they designed it to accept all the invoice details as parameters of ti. To ease the comunication we can use zeep, which expectes to receive a dict of values that can directly generated from the invoice.
I do not see any issue on this frequency. Did you?
BTW the account_fr_chorus module cron has a 15 minutes execution frequency. I think we can use the same values.
If a more Tryton experienced developer does not see any issue me neither. Just for learn. It’s fine for me.
So he has to give its secret to the website.
Any way, the system administrator will have access to this data no matter what you design (except if you put the submission process on the user system).
That’s why I said it is not secure and it is not how certificates are designed.
The certificate is not used as a certificate for all the above reason.
But I do not think there is any need to discuss this technical semantic further.
This certificate is just like the secret_key of Stripe (with a different way to use it). So we must manage the certificate like we do for similar concept. We just store them in the database as it is linked to the company.
And in this case as the data received by the user is protected by a password, I would store the password and the “certificate” as-is.
About the fernet usage, I think it is out of the scope of this blueprint. I think we have already one (I can not find it) blueprint to store encrypted data in the database. Once implemented it can be used for this password (and other modules).
Even for the codification? They just invented a specific codification only for them?
I still do not understand most of those states. For me when you send something to someone, it has a binary state: sent or not. What are the other cases? Should they really be managed?
No as the secret is not stored on the website, it’s only used to encrypt the cert so anyone that does not know this secret can not extract the keys (so can not use it).
Ok, we store this information but then we will need to extract public and private key it each time an invoice is sent. I’m not very fan of storing the password (as we have to store it on plain text). That’s why I propsed to store only the public key and the private key which is the only data we require and use a wizard to update this values by asking the user for the right data. As this may be an implementation detail I’m ok leaving the discussion here and we can come back latter when we have some code to discuss about.
Ok, Forget about the encription part and keep it simple.
I only found the blueprint about client side transforming, but I do not see it usefull for this use case.
Yes, the codification is specific for sending the invoices with the webservice. But if this changes in the future I think we can move the fields to the account_es module.
Here we have Pending for not set, and all the others are sent + the state on the other system.
If you prefer we can seperate it storing only the state on the other system, and all the records with empty state are the one that should be sent to tax authorithy.
Yes, it is very important to manage the “Rejected” and "Accepted with errors"status because it’s the user responsabiliy to do something in order to resend the invoice until he gets a reply with the “Accepted” state.
For the canceled one, it is the response that the tax authority gives when an invoice is cancelled.
From the user point of view they need a screen to search for invoices with are not in accepted state and have the possibility to re-send the invoice. Here is detailed:
But after a second thought I am wondering if it won’t be better to follow the account_fr_chrous design and have a single record for the invoice (with an unique constraint) but allow to re-schedule a record to be resended. This way we always have the last state of the tax_authority system which is what is relevant for the end user.
I agree better a cron job. Although will be great to add a button in order to users can force a manual sent.
I prefer this design instead of duplicate records, but it should keep a history of changes (when was sent for the first time, the state, …). Perhaps enabling history changes on the model for a set of fields.
Will be great to have access to the JSON on the form view (as a text field or a binary widget to download).
Indeed the certificate identifies the party (so it is per party).
For intracommunitary invoices the type of operation (Detalle Operaciones) must be sent. This is untaxed amount and tax amount per goods and services. How do you think to implement it? I suppose:
- goods: lines with product of types goods and assets
- service: lines with product of types service
- when there is no product on invoice line: ¿?
As you know the web service allows to sent invoice modification and invoice cancelation. So this actions should be considered to re-schedule the record to be resended.
For me the table recording the sending of the invoice should have unique constraint on the invoice to ensure it is sent only once.
So all other states are indeed just logs.
Could you give an example for each case? I do not understand how it could be accepted with errors.
For me the invoice is sent or not. If it is not sent the cron must sent it.
Send status should be a boolean. It is or not, all other cases are not sent and logging data.
I do not see the point. User can run cron at any time.
When could an invoice be modified. In Tryton is it never.
What is invoice cancelation? For me, it makes no sense to change an posted invoice.
Please could you provide a use where an invoice should be re-sent.
It is when there are errors on invoice’s message but they are considered as non critical and the invoice is accepted with this special state.
Well I don’t agree due to an invoice sent and rejected is sent. Moreover in this case if the invoice is marked as not sent the job will send it indefinitely until user fix it.
Account user normally does not have acces to Cron jobs.
AFAIK Tryton allows (or will allow) to cancel in/out invoices.
You’re right about modifications.
When state is rejected/accepted with errors that user must fix any configuration, and when invoice is cancelled.
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.