[14.0][FIX] l10n_br_fiscal, l10n_br_account: refatoração do processo de estorno #3623
Conversation
This file contains 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
|
Hi @rvalyi, @renatonlima, |
felipemotter
force-pushed
the
14.0-account-fiscal-refund-fix2
branch
from
20cf7a5 to
03a5b18
Compare
antoniospneto
approved these changes
Feb 14, 2025
rvalyi
requested changes
Feb 15, 2025
felipemotter
force-pushed
the
14.0-account-fiscal-refund-fix2
branch
from
03a5b18 to
3bb4057
Compare
antoniospneto
approved these changes
Feb 17, 2025
marcelsavegnago
approved these changes
Feb 19, 2025
rvalyi
requested changes
Feb 19, 2025
There was a problem hiding this comment.
pessoal, neste PR tem uma parte que o @renatonlima não achou bem legal #3626 por isso não teria como entrar dessa forma...
Qual é a parte? |
O return_fiscal_operarion_id que foi extraído no PR #3626 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 mesmo problema descrito na #2629, mas, ao final, permitimos o fechamento, pois achávamos que isso não seria mais necessário.
Os dados chegam embaralhados ao usar o wizard de devolução, sendo utilizados antes de serem preenchidos com os valores corretos.
Não considero isso apenas um problema de REF, pois corrige questões como:
Ao criar uma nota de devolução para anulação de venda (quando a própria empresa gera a devolução de todos os itens), o campo nfe40_dup é populado, fazendo com que a nota seja rejeitada (veja a imagem abaixo):
O correto seria não ter o campo nfe40_dup; portanto, o vDup não deveria nem ser zero.
A origem do erro é que, na hora de validar se é necessário gerar o nfe40_dup, a nota ainda está marcada como tipo "saída". A mudança para "entrada" pelo wizard ocorre apenas depois de os valores de duplicata terem sido gerados incorretamente:
O mesmo problema ocorre com uma nota de devolução para fornecedor emitida pela empresa: mesmo quando o campo nfe40_dup deveria ser criado, a inconsistência dos dados impede sua criação, gerando nova rejeição.