Skip to content
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

Criação do atributo personalizado "[TString]" o qual deve ser utiliza… #6

Conversation

danilobreda
Copy link
Collaborator

Pullrequest de @silvairsoares no Zeus puxado para cá.

silvairsoares commented Apr 18, 2024

Criação do atributo personalizado "[TString]" o qual pode ser utilizado para decorar todas as proriedades referentes às tags do xml do tipo "TString".
Com o objetivo de corrigir automaticamente os dados destas propriedades, evitando a falha de schema:

O elemento '<nome_elemento>' é inválido - O valor 'exemplo de valor inválido' é inválido de acordo com o seu tipo de dados 'String'

Já inclui a anotação em alguns atributos, mas será necessário incluir nos demais. São centenas.

Fiz algumas alterações nos dados da NFe gerados no arquivo "NFe.AppTeste.NetCore/Program.cs" somente para teste da funcionalidade.

Na solução em que uso este atributo corretor, inclui a chamada para o método "ExecutarCorrecaoDeDados" no construtor da classe "InfNFe". Pois aqui, tenho apenas um construtor, que solicita que todos os dados sejam enviados. Então, tenho algo como:

public partial class InfNFe : ClasseNFe
{
    public InfNFe(ide ide, emit emit, avulsa avulsa, dest dest, TLocal retirada, TLocal entrega,
                List<autXML> autXML, List<det> det, total total, transp transp, cobr cobr, pag pag,
                infIntermed infIntermed, infAdic infAdic, exporta exporta, compra compra, cana cana,
                infRespTec infRespTec, string versao, string id)
    {
        this.ide = ide;
        this.emit = emit;
        this.avulsa = avulsa;
        this.dest = dest;
        this.retirada = retirada;
        this.entrega = entrega;
        this.autXML = autXML;
        this.det = det;
        this.total = total;
        this.transp = transp;
        this.cobr = cobr;
        this.pag = pag;
        this.infIntermed = infIntermed;
        this.infAdic = infAdic;
        this.exporta = exporta;
        this.compra = compra;
        this.cana = cana;
        this.infRespTec = infRespTec;
        this.versao = versao;
        Id = id;

        ExecutarCorrecaoDeDados(this);
    }

Assim tenho a garantia que todos os dados de todas as instâncias da classe "InfNFe" sempre estarão normalizados.
Mas aqui não foi possível pois existe apenas o construtor padrão:

public infNFe()
{
    det = new List<det>();
}

Não encontrei um local centralizado, que garantisse a execução do método "ExecutarCorrecaoDeDados(this);". Portanto, ficaria a cargo do desenvolvedor encontrar o melhor local para invocação deste método.

Esse recurso me ajudou demais aqui, evitando centenas de verificações dentro do ERP.

Seguindo esta mesma idéia, outros atributos semelhantes ao [TString] poderão ser criados no futuro.

…do para decorar todas as proriedades referentes às tags do xml do tipo "TString".

Com o objetivo de corrigir automaticamente os dados destas propriedades, evitando a falha de schema "O valor '@@@' é inválido dependendo do tipo de dados 'String'".
Já inclui a anotação em alguns atributos, mas será necessário incluir nos demais. São centenas.
@danilobreda
Copy link
Collaborator Author

danilobreda commented Apr 20, 2024

@silvairsoares tudo certo? esse é o fork do Zeus, Vamos analisar seu pullrequest em breve! Obrigado pela contribuição!

@silvairsoares
Copy link

silvairsoares commented Apr 22, 2024

Caso achem a solução interessante, me compromento a fazer um novo PR, marcando as demais tags da NF-e/NFC-e que são do tipo TString.
É basicamente um trabalho braçal, mas muito extenso. São centenas de tags desse tipo espalhadas por todo o schema do XML.

@danilobreda
Copy link
Collaborator Author

danilobreda commented Apr 27, 2024

Aqui vai meu pensamento sobre a proposta:

Não sei se é algo que o ZeusFiscal deveria se preocupar. Se pegamos a responsabilidade de que formatamos a string da melhor maneira, isso pode ser um problema muito grande para nós como responsabilidade e mantenedores.
Pensando alto: E se tiver um bug e formatarmos o CFOP incorretamente e o cliente emitir tudo errado.
Naturalmente o programador resolve isso no sistema dele dando um trim().

A remoção de acentuação é uma opção hoje que faz +- isso, porem é feito diretamente no XML, não propriedade por propriedade. Achei complexo a implementação :/ e principalmente para dar manutenção

@marcosgerene
Copy link
Collaborator

Minha opinião segue a do @danilobreda.

Entretanto acho um Add-On legal... que tal um projeto de extensão @silvairsoares ?

@silvairsoares
Copy link

silvairsoares commented Apr 29, 2024

Minha opinião segue a do @danilobreda.

Entretanto acho um Add-On legal... que tal um projeto de extensão @silvairsoares ?

Concordo com a opinião de vocês. Realmente, se abrir precedente pra este tipo de tratamento, propriedade por propriedade, os usuários destas soluções já teriam esta expectativa e seria algo muito pesado de se manter, além de uma baita responsabilidade.
Aqui, eu implementei esta funcionalidade no nosso SDK que comunica com a API de emissão de notas, e não diretamente nesta API.
Vou avaliar esta possibilidade de criar um Add.On, porém acho difícil ser viável, uma vez que a minha proposta exige que as propriedades das classes usadas para gerar os payloads com os dados dos DFE-s, sejam decorados, e estas classes, já está implementadas dentro do próprio Hercules/ZeusFiscal.
De qualquer forma, agradeço pelo tempo dispensado na alálise da minha proposta.

@danilobreda
Copy link
Collaborator Author

danilobreda commented May 3, 2024

Vou fechar, se aparecer alguma ideia diferente sobre esse assunto não deixe de compartilhar com a gente.
Muito obrigado pela contribuição @silvairsoares

@danilobreda danilobreda closed this May 3, 2024
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 merging this pull request may close these issues.

4 participants