8000 Melhora no ValidacaoSchemaException by henriqueTr25 · Pull Request #70 · Hercules-NET/ZeusFiscal · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Melhora no ValidacaoSchemaException #70

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 clicki 8000 ng “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

Conversation

henriqueTr25
Copy link
Contributor

Introdução

Ao realizar validação do schema do xml, por vezes não é possível ter acesso ao xml gerado para podermos revisar, o que nos resta seria remover o pacote nuget temporariamente e subir o projeto zeus no nosso projeto. Isso é por vezes necessário, porém burocrático e pouco eficiente.

O que foi feito

Por esse motivo, eu resolvi criar o atributo XmlString no ValidacaoSchemaException. Isso traz uma vantagem no momento de realizar algumas chamadas que não temos o poder de montar o xml para envio.

Exemplo de problema causado

Para exemplificar, eu tive um problema ao realizar um cancelamento de nota ao chamar o método servicoNFe.RecepcaoEventoCancelamento(1, 1, protocolo, chaveNFe, justificativa, cpfCnpj);

O xml de envio de cancelamento é montado internamente e não temos acesso ao que foi gerado para conferir possíveis inconsistências.

Solução

Com essa mudança, caso qualquer validação de schema falhe, o xml com falhas virá junto ao ValidacaoSchemaException, facilitando o debug para correções de problemas sem a necessidade de referenciar o projeto diretamente.

Como utilizar

try 
{
   servicoNFe.RecepcaoEventoCancelamento(1, 1, protocolo, chaveNFe, justificativa, cpfCnpj);
}
catch(ValidacaoSchemaException vsex) 
{
   //tenho acesso ao xml através desse atributo: 
   vsex.XmlString
}

Objetivo final

Facilitar o debug da aplicação sem a necessidade de referenciar o projeto Zeus Fiscal no meu projeto para essa situação

@marcosgerene
Copy link
Collaborator

@henriqueTr25

Em primeiro lugar obrigado pela contribuição, entendo perfeitamente sua dor e sua implementação é de grande ajuda.


Mas gostaria de dar um pitaco (não na sua contribuição, mas no projeto como um todo):

Na minha visão o problema é mais profundo. No exemplo citado o ideal seria chamar o cancelamento passando um objeto e não parametros. O problema está no ínicio do projeto que virou uma "salada" de padrões.

Entendo que reescrever uma parte razoavel do projeto (refatoring) seria o ideal, mas isso exige recursos (tempo) que não temos. Logo, soluções "de contorno" como a sua são muito bem vindas.

@marcosgerene marcosgerene merged commit eed6b19 into Hercules-NET:master May 31, 2025
1 of 2 checks passed
@henriqueTr25
Copy link
Contributor Author

@marcosgerene Entendo. Convivo com o mesmo problema aqui na empresa também, acredito que não tem muito pra onde correr, as demandas sempre superam o tempo que temos pra reorganizar e refatorar os projetos. Infelizmente.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully mergi 3983 ng this pull request may close these issues.

2 participants
0