Registros C180 e C181

[Rômulo da Costa de Souza]

Boa tarde Pessoal, 

  Analisando o manual EFD-ICMS/IPI – Versão 3.0.6, identifiquei na página 307 o seguinte:

Para o Perfil A os registros C180 e C181, operações de entrada, até então pode ser informado no meu entendimento, porém no arquivo ACBrEFDBloco_C_Class, nos métodos "TBloco_C.WriteRegistroC180()" e "TBloco_C.WriteRegistroC181()", temos a seguinte validação:

if FBloco_0.Registro0000.IND_PERFIL in [pfPerfilA] then
  Check(False, 'O RegistroC181, não deve ser gerado em movimentações de saída, no %s, conforme ATO COTEPE 09/08', ['PerfilA']);

Gostaria de ver se alguém mais teve o mesmo entendimento. Se sim, poderíamos passar o objeto RegC100 para os métodos "TBloco_C.WriteRegistroC180()" e "TBloco_C.WriteRegistroC181()", e verificar se é uma operação de saída e for perfil A, levantamos a exceção!

[Juliomar Marchetti]

Favor anexar a alteração sugerida para que possa ser validado, assim podemos ver

[Rômulo da Costa de Souza]

Boa tarde Juliomar, 

  Segue em anexo o arquivo ACBrEFDBloco_C_Class.pas, peço que ignore as alterações da linha 1246 e no método TBloco_C.WriteRegistroC185().

ACBrEFDBloco_C_Class.pas

[Juliomar Marchetti]

Fiquei na dúvida  linha 2340

não está meio confuso o tratamento? e não estamos levando regras em que o software deve de agir e não o componente

[Rômulo da Costa de Souza]

Boa tarde Juliomar,

  Concordo! Efetuei esses tratamentos pelos códigos "RS" nos métodos TBloco_C.WriteRegistroC181() e TBloco_C.WriteRegistroC185() por causa do Validador do SPED ICMS/IPI, em alguns casos dependendo do código não pode ser enviado o valor 0 (zero), e sim o caractere delimitador. Pelo fato de estar corrido acabei fazendo o tratamento diretamente nos métodos. Uma solução seria alterarmos essas propriedades para o tipo Variant, com isso possibilitamos efetuar o tratamento pela aplicação.

Efetuei uma melhoria nesses métodos, segue em anexo o arquivo.

ACBrEFDBloco_C_Class.pas

[Juliomar Marchetti]

Olá

volto a dizer que não concordo em colocar regra de negocio componente , deixar aberto para que pessoa faça o correto

falo desses dois trechos abaixo

[EMBarbosa]

Em 25/01/2021 at 15:35, Rômulo da Costa de Souza disse:

Boa tarde Juliomar,

  Concordo! Efetuei esses tratamentos pelos códigos "RS" nos métodos TBloco_C.WriteRegistroC181() e TBloco_C.WriteRegistroC185() por causa do Validador do SPED ICMS/IPI, em alguns casos dependendo do código não pode ser enviado o valor 0 (zero), e sim o caractere delimitador. Pelo fato de estar corrido acabei fazendo o tratamento diretamente nos métodos. Uma solução seria alterarmos essas propriedades para o tipo Variant, com isso possibilitamos efetuar o tratamento pela aplicação.

Efetuei uma melhoria nesses métodos, segue em anexo o arquivo.

ACBrEFDBloco_C_Class.pas 150 kB · 2 downloads

Muito obrigado pela contribuição. Realmente a validação dos registros C180 e C181 estavam incompletos.
Fiz a implementação das validações baseada nela.

Subi as alterações relacionadas a isso para o SVN na Revisão  21368. Mas não subi nenhuma das outras alterações.

Sobre a questão de campos que podem tanto ficar vazios ou serem preenchidos com algum valor nulo (como zero ou espaço). O padrão dos componentes atualmente é usar como tipo de campo "Variant". Caso queira enviar correções nesse sentido, peço que por favor inicie um novo tópico. Pode ter uma ideia de implementar analisando o Registro C815.

Queira por favor atualizar, testar e reportar qualquer problema.

Mais uma vez obrigado.

[Rômulo da Costa de Souza]

Em 15/02/2021 at 15:18, EMBarbosa disse:

Muito obrigado pela contribuição. Realmente a validação dos registros C180 e C181 estavam incompletos.
Fiz a implementação das validações baseada nela.

Subi as alterações relacionadas a isso para o SVN na Revisão  21368. Mas não subi nenhuma das outras alterações.

Sobre a questão de campos que podem tanto ficar vazios ou serem preenchidos com algum valor nulo (como zero ou espaço). O padrão dos componentes atualmente é usar como tipo de campo "Variant". Caso queira enviar correções nesse sentido, peço que por favor inicie um novo tópico. Pode ter uma ideia de implementar analisando o Registro C815.

Queira por favor atualizar, testar e reportar qualquer problema.

Mais uma vez obrigado.

Bom dia,

  Certo, quando atualizarmos os fontes farei o teste, e logo em seguido devolvo o feedback!

Obrigado!

[Rômulo da Costa de Souza]

Boa tarde @EMBarbosa,

  Atualizei meus fontes, estou na revisão 21927, identifiquei a mudança do método LFill() pelo DFill(), nos métodos WriteRegistroC181() e WriteRegistroC185(), porém foi definido o parâmetro do decimal com o valor zero(0). Peço que ignore a linha 1246 do método WriteRegistroC100().

   Apenas para comentar essa troca do método LFill() pelo DFill(), pode ser que em alguns casos funcione. Porém a definição de gerar com o valor em branco ou zerado, para alguns campos depende do código do motivo da restituição, acredito que a melhor solução seria extrair essa definição do valor do campo para fora do componente. Quem sabe definir essas propriedades como Variant, conforme foi comentado  anteriormente.

 

Obrigado pela Atenção!

ACBrEFDBloco_C_Class.pas

[EMBarbosa]

Em 26/05/2021 at 18:04, Rômulo da Costa de Souza disse:

Boa tarde @EMBarbosa,

  Atualizei meus fontes, estou na revisão 21927, identifiquei a mudança do método LFill() pelo DFill(), nos métodos WriteRegistroC181() e WriteRegistroC185(), porém foi definido o parâmetro do decimal com o valor zero(0). Peço que ignore a linha 1246 do método WriteRegistroC100().

ACBrEFDBloco_C_Class.pas 148 kB · 0 downloads

Muito obrigado pela contribuição.
Fiz a implementação baseada nela.
Subi as alterações para o SVN na Revisão  21980.
Pelo que vi está tudo certo.
Queira por favor atualizar, testar e reportar qualquer problema.

 

Em 26/05/2021 at 18:04, Rômulo da Costa de Souza disse:

Apenas para comentar essa troca do método LFill() pelo DFill(), pode ser que em alguns casos funcione. Porém a definição de gerar com o valor em branco ou zerado, para alguns campos depende do código do motivo da restituição, acredito que a melhor solução seria extrair essa definição do valor do campo para fora do componente. Quem sabe definir essas propriedades como Variant, conforme foi comentado  anteriormente.

A saída é realmente mudar esses campos que podem ou não ser vazios para Variant. Existem outros campos assim.

Se desejar fazer a implementação fique a vontade que vamos avaliar.

Mais uma vez obrigado.