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.