[16.0][REF] l10n_br_fiscal_edi: Finite State Machine refactor

[rvalyi]

substituição e #4137 sem a mudança de nome da variável state_edoc (para não ter conflito entre o state do account.move e do l10n_br_fiscal.document) e continuação para passar os testes em todos modulos que dependem do l10n_br_fiscal_edi.

ver os novos arquivos de README:

• https://github.com/akretion/l10n-brazil/blob/16.0-edi-refactor/l10n_br_fiscal_edi/readme/DESCRIPTION.md
• https://github.com/akretion/l10n-brazil/blob/16.0-edi-refactor/l10n_br_fiscal_edi/readme/USAGE.md

[felipemotter]

Como está o andamento dessa proposta @rvalyi ?

[rvalyi]

Ta quase. Como vc vê tem um teste falhando ainda e tou revisando o script de migração tb. Mas conceitualmente ta tudo ai já, se faltar algo é detalhe mesmo.

Não estamos com pressa para mesclar, se levar 2 ou 3 semanas tudo bem. Mas eu so acho que é bom fazer na 16.0 ainda porque:

• vai ajudar bastante quem vai ficar ainda uns anos na 16.0
• vai facilitar a manutenção entre a 16.0 e a 18.0

Agora sim, tem vai ter que testar isso MUITO bem para não introduzir regressão. Com isso eu diria que daria para considerar o l10_br_fiscal_edi como Production/Stable.

Observem nos logs tb como agora a mudança de estado e os hooks ficou tudo no log facil de auditar ou de extender...

[mileo]

Seria interessante implementar certa segurança nos campos, permitindo ou não alteração dependendo do estado.

Sendo que isso é especifico de cada campo

Os documentos importados / compras também tem detalhes específicos.

Se for o caso apenas implementar o motor e deixar tudo bloqueado, mas que fique fácil de alterar o comportamento depois.

De resto parece ok, exceto pelos métodos com nome parecido com o account, pode dar mais problema de manutenção no futuro, muitos a palavra "document" foi coloca de propósito, para facilitar a pesquisa no código.

[rvalyi]

Seria interessante implementar certa segurança nos campos, permitindo ou não alteração dependendo do estado.

Sendo que isso é especifico de cada campo

Os documentos importados / compras também tem detalhes específicos.

Se for o caso apenas implementar o motor e deixar tudo bloqueado, mas que fique fácil de alterar o comportamento depois.

De resto parece ok, exceto pelos métodos com nome parecido com o account, pode dar mais problema de manutenção no futuro, muitos a palavra "document" foi coloca de propósito, para facilitar a pesquisa no código.

Realmente da par conservar os nomes action_document_confirm, action_document_cancel e action_document_back2draft. Tou ajustando isso. Com isso o diff vai ficar mais fácil de revisar e o impacto para migrar vai ficar menor.

[rvalyi]

ficou quase OK. So ver o cancel e o script de migração. Conservei os nomes dos métodos antigos onde era possível e assim o diff ficou um pouco menor.