[16.0] l10n_br_fiscal_dfe, l10n_br_nfe_dfe: generic l10n_br_fiscal_dfe, add l10n_br_nfe_dfe for NF-e DF-e#4416
Draft
[16.0] l10n_br_fiscal_dfe, l10n_br_nfe_dfe: generic l10n_br_fiscal_dfe, add l10n_br_nfe_dfe for NF-e DF-e#4416
Conversation
Contributor
|
Hi @renatonlima, |
Co-authored-by: Felipe Motter <felipe@engenere.one>
Co-authored-by: Antônio Neto <neto@engenere.one>
Co-authored-by: Antônio Neto <neto@engenere.one>
Co-authored-by: Felipe Motter <felipe@engenere.one>
Co-authored-by: Felipe Motter <felipe@engenere.one>
Use sudo() in action_download_xml, action_download_xmls_zip and make_pdf so that users with read-only access to dfe.document can execute these download buttons without triggering a write access error from ir.attachment creation or computed field recomputation during flush. Add groups_id to the download XMLs zip server action so that the ir.actions.server framework skips the write access check for users that belong to the fiscal user group.
Instead of re-downloading the XML from SEFAZ via key lookup, import_document now reads from the existing attachment_id. Errors propagate to the user as UserError instead of being silently logged. The batch method import_document_multi still catches and logs errors to allow cron processing to continue.
Remove _dfe_download_document and _dfe_parse_xml_document which are no longer called after import_document was refactored to use local XML attachments. Also remove their tests and unused gzip/BytesIO imports.
…end_event Change document_number from Float to Char to match the convention used across the localization. Remove pointless try/except re-raise in action_send_event.
Keep dfe model as raw data storage only. The import_document method now lives entirely in dfe_document, reading the local XML attachment instead of delegating to dfe. Remove dead dfe_import_documents and import_document_multi methods.
The try/except handler around the access key extractor in _dfe_process_distribution was unreachable: if the extractor fails for a known schema, the corresponding _dfe_create_from_* handler accesses the same XML attributes and would crash anyway. Simplify to a single ternary expression and remove the unused logger import.
Add targeted tests to cover uncovered branches: - _dfe_log with string/bytes envio_xml and retorno content variants - zero-NSU with unknown schema (no extractor, no dedup) - _dfe_sync_cron_nextcall when cron ref is missing - _update_metadata skip when complete DFe already exists - DFe name_get without dfe_nfe_document_type - _dfe_notify_users fallback URL when action ref is missing - _dfe_get_or_create_document with short access key - Fix test_xml_pretty_computed dead branch (if dfe_no_attach)
dhEmi from SEFAZ XML includes a timezone offset (e.g. -03:00) but the code was stripping it with [:19] and saving the local time as if it were UTC. Use datetime.fromisoformat() with astimezone(utc) to properly convert before storing in the Datetime field.
Same issue as dhEmi: fromisoformat() returns a timezone-aware datetime but fields.Datetime.to_string() does not convert to UTC, storing the local time as if it were UTC.
…ility message_notify called without model/res_id creates orphan messages that the JS inbox dropdown cannot render (it groups by originThread). Pass model="res.company" and res_id so notifications appear in the topbar messaging dropdown.
rvalyi
force-pushed
the
16.0-generic-dfe
branch
2 times, most recently
from
bcf71ea to
c00ca34
Compare
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
o problema de #4383 é que ele torna o modulo l10n_br_fiscal_dfe especifico para a NF-e.
Mas poderia ser útil usar serviço de DF-e para outros documentos fiscais como a CT-e (alias na Akretion vamos precisar para um cliente). Por isso eu acho melhor conservar um modulo l10n_br_fiscal_dfe genérico.
E ai em vez de entupir o modulo l10n_br_nfe que já ta mega pesado de coisas extra de DF-e com dependências novas (tipo queue_job), eu prefiro seguir o que faz o sucesso da OCA: módulos pequenos e fáceis de migrar (ou ainda pequenos para caber no contexto de uma IA...). Dessa forma, se "alguém" preferir um modulo de DFe que usa erpbrasil.edoc terminado no m*jo por estagiários de faculdade, sem problema desde que não vem atrasar a vida de geral na OCA. E ai pelo menos temos um l10n_br_nfe robusto e fácil de migrar.
EDIT: nessa outra branch (para depois), eu fiz um prototipo de como poderia ser o modulo de DF-e especifico para CT-e:
Disclaimer, acabei de fazer o refator com AI mas eu ainda não testei em produção.