ZeusAutomacao
ICMS10 campo CST sempre 00
O campo CST esta como 10 e quando retorna na propriedade sempre retorna como 00, por enquanto somente quando é ICMS10
<ICMS>
<ICMS10>
<CST>10</CST>
</ICMS10>
</ICMS>
Olá, @gustavo-campos, tudo bem?
Você está se referindo à desserialização do XML para um objeto de classe?
Fiz alguns testes com essa tag e com o campo CST, e os valores foram atribuídos corretamente à propriedade da classe e também foram gerados corretamente no XML.
Você poderia compartilhar o XML que está utilizando para podermos analisar? Lembrando de remover ou substituir quaisquer dados sensíveis ou pessoais antes de compartilhar.
Boa tarde, @gustavo-campos
Fiz os testes com o XML que você forneceu. O problema ocorre devido a ordem das tags do XML.
No seu XML, a ordem está assim:
Note que as tag's orig e CST não estão na ordem determinada pela classe ICMS10, observe na imagem abaixo que essas duas tag's são as primeiras na ordem especificada:
Se você mover para a ordem correta, vai conseguir desserializar corretamente com CST 10:
Teste realizado no app de teste da biblioteca:
É possível que seja implementado um método que desserialize sem respeitar a ordem. Iremos analisar sobre. Caso também deseje, pode abrir um PR com a implementação de um método auxiliar para esses casos especificos.
Olá, @gustavo-campos . O XML disponibilizado tem origem no projeto DF-e?
Realizei o download de uma nota com CST 10 para tentar replicar, mas não houve erro algum. O problema ocorreu com outras emissões que utilizem a CST 10?
Ocorre em outras emissões, mas não é um problema corrente, mas sim intermitente, algumas notas caem nesse problema.
As notas que ocorrem o problema apresentam a divergência da sequencia mencionada por @AgnaldoSilva0, em comentário acima?
Dessa forma, será feita a análise de viabilidade sobre a sugestão de @AgnaldoSilva0 de um método que desserialize sem respeitar a ordem. Foram feitos testes de emissão com CST 10 a fim de encontrar a intermitência, mas nada foi encontrado. A análise continuará. Caso encontre alguma outra informação sobre a intermitência, agradeceríamos se compartilhasse.
Foi realizada uma análise mais aprofundada sobre o problema. Para isso, foi investigado todo o processo de emissão e serialização da NF-e com CST10. Durante esse processo, não foi encontrada nenhuma inconformidade por parte da biblioteca. Da mesma forma, como foi comentado que o erro ocorre de maneira intermitente, realizamos a replicação do cenário com base no XML fornecido. A nota foi emitida corretamente e sua consulta, realizada no site da SEFAZ, retornou o XML com a estrutura correta.
Ao avaliar o XML fornecido, foram notados pontos de divergência em relação às exigências da SEFAZ, como campos fora da ordem definida e atributos representados como tags. Por exemplo, é o caso do nItem, que, na nota fornecida, não está como atributo. Além disso, foi discutida, entre os mantenedores, a possibilidade de implementar um método que desserializasse um XML sem considerar a ordem dos campos. Essa implementação não será feita, pois um XML que não segue os padrões definidos pela SEFAZ será considerado inválido. Ainda assim, foram realizados testes com o XML fornecido e, ao organizar os campos corretamente, a desserialização ocorreu normalmente.
Diante disso, aparentemente não há qualquer problema relacionado à biblioteca DF-e, seja na emissão ou na importação do XML. Além disso, como não há outros relatos semelhantes, esta issue será encerrada.
Agradecemos por ter reportado a situação. Caso identifique qualquer outro comportamento inesperado, não hesite em compartilhar com a gente. Será sempre bem-vindo, obrigado!