[FIX] l10n_hu_edi: Various fixes #165195
[FIX] l10n_hu_edi: Various fixes #165195
Conversation
antoine162
force-pushed
the
17.0-l10n_hu_edi-fix-nightly-tests-andu
branch
from
a375e17
to
b11c3bb
Compare
antoine162
changed the title
antoine162
force-pushed
the
17.0-l10n_hu_edi-fix-nightly-tests-andu
branch
from
b11c3bb
to
9c981e9
Compare
| @@ -82,6 +82,18 @@ class AccountMove(models.Model): | |||
| l10n_hu_edi_messages = fields.Json( | |||
| string='Transaction messages (JSON)', | |||
| copy=False, | |||
| help=""" | |||
There was a problem hiding this comment.
This is good for a comment, not for the user to see anywhere. (technical comments should not be in help)
| @@ -561,15 +574,15 @@ def _l10n_hu_edi_query_status_single_batch(self, connection): | |||
| 'l10n_hu_edi_messages': { | |||
| 'error_title': _('The invoice was sent to the NAV, but there was an error querying its status.'), | |||
| 'errors': e.errors, | |||
| 'blocking_level': 'error_but_continue', | |||
There was a problem hiding this comment.
do we still have error_but_continue left?
There was a problem hiding this comment.
No 😄
I had misunderstood the use of error_but_continue in the Send & Print: it's used in cases where the EDI has some kind of error which prevents an official tax invoice from being generated (e.g. if a QR code is missing) but we should still generate a proforma PDF.
I don't think it is applicable to Hungary, since the normal PDF can always be generated (it does not require anything retrieved from the government). Therefore, if there is an actual error (invoice rejected), we block the user with a UserError. In all other cases, we just provide a message in the banner.
I appreciate this is not the best in the case where NAV is slow, so the Send and Print returns but we are still waiting for a response from the government (in this case, we put this in the banner, but don't block the user, the PDF is generated and the e-mail is sent to the customer etc.) This might not be the best since the invoice might still be rejected later. I'll have a chat with LAS tomorrow to see whether we can do something to the Send and Print to handle this case better (which is also needed in other localizations where the sending is in 2 steps e.g. Peru).
antoine162
force-pushed
the
17.0-l10n_hu_edi-fix-nightly-tests-andu
branch
from
9c981e9
to
a628f07
Compare
1. Avoid crashing if move.name is not set
In the tests
`:TestAccountMoveInInvoiceOnchanges.test_fiduciary_mode_date_suggestion`
`:TestSequenceMixin.test_sequence_empty_editable_with_quick_edit_mode`
the compute method `_compute_l10n_hu_edi_attachment_filename` gets
called before the invoice name is set.
Because of this, calling move.name.replace('/', '_') was raising an
AttributeError.
2. Allow user to not put credentials in demo mode.
3. sent (waiting for response) and confirmed_warning states don't raise
a UserError and don't block an e-mail from being sent to the customer
anymore.
4. always send modification invoices using 'MODIFY' (never 'STORNO')
since in Odoo we can't predict whether the user will want to issue
further corrections to an invoice in the future.
Fixes runbot errors 64755 and 64756.
antoine162
force-pushed
the
17.0-l10n_hu_edi-fix-nightly-tests-andu
branch
from
a628f07
to
a2699b7
Compare
|
@robodoo r+ |
|
@antoine162 @jco-odoo this pull request has forward-port PRs awaiting action (not merged or closed): |
1 similar comment
|
@antoine162 @jco-odoo this pull request has forward-port PRs awaiting action (not merged or closed): |
In the tests
:TestAccountMoveInInvoiceOnchanges.test_fiduciary_mode_date_suggestion:TestSequenceMixin.test_sequence_empty_editable_with_quick_edit_modethe compute method
_compute_l10n_hu_edi_attachment_filenamewas called before the invoice name was set.Because of this, calling move.name.replace('/', '_') was raising an AttributeError.
Allow user to not put credentials when they are using demo mode.
sent (waiting for response) and confirmed_warning states should not raise a UserError and should not block an e-mail from being sent to the customer.
always send modification invoices using 'MODIFY' (never 'STORNO') since 'STORNO' prevents further modifications from being issued to the invoice, but in Odoo we can't predict whether the user will want to issue further corrections to an invoice in the future.
Fixes runbot errors 64755 and 64756.