Integração com Banco de Dados

[orochasamuel]

Galera, o que acham desta ideia? Sugestão do @leandrossantos

@marcosgerene @marcianobandeira @adrianotrentim @ebitencourt @ThalyaAutocom @PGama-Rodrigo @hbdbim @EderWillian @eduarda80

Issue #22

[hbdbim]

Eu nem entendi a demanda.

Tenho uma outra sugestao, um parser que eu fiz mais ou menos.

Tem essa lib de emissao de nfs, muito utilizada.
dfe.net

Eu fiz um parser pra passa as classes dela para os blocos do sped.
Entao eu pego os xml das notas, carrego nas classes dessa lib e depois faço o parse para o sped.

[marcianobandeira]

interessante

[orochasamuel]

A ideia é boa @hbdbim

É possível incluir essa feature.

[hbdbim]

Fiz um comit no meu fork.
se quiser dar uma olhada... nao vai estar funcionando pq comentei varios blocos que utilizavam classes do meu ERP, mas da pra ter uma ideia doque estou falando.

https://github.com/nerd-working/fiscalbr.net

[marcosgerene]

@orochasamuel

Toda vez que engajo em discussões assim acabo sempre optando pelo "menos é mais".

Na minha visão o projeto tem que se ater em gerar e ler o arquivo os arquivos que se propõe.

[orochasamuel]

@marcosgerene se a ideia for boa e alguém tiver demanda podemos analisar para incluir, eu não quero "inflar" a biblioteca com coisa demais mas, ter o máximo possível de features para atender o ecossistema do Sped.

Nesse caso do banco de dados separado, creio não termos aproveitamento (pelo menos não por hora), vou encerrar a discussão e iniciar o andamento na ideia do parser que o @hbdbim citou.

Essa feature do parser precisa ser independente, quem quiser usar usa, quem não quiser não usa. Vou providenciar um MVP da ideia.

@hbdbim você fez o parser somente de NF-e e NFC-e? Tem demanda para CT-e aí na empresa?

[hbdbim]

CT-e também.
Vocë percebeu que ele depende da outra lib, certo ?
Acho que o ideal seria fazer uma dll separada para o parser.

Oque acha ?
Ja esta banstante completo o parse, tem que limpara umas coisas que são dependencias do meu ERP e vazer algumas validações ai do pessoal que tem mais esperiencia contabil que eu .

[marcosgerene]

Eu não gosto da ideia do Parse mesmo que em um projeto separado, eu sou um pouco "radical" nesse sentido.

O projeto "FiscalBr.NET" tem que ser bom em ler e gerar o arquivo SPED, ponto final.

Se existe um FiscalBr.NET.CTe que lê o CTe e tenta jogar para as classes do SPED mas ele não atende à alguma regra X de negócio pronto, temos um problema, e o nome FiscalBr.NET como um todo é afetado.

Não me oponho a iniciativa dos senhores de criar um novo projeto com o tempo e recurso dos senhores, mas como a minha opinião foi solicitada na discussão achei válido trazer esse ponto de vista.

[hbdbim]

Concordo com suas colocações mas acho que na balança vale a pena.

[marcosgerene]

@hbdbim

Entendo seu ponto de vista, mas discordo inclusive que na balança valha a pena.

Meu argumento se baseia no principio da responsabilidade.

• O projeto do SPED deve ater-se somente ao SPED;
• o do CTe deve-se ater somente ao CTe;
• o ERP que consome ambos deve tratar da integração;

Por experiência digo que um projeto que tenta fazer tudo não faz nada bem feito.

[orochasamuel]

Bom, vamos lá.

Do meu ponto de vista, o Parser tem seus prós e contras mas, tem mais prós.

PROS

• Dá maior agilidade na "população" das classes de documentos fiscais (C100, D100, etc).
• Se fizer uso de uma lib externa (DFe.NET, por exemplo), toda a responsabilidade de atualização do layout será dessa lib, o FiscalBr, só fará a "leitura" e transcrição para layout do SPED.
• Esse tipo de recurso seria usado em larga escala para negócios menores, visto que o nível de adaptação tende a ser menor nesses casos.

CONTRAS

• Caso seu negócio tenha uma demanda para personalização na escrita de alguns registros a ferramenta não seria tão útil mas, ainda assim serviria de base para a escrita do seu próprio parser para atender as demandas dos seus clientes.
• A ferramenta se torna refém da estabilidade da DLL do terceiro que implementar a leitura do layout da NF-e, NFC-e, CT-e, etc.

[marcosgerene]

@orochasamuel

• Dá maior agilidade na "população" das classes de documentos fiscais (C100, D100, etc).

Discordo, só vejo maior complexidade. Se a aplicação é pequena é desnecessária essa performance, se é grande as regras de negócio provavelmente não serão atendidas.

• Se fizer uso de uma lib externa (DFe.NET, por exemplo), toda a responsabilidade de atualização do layout será dessa lib, o FiscalBr, só fará a "leitura" e transcrição para layout do SPED.

• Esse tipo de recurso seria usado em larga escala para negócios menores, visto que o nível de adaptação tende a ser menor nesses casos.

Sarna para se coçar.

Nota fiscal de saída até vai, mas e entrada? O cara tem que fazer a conversão uma vez que o enfoque é no declarante, o usuário iniciante vai querer fazer o "load" do XML no objeto do DFe.NET e que a aplicação faça a mágica pro SPED, ai a conversão está incorreta (ex: compra de uso e consumo 5102 -> 1556) e issue com "problemas".

---

Estou nessa discussão porque fui "citado", estou fazendo o papel de advogado do diabo, obviamente o tempo/recurso que os senhores quiserem empregarem em novas funcionalidades sempre são vistos com bons olhos, mas acho essa iniciativa um gasto de recursos fadada a falhar.

[elieltonbitencourt]

Também penso assim, se a aplicação chegou ao ponto de gerar SPED, já deve ter suas regras para lançamentos de entrada de forma individual para cada NF-e.
Da mesma forma para as saídas, se o sistema emitiu a NF-e, normalmente já tem as informações no próprio banco de dados.
Não que seja algo ruim, mas pensando um pouco mais a frente vejo um config cheio de parâmetros de tratamento de conversões para cada situação.
Essa é minha opinião com base na minha realidade e posso estar errado mas acredito que seja também da maioria que chega na "fase" do SPED.
De qualquer forma DFE.Net é uma lib estável e confiável se optarem por seguir o caminho, a questão da dependência não deve ser problema.