Versões Layout

[bruno-crr]

Bom dia, a biblioteca suporta a geração de arquivos retroativos? Eu vi que passo o layout para o método de abertura , mas ele vai gerar os arquivos de acordo com a versão informada?

[marcosgerene]

@bruno-crr

É uma excelente ideia, mas infelizmente não é levado em consideração pelo projeto.

Não sei o @osamueloliveira, mas eu hoje não tenho essa necessidade (como tive com a leitura), então não pretendo implementar nem mesmo a longo prazo.

[bruno-crr]

Bom dia, entendi, to precisando implementar uma ferramenta de geração de SPED, mas temos muitos casos onde os clientes necessitam gerar o arquivo em algum Layout específico por conta de notificação do fisco.

[orochasamuel]

Fala @bruno-crr tudo na paz?

Cara... o que dá pra fazer é o seguinte, alterar a lib pra gerar de acordo com a versão que você escolher. Mas os registros mais novos, dos novos layouts serão gerados. Eu já tinha pensado em fazer algo relacionado a isso mas como não havia demanda não mexi com nada. Uma ideia é criar um atributo de data que seria verificado em cada propriedade no ato de geração, a problemática disso aqui é que teria um atributo para cada versão de layout e deixaria a tarefa de mapeamento das classes muito mais "chata", levando em conta que hoje temos 14 versões de layout para a EFD ICMS/IPI.

Vou pensar em algo (aceito sugestões) mais pra frente e retorno nesta issue. Vou deixar aberta enquanto isso.

Vida longa e próspera. 🖖

[orochasamuel]

Fala @bruno-crr, tudo na paz? Espero que sim. \o/

Iniciei a implementação desse recurso na biblioteca e já fiz algumas validações, tá rodando liso (até agora). Agora o que falta é mapear as propriedades com as alterações de cada layout para que seja possível fazer a geração retroativa.

O método que faz a escrita dos campos agora possui um parâmetro "CodigoVersaoLeiaute", caso informado, usará as regras de escrita da versão escolhida ou, caso não tenha o leiaute especificado irá utilizar as informações da última atualização do leiaute.

A versão estável ainda é a do Nuget, vou fazer mais algumas validações para me certificar de que tudo funcionará como devido.

Vida longa e próspera 🖖

[bruno-crr]

@orochasamuel tudo bem? que bom isso vai ficar ajudar muito, vou usar ela no projeto de um sistema de gestão em que estou trabalhando, no caso daqui pra frente os layouts novos sempre será criado no histórico e no caso de necessitar de um antigo no caso a receita só pode pedir os ultimos 5 anos, teria que criar a estrutura para esse layout especifico? nós mesmo conseguimos sobrescrever e criar um layout especifico necessário?

[orochasamuel]

Fala @bruno-crr, tudo ótimo por aqui. \o/

"[...] teria que criar a estrutura para esse layout especifico?" Reply: Não, a propriedade só precisa estar mapeada com as regras do layout desejado. Eu alterei o SpedCamposAttribute para ser múltiplo.

"[...] nós mesmo conseguimos sobrescrever e criar um layout especifico necessário?" Reply: Não, os layouts disponíveis serão os que já estão na lib.

Exemplo:

Versões do Layout

Em cada propriedade agora será definida a versão do layout, neste caso, o campo "CodVer" foi introduzido na primeira versão do layout e até então não houve alteração.

Caso houver alteração em alguma versão do layout é só incluir um novo atributo na propriedade. Não precisa incluir um atributo para cada versão, somente nas que houveram alteração naquele campo, seja de alteração na ORDEM, NOME, TIPO, ou até mesmo no TAMANHO e alteração de OBRIGATÓRIO sim/não.

Ao escrever as linhas basta usar o método EscreverCampos COM ou SEM versão informada, caso a versão do layout não seja informada a geração será feita usando a última versão do layout implementada na lib.

PS: Nos exemplos acima eu usei a versão 1, mas ela não existe na verdade, como você pode ver na lista de códigos de versão. Antes de publicar essas alterações no Nuget eu vou revisar o layout e incluir as versões nos campos mais usados, será um trabalho gradual, assim como é feito o mapeamento e inclusão de novos registros e campos. Mas logo logo toda a lib estará com as informações específicas de cada layout.

Vida longa e próspera 🖖

[orochasamuel]

@bruno-crr pode me explicar melhor essa necessidade? 👇

"[...] nós mesmo conseguimos sobrescrever e criar um layout especifico necessário?"

[marcosgerene]

@orochasamuel

Alguns softwares de contabilidade usam um layout próprio, basicamente é o que já existe com alguns campos a mais. Ex: dados de Pis/Cofins no SPED Fiscal.

