-
-
Notifications
You must be signed in to change notification settings - Fork 248
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[14.0][REF][l10n_br_fiscal][l10n_br_fiscal_edi] l10n_br_fiscal_edi extraction from l10n_br_fiscal #3012
Conversation
a342b96
to
bc9c6f2
Compare
bc9c6f2
to
9710f59
Compare
Hi @luismalta, @mileo, @gabrielcardoso21, @renatonlima, @mbcosta, @marcelsavegnago, |
9710f59
to
fe898c5
Compare
8de978b
to
30c46d7
Compare
Pessoal, dei um rebase porque o PR do @felipemotter #3090 matou a metade dos workarounds dessa PR (ver detalhe dos commits). Nisso a extração do l10n_br_fiscal_edi ta bem facil agora... |
Olá pessoal, Há algum tempo atrás eu havia trabalhado para melhorar o suporte aos documentos fiscais principalmente os eletrônicos para implementar algumas funcionalidades faltantes como o MDE, DFE e demais eventos dos documentos fiscais, para isso é necessário primeiro fazer uma organização na estrutura base dos documentos fiscais, porque os objetos e heranças dos documentos fiscais devem, ser simplificado, eu fiz um diagrama atualmente dos objetos dos documentos fiscais: classDiagram
FiscalDocumentEletronic <|-- FiscalDocumentWorkflow
FiscalDocument <|-- FiscalDocumentEletronic
FiscalDocumentMixin <|-- FiscalDocumentMixinFields
FiscalDocumentMoveMixin <|-- FiscalDocumentMixinMethods
FiscalDocumentMixin <|-- FiscalDocumentMixinMethods
FiscalDocument <|-- FiscalDocumentMoveMixin
FiscalDocument <|-- FiscalDocumentMixinFields
FiscalDocument <|-- MailThread
class FiscalDocumentWorkflow{
state_edoc = fields.Selection
state_fiscal = fields.Selection
cancel_reason = fields.Char
correction_reason = fields.Char()
+action_document_confirm()
+action_document_send()
+document_back2draft()
+action_document_back2draft()
+action_document_cancel()
+action_document_invalidate()
+action_document_correction()
}
class FiscalDocumentEletronic {
issuer = fields.Selection
status_code = fields.Char
status_name = fields.Char
status_description = fields.Char
authorization_event_id = fields.Many2one
authorization_date = fields.Datetime
authorization_protocol = fields.Char
send_file_id = fields.Many2one
authorization_file_id = fields.Many2one
cancel_event_id = fields.Many2one
cancel_date = fields.Datetime
cancel_protocol_number = fields.Char
cancel_file_id = fields.Many2one
invalidate_event_id = fields.Many2one
invalidate_date = fields.Datetime
invalidate_protocol_number = fields.Char
invalidate_file_id = fields.Many2one
document_version = fields.Char
is_edoc_printed = fields.Boolean
file_report_id = fields.Many2one
+serialize()
+view_xml()
+make_pdf()
+view_pdf()
}
Alguns objetos e heranças podem ser simplificados eu comecei a fazer esse trabalho aqui na branch 14.0-rfc-fiscal-document-events onde eu também fiz melhorias na gestão da comunicação com a Sefaz e suporte a outros webservice ainda não implementados no Odoo. Eu vou fazer um rebase e continuar esse trabalho. |
5f89a07
to
84b722f
Compare
Bora... Quanto mais cedo enfrentar esta questão.. melhor. |
@renatonlima teve tempo para olhar? |
/ocabot merge nobump |
@rvalyi The merge process could not start, because command `git merge --no-ff -m 'Merge PR #3012 into 14.0 Signed-off-by rvalyi' tmp-pr-3012` failed with output:
|
[REF] extract l10n_br_fiscal_edi from l10n_br_fiscal 2/2 [TMP] leave invalidate.number in l10n_br_fiscal [REF] l10n_br_fiscal: mv doc wrkflw ->fisc edi [REF] l10n_br_fiscal_edi: mv doc wrkflw ->fisc edi [WIP] mv edoc import to fiscal_edi [REF] add fiscal document hook [FIX] l10n_br_fiscal_edi: wrong status_description [FIX] l10n_br_fiscal: edi migration
a14ced1
to
b5997db
Compare
/ocabot merge nobump |
On my way to merge this fine PR! |
Congratulations, your PR was merged at 81f8233. Thanks a lot for contributing to OCA. ❤️ |
since OCA#3012 when l10n_br_fiscal_edi is not installed, these tests were failing
since OCA#3012 when l10n_br_fiscal_edi is not installed, these tests were failing
since OCA#3012 when l10n_br_fiscal_edi is not installed, these tests were failing
since OCA#3012 when l10n_br_fiscal_edi is not installed, these tests were failing
since OCA#3012 when l10n_br_fiscal_edi is not installed, these tests were failing
Este PR extrai um modulo l10n_br_fiscal_edi do modulo l10n_br_fiscal. Pois o módulo l10n_br_fiscal que esta usado por muitos módulos tem que focar em ser apenas o tax engine da localização e coisas como importação de documentos fiscais, eventos de comunicação fiscal ou hooks de mudança de estado do documento fiscal devem ser extraídos neste modulo extra l10n_br_fiscal_edi que hoje apenas 3 modulos iriam usar: l10n_br_nfe, l10n_br_nfse e l10n_br_fiscal_closing.
Eh previsível também que logo mais coisas serão adicionadas no modulo l10n_br_fiscal_edi e por isso é urgente começar a dividir quanto antes. Futuramente da v16 para frente, algumas coisas poderão ser inspiradas dos trabalhos feitos em https://github.com/OCA/edi/ e https://github.com/OCA/edi-framework porem o primeiro passo já eh começar por extrair o módulo...
l10n_br_fiscal antes:
l10n_br_fiscal depois:
ou seja tira 1591 linhas do modulo l10n_fiscal e impacta (levemente) quase que apenas 3 modulos l10n_br_nfe, l10n_br_nfse e l10n_br_fiscal_closing que passam então a depender deste novo modulo l10n_br_fiscal_edi.
Combinado com o #3290 que tira umas 500 outras linhas, já traz do modulo l10n_br_fiscal dentro de um tamanho mais razoável de umas 9500 linhas de Python (quando tira os testes).
Para nos da Akretion é indispensável fazer essa extração na v16 porque não da pro módulo l10n_br_fiscal ter um scope infinito e passar de 12k linhas de Python ou de 20k linhas qdo considera o XML (que da o mesmo tanto de trabalho para maintainer). A única questão é se a gente faz na v14 tb e mantém uma boa sinergia pros cherry-picks entre as branches 14 e 16 para essas 1600 linhas do l10n_br_fiscal_edi ou se a gente fica conservador na v14 mas com certeza terá menos backport de debug da v14 daqui 1 ou 2 anos. Eu diria que vale a pena fazer a mudança na v14, mas cabe a os que ajudaram na v14 de decidir o que querem para vcs @marcelsavegnago @antoniospneto @felipemotter @renatonlima @mileo