@bruno-crr

Quando eu progravama em Delphi o ACBr permitia fazer isso (editar a linha gerada) nos eventos antes de escrever.

Aqui, em caso de geração linha a linha pelo usuário, basicamente é editar a linha gerada.

Ccaso de geração seja "automatizada" (preencher as classes com seus filhos e mandar gerar) talvez um evento antes de escrever a linha resolva. O processo consiste basicamente em permitir editar a linha antes de adicionar na Lista de linhas.

---

Edit: mandei um commit sem nem testar, ainda não abri PR. A ideia é só mostrar uma forma de implementar como o ACBr fazia na época.

https://github.com/marcosgerene/fiscalbr.net/commit/78fcd312a40356f2040a5b1eddcc0e7e47c05371

[orochasamuel]

@marcosgerene o que eu não entendi é a ideia do "layout próprio" na geração do arquivo, sendo que se não for gerado conforme as especificações do layout o PVA não vai validar o arquivo.

Para leitura eu até concordo, talvez as informações com que o software trabalhem não são as mesmas (específicas) do layout e seria esse o caso de alterar para compatibilizar.

Confesso que estou tentando entender o cenário mas não consigo enxergar o aproveitamento disto. Posso não ter entendido a ideia mas, implementar algo assim na lib vai fugir ao propósito de gerar o arquivo especificamente para validação no PVA. Talvez, se eu conseguir entender o propósito a fundo possamos pensar em algo a respeito.

EDIT @bruno-crr esse é seu cenário atualmente? Pode me dar um exemplo?

@adrianotrentim se não me engano já conversamos sobre algo a respeito. Você também tem essa necessidade?

Vida longa e próspera 🖖

[bruno-crr]

@bruno-crr pode me explicar melhor essa necessidade? 👇

"[...] nós mesmo conseguimos sobrescrever e criar um layout especifico necessário?"

Eu tinha entendido que foi implementado para gerar de acrodo um uma versao de layout, mas que as versões seriam criadas daqui pra frente apenas, nao achei que vc iria criar todos os layouts anteriores, pensei que caso eu precisasse do layout 2 por exemplo eu teria que implementar o registro para ele sobrescrevendo o registro geral.

Sobre a questao de editar a geracao de um registro em um layout próprio não era o que eu tinha em mente. Seria sobre criar os layouts passados mesmos.

[bruno-crr]

@orochasamuel

Alguns softwares de contabilidade usam um layout próprio, basicamente é o que já existe com alguns campos a mais. Ex: dados de Pis/Cofins no SPED Fiscal.

@bruno-crr

Quando eu progravama em Delphi o ACBr permitia fazer isso (editar a linha gerada) nos eventos antes de escrever.

Aqui, em caso de geração linha a linha pelo usuário, basicamente é editar a linha gerada.

Ccaso de geração seja "automatizada" (preencher as classes com seus filhos e mandar gerar) talvez um evento antes de escrever a linha resolva. O processo consiste basicamente em permitir editar a linha antes de adicionar na Lista de linhas.

Edit: mandei um commit sem nem testar, ainda não abri PR. A ideia é só mostrar uma forma de implementar como o ACBr fazia na época.

marcosgerene@78fcd31

Bom dia, creio que isso em algum momento vai acabar sendo necessário em algum cenário , seria uma implementação interessante, ainda nao tive nehum caso com essa necessidade.

[orochasamuel]

Ahhhhhhhhhhhh, entendi.

Da forma como eu implementei existe um attributo para a vigência do registro (SpedRegistros), como é o caso dos registros do bloco K por exemplo, e outro atributo para os campos (podendo ter mais de 1 pois houveram alterações nos layouts).

Exemplo, se você precisar do layout na versão 2, basta informar na geração do arquivo V2 e a DATA DE COMPETÊNCIA do arquivo. Os registros que ainda não existiam no layout nessa versão não serão gerados, que é o caso dos registros do Bloco K por exemplo. Não vai alterar em nada a sua escrita para geração das linhas, a própria lib é que vai se responsabilizar pelo que será gerado ou não. A diferença é que agora quando gerar uma linha, se o registro em questão não existir naquela versão do layout o retorno do método será null, você vai precisar validar antes de incluir no TXT.

Vida longa e próspera 🖖

[bruno-crr]

Ahhhhhhhhhhhh, entendi.

Da forma como eu implementei existe um attributo para a vigência do registro (SpedRegistros), como é o caso dos registros do bloco K por exemplo, e outro atributo para os campos (podendo ter mais de 1 pois houveram alterações nos layouts).

Exemplo, se você precisar do layout na versão 2, basta informar na geração do arquivo V2 e a DATA DE COMPETÊNCIA do arquivo. Os registros que ainda não existiam no layout nessa versão não serão gerados, que é o caso dos registros do Bloco K por exemplo. Não vai alterar em nada a sua escrita para geração das linhas, a própria lib é que vai se responsabilizar pelo que será gerado ou não. A diferença é que agora quando gerar uma linha, se o registro em questão não existir naquela versão do layout o retorno do método será null, você vai precisar validar antes de incluir no TXT.

Vida longa e próspera 🖖

Opa blz , entao ficou melhor ainda, mas por exemplo no registro C100 vamos supor que no Lay 2 tinha 10 campos, e no lay 15 agora tem 16 campos, isso vc já deixou implementado tmb na rotinha de gerar a linha? sei que as variaçoes foram poucas nos registros , mas creio que existiu em agluns.

[orochasamuel]

Sim, já deixei implementado a geração para esse cenário também. (eu vou fazer testes unitários para validar que está funcionando 100%)

Caso exista apenas 1 atributo para definição do campo, será utilizado. Caso exista mais de 1 vai procurar o atributo para definição do campo com a versão específica informada. Caso não encontre, busca a definição na versão anterior até encontrar.

Assim eu consigo me certificar de que nos casos em que houve alteração da ORDEM dos campos a geração seja feita em ordem crescente para não quebrar a estrutura do layout.

Vida longa e próspera 🖖

[bruno-crr]

Sim, já deixei implementado a geração para esse cenário também. (eu vou fazer testes unitários para validar que está funcionando 100%)

Caso exista apenas 1 atributo para definição do campo, será utilizado. Caso exista mais de 1 vai procurar o atributo para definição do campo com a versão específica informada. Caso não encontre, busca a definição na versão anterior até encontrar.

Assim eu consigo me certificar de que nos casos em que houve alteração da ORDEM dos campos a geração seja feita em ordem crescente para não quebrar a estrutura do layout.

Vida longa e próspera 🖖

Maravilha então ficou 100%, esse recurso era importante pra garantir no caso do fisco solicitar uma geração retroativa, Obrigado ai pelo retorno!!

[orochasamuel]

👍

EDIT: Assim que eu fizer os testes para esse cenário do C100 eu posto o resultado aqui.

[marcosgerene]

@orochasamuel @bruno-crr

Voltei agora do almoço e tenho visita a cliente daqui alguns minutos, não vou conseguir dar atenção a isso, mas se acharem interessante a minha implementação é só falar que testo e levo ela mais a sério até virar um PR.

[RaCastroBR]

Boa noite @orochasamuel.

Esse assunto evoluiu? Conseguiu fechar o versionamento?

Obrigado

[candinho1987]

Boa noite, para leitura de arquivo de versão anterior tem como informar o "CodigoVersaoLeiaute.V15" por exemplo

[orochasamuel]

@RaCastroBR vou retomar a verificação dessas versões do layout e criar alguns testes.

@candinho1987 para a leitura do layout "versionado" não foi feita a implementação ainda, quem fez as features de leitura foi o @marcosgerene e a equipe dele.

Vou trabalhar na lib para chegarmos em uma versão estável no que diz respeito à geração retroativa das informações.

[marcosgerene]

@orochasamuel

Posso estar enganado, mas acredito que para a leitura acho que o versionamento não faz diferença. Uma vez que o arquivo já está gerado, se determinado registro ou campo não existia na versão anterior ele vai ser desconsiderado/marcado como nulo.

Se tiver algum arquivo antigo ai e quiser que eu ajuste algo na leitura nesse sentido me chama no WhatsApp.

Valeu.

[orochasamuel]

@orochasamuel

Posso estar enganado, mas acredito que para a leitura acho que o versionamento não faz diferença. Uma vez que o arquivo já está gerado, se determinado registro ou campo não existia na versão anterior ele vai ser desconsiderado/marcado como nulo.

Se tiver algum arquivo antigo ai e quiser que eu ajuste algo na leitura nesse sentido me chama no WhatsApp.

Valeu.

@marcosgerene a issue #53 relata algumas dificuldades de se ler arquivos antigos.

[marcosgerene]

@orochasamuel

Se me arrumar um arquivo antigo com esse problema posso tentar arrumar, me manda no whatsapp ou e-mail o arquivo que vejo!

[orochasamuel]

Pessoal,

Na issue #109 descrevi a implementação inicial da detecção de versão para a EFD Fiscal.

Se esse assunto voltar a ser necessário e melhor iniciar uma nova issue.

Vida longa e próspera 🖖