Alteração da geração do registro 0110

[manoel_totall]

Olá, gostaria de informar que o SPED na última versão estava criticando o registro 0110, informando que o registro deveria conter apenas 4 campos, e continha 5, analisando o código e o layout, percebi que no layout o último campo estava em azul e com um condicional (COD_INC_TRIB = 2), no meu entender, se o COD_INC_TRIB for igual a 1 ou 3, então o último campo não deveria ser enviado, minha alteração do método "WriteRegistro0110" da classe "TBloco_0" unit "ACBrEPCBloco_0_Class" ficou assim:

procedure TBloco_0.WriteRegistro0110(Reg0001: TRegistro0001) ;

var

strCOD_INC_TRIB: string;

strIND_APRO_CRED: string;

strCOD_TIPO_CONT: string;

strIND_REG_CUM: string;

begin

if Assigned(Reg0001.Registro0110) then

begin

with Reg0001.Registro0110 do

begin

case COD_INC_TRIB of

codEscrOpIncNaoCumulativo: strCOD_INC_TRIB := '1';

codEscrOpIncCumulativo: strCOD_INC_TRIB := '2';

codEscrOpIncAmbos: strCOD_INC_TRIB := '3';

end;

case IND_APRO_CRED of

indMetodoApropriacaoDireta: strIND_APRO_CRED := '1';

indMetodoDeRateioProporcional: strIND_APRO_CRED := '2';

end;

case COD_TIPO_CONT of

codIndTipoConExclAliqBasica: strCOD_TIPO_CONT := '1';

codIndTipoAliqEspecificas: strCOD_TIPO_CONT := '2';

end;

case IND_REG_CUM of

codRegimeCaixa : strIND_REG_CUM := '1';

codRegimeCompetEscritConsolidada : strIND_REG_CUM := '2';

codRegimeCompetEscritDetalhada : strIND_REG_CUM := '9';

end;

// Manoel - 09/01/2012 - Estava dando erro no SPED, pois o mesmo falava que tinha que haver 4 campos

// olhando no layout, entendeu-se que só se deve mandar o campo 5 se o mesmo existir, ou seja, se ele

// estiver em branco (campo strIND_REG_CUM) não é enviado

if COD_INC_TRIB = codEscrOpIncCumulativo then begin

Add( LFill('0110') +

LFill( strCOD_INC_TRIB ) +

LFill( strIND_APRO_CRED ) +

LFill( strCOD_TIPO_CONT ) +

lFill( strIND_REG_CUM ) ) ;

end else begin

Add( LFill('0110') +

LFill( strCOD_INC_TRIB ) +

LFill( strIND_APRO_CRED ) +

LFill( strCOD_TIPO_CONT ) ) ;

end;

///

if IND_APRO_CRED = indMetodoDeRateioProporcional then

WriteRegistro0111(Reg0001.Registro0110);

end;

Registro0990.QTD_LIN_0 := Registro0990.QTD_LIN_0 + 1;

/// Variavél para armazenar a quantidade de registro do tipo.

FRegistro0110Count := FRegistro0110Count + 1;

end;

end;

Posso estar enganado, se estiver gostaria que me informassem como proceder com este registro, e o porquê da reclamação do gerador...

[EMBarbosa]

O que acontece é que o PVA que você testou não está pronto para receber esse layout. O quinto campo deve ser enviado sim, mas será vazio, ou seja, ||.

[triguinhu]

Ola, Bom dia pessoal

Enfrento o mesmo problema...

Como proceder? Faço as modificações no layout que o amigo sugeriu, ou devo informar || , alterando tbm o layout?

É necessário alguma alteração no componente? Devo enviar a minha modificação que fizer para auxiliar o componente, ou ja existe alguém responsável por essa alteração no componente ( logicamente se for necessário fazer a alteração )

Muito obrigado

Rodrigo

[EMBarbosa]

Você deve seguir o modo que o Guia Prático informar. O PVA é usado para garantir que está fazendo igual ao Guia Prático pede, principalmente em pontos ambíguos. Mas acontece de o PVA estar desatualizado.

Pelo menos foi o que entendi...

[triguinhu]

Pessoal, Bom dia

Realmente na ultima versão do PVA isto esta ocorrendo... Fiz a alteração sugerida pelo amigo do primeiro post, e deu certo.. o componente esta mandando quando o quarto campo fosse 1 um registro 1 no quinto campo..o que esta diferente no manual.. e esta sendo criticado na ultima versão do PVA..

Isso ja esta modificado na ultima versão do componente? Se eu atualizar o componente terei que refazer essa modificação?

Abraços e desculpem a ignorancia

Rodrigo

[EMBarbosa]

Última versão que você diz é a 1.0.7? Caso negativo, favor baixar o novo validador e testar novamente.

Se o PVA está criticando, por favor anexe a mensagem do PVA ou um arquivo de exemplo para que possamos testar.

Quanto a você atualizar, se atualizar pelo Tortoise, ele vai tentar fazer um Merge das alterações. Se não for possível, ele vai indicar que houve um conflito e assim você vai ter que intervir manualmente.

EDIT: Agora que vi no site, acho que só a versão 2.0 do PVA é que vai contemplar esse modelo.

A versão 1.07 ainda não contempla os registros da escrituração das pessoas jurídicas tributadas pelo Lucro Presumido, cuja versão do PVA (versão 2.0) deverá ser disponibilizada no mês de abril de 2012.

Ainda assim, você deve sempre fazer os testes com a versão mais nova.

[EMBarbosa]

A propósito, se você tentar validar algum arquivo com 5 campos no PVA atual, mesmo que COD_INC_TRIB = codEscrOpIncCumulativo, ele vai falar que o arquivo está em formato errado e não vai nem importar para o PVA.

Será necessário a versão 2.0 do PVA para poder validar os arquivos nesse modelo.

Pensando nisso, fiz uma alteração no código só pra deixar isso mais claro.

Espero que sane as dúvidas a este respeito.

[triguinhu]

Blz pessoal, Bom dia a todos..

Em anexo esta um arquivo JPG do print de tela, da configuração de PIS e COFINS da empresa cliente..

De acordo com essas configurações o componente manda o registro 0110 da seguinte forma:

|0110|1|2|1|1|

Ae, ao importar no PVA ultima versão ( baixado na semana passada ) da erro de estrutura..

O erro do PVA eu salvei em formato pdf e anexei tbm aqui nessa mensagem...

Ao retirar o ultima coluna , a importação passa sem crise..

Fica assim:

|0110|1|2|1|

Analisem por gentileza, pode ser alguma coisa passando despercebido pela gente...

Abraço

Rodrigo

erro_pva.pdf

[triguinhu]

Desculpe, grande EMBarbosa

Não havia lido ainda suas sugestões.. vou atualizar aqui o componente e dar uma checkada.. não perca ainda seu tempo analisando o que passei.. vou testar primeiro aqui

Abração

Rodrigo

[triguinhu]

Bom dia novamente pessoal

Com relação ao EFD PIS COFINS... eu estou com a versão 1.0.7 .. e é nela que esta ocorrendo o problema com o registro 0110.. a versão 2.0 no site da receita diz que vai ter PVA só em abril de 2012... estou viajando quanto a esse abril de 2012? é isso mesmo?

Pra atualizar o componente eu preciso recompilar no Delphi o componente, ou é só a mudança dos arquivos resolve? Uso o Tortoise...

Abraços

Rodrigo

[EMBarbosa]

Sim. A versão 2.0 do PVA está programada para ser lançada só em abril de 2012.

Você provavelmente vai precisar fazer um Build nos componentes. Antes, verifique no Explorer se não está marcando algum dos arquivos como modificado ou como conflito.

Se for o caso, é aconselhado fazer um checkout novamente...

Por último, favor fazer o teste no DEMO.

[Gr@c@]

Estou enfrentando esse mesmo problema. O validador informa Valor Calculado = 4 e Conteudo do Campo = 5.

Empresa com regime de incidência = cumulativo

Fiz o update do componente do ACBrSpedFiscal hoje (12/03/2012) mas o erro continua.

E eu só estou informando

COD_INC_TRIB = 2

COD_TIPO_CONT = codIndTipoConExclAliqBasica

IND_REG_CUM = codRegimeCompetEscritDetalhada (esse campo só se aplica se COD_INC_TRIB = 2 que é o caso)

No caso não informo IND_APRO_CRED pois só se aplica se COD_IND_TRIB = 1 ou 3

mas estão sendo gerados 5 campos

|0110|2|1|1|1|

acho que deveria ser

|0110|2|1|1|

[EMBarbosa]

Você quer dizer SPEDPisCofins né?

[Gr@c@]

ih, Desculpe, SPEDPisCofins

Com Regime de Incidência Não Cumulativo deu certo, gerou apenas 4 campos. O erro está no Cumulativo que está gerando 5 campos.

[EMBarbosa]

hehe.

Então, é que o PVA 1.0.7 não está pronto para validar registros pro Lucro Presumido (regime cumulativo)

Olhe esse meu comentário com o link para o site do SPED http://www.djsystem.com.br/acbr/forum/viewtopic.php?p=23835#p23835.

Daí a gente precisa esperar sair a versão 2.0 do PVA...

[dsv2]

Pessoal,

Estou no layout Versão_104 e com a versão do validador 1.0.7.

Mesmo assim ocorre o erro. Olhando os fontes me deparei com erro:

03 IND_APRO_CRED

Código indicador de método de apropriação de créditos

comuns, no caso de incidência no regime nãocumulativo

(COD_INC_TRIB = 1 ou 3):

1 – Método de Apropriação Direta;

2 – Método de Rateio Proporcional (Receita Bruta)

Ou seja, só informar o campo se o indicador for 1 ou 3, mas no meu caso o meu indicador foi 2 (codEscrOpIncCumulativo "Cumulativo").

Olhando o fonte temos:

if (COD_INC_TRIB = codEscrOpIncCumulativo) then

//Nota: Só a versão 2.0 ou superior do PVA vai estar pronta para validar esse arquivo.

Add( LFill('0110') +

LFill( strCOD_INC_TRIB ) +

LFill( strIND_APRO_CRED ) + // Aqui está o problema. se o tipo for 2, não podemos informar este campo. Total de campos = 5, sendo que deve ser 4

LFill( strCOD_TIPO_CONT ) +

lFill( strIND_REG_CUM ) );

Correto:

if FRegistro0000.COD_VER >= vlVersao101 then

begin

//Verificar a necessidade desse if abaixo quando sair a versão 2.0 do PVA PisCofins

if (COD_INC_TRIB = codEscrOpIncCumulativo) then

//Nota: Só a versão 2.0 ou superior do PVA vai estar pronta para validar esse arquivo.

Add( LFill('0110') +

LFill( strCOD_INC_TRIB ) +

//LFill( strIND_APRO_CRED ) +

LFill( strCOD_TIPO_CONT ) +

lFill( strIND_REG_CUM ) )

[EMBarbosa]

Olá dsv2,

Essa Vou grifar em vermelho uma parte do código que você despercebeu.

if (COD_INC_TRIB = codEscrOpIncCumulativo) then

//Nota: Só a versão 2.0 ou superior do PVA vai estar pronta para validar esse arquivo.

Add( LFill('0110') +

LFill( strCOD_INC_TRIB ) +

LFill( strIND_APRO_CRED ) +

LFill( strCOD_TIPO_CONT ) +

lFill( strIND_REG_CUM ) );

Se você ler o tópico vai entender o motivo. Espero que ajude.

Qualquer coisa poste aí.

EDIT: Percebi ainda assim que nessa situação específica, pode haver um erro no campo. Mas não é por que o campo está sendo informado. Aconteceria pois está sendo informado com valor diferente de vazio. Vou fazer uma correção e postar quando estiver pronto.

[EMBarbosa]

Enviei uma correção para passar o campo em branco na revisão 3385 do SVN.

[Gr@c@]

Já estou usando o PVA 2.0 para validar arquivos de Lucro Presumido. No caso, no registro 0110, o campo IND_APRO_CRED não existe (nem como vazio)

Registro 0110 SPED Contribuições Lucro Presumido está gerando um campo a mais ref ao IND_APRO_CRED que só deve existir no Lucro real

|0110|2||1|1| ==> não valida no PVA = O numero de campos informado informado no registro difere do numero de campos especificado no layout

|0110|2|1|1| ==> alterei via bloco de notas e validou no PVA 2.0

[EMBarbosa]

Olá,

Você poderia testar colocando os dados a partir de 01 de Julho de 2012?

[Filipe Sortica]

Olá a todos!

Este negócio de versões está bem complicado mesmo, mas vamos por partes...

Estou com a última versão do manual (Versão 1.0.7), o qual indica 4 versões de leiaute do arquivo (1.00, 1.01, 2.00 e 2.01), e com a última versão do PVA (2.0.0). (Pra que tanta coisa né....)

Bom, gostaria de informar a todos que nem mesmo a versão 2.0.0 do PVA está pronta para validar o registro 0110 com 5 campos.

O manual é bem claro ao dizer:

Em ambas as versões do PVA (1.0.7 e 2.0.0), o arquivo deve ser gerado com o registro “0110 – Regimes de Apuração da

Contribuição Social e de Apropriação de Crédito” contendo apenas 04 (quatro) campos. Esse registro só será escriturado

contendo 05 (cinco) campos em seu conteúdo, na versão 2.0.1 do PVA, a ser disponibilizada em junho de 2012.

(Fonte: Guia Prático da EFD-Contribuições, versão 1.0.7, Maio 2012, pág. 32)

Logo acima disso, há a tabela 3.1.1 de Versões de Leiaute.

Ela prevê que para a versão 2.0.1 do PVA, que validará o registro 0110 com 5 campos, haverá uma nova versão do leiaute do arquivo: 2.01.

Gostaria de sugerir que esta versão seja adicionada na unit "ACBrEPCBlocos.pas", como indicado a seguir:

  /// Versão do Leiaute do arquivo - TRegistro0000

  TACBrVersaoLeiaute = (

                         vlVersao100,  // Código 001 - Versão 100 ADE Cofis nº 31/2010 de 01/01/2011

                         vlVersao101,  // Código 002 - Versão 101 ADE Cofis nº 34/2010 de 01/01/2011

                         vlVersao201   // Código 003 - Versão 201 ADE Cofis nº 20/2012 de 14/03/2012

                        );

Dai a geração do registro 0110 poderia ficar assim:

       if FRegistro0000.COD_VER >= vlVersao101 then

       begin


         //Verificar a necessidade desse if abaixo quando sair a versão 2.0 do PVA PisCofins

         if (COD_INC_TRIB = codEscrOpIncCumulativo) then

         begin

           strIND_APRO_CRED := '';// Conforme Guia prático 1.0.5 Deve ser vazio caso COD_INC_TRIB = 2

  	       [b]//Nota: Só a versão 2.0.1 do PVA vai estar pronta para validar esse arquivo.[/b]

           Add( LFill('0110') +

                LFill( strCOD_INC_TRIB ) +

                LFill( strIND_APRO_CRED ) +

                LFill( strCOD_TIPO_CONT )  +

                [b]IfThen(FRegistro0000.COD_VER = vlVersao201, LFill( strIND_REG_CUM ), '' )[/b]

           )

         end

         else

           Add( LFill('0110') +

                LFill( strCOD_INC_TRIB ) +

                LFill( strIND_APRO_CRED ) +

                LFill( strCOD_TIPO_CONT ) ) ;

       end

       else //Modelos de registro anteriores à versao 1.0.3 do guia prático

         Add( LFill('0110') +

              LFill( strCOD_INC_TRIB ) +

              LFill( strIND_APRO_CRED ) +

              LFill( strCOD_TIPO_CONT ) ) ;

Se for possível realizar esta alteração nos fontes, acho que resolveria o problema de incompatibilidade de versões...

[EMBarbosa]

Ficou bem confuso mesmo.

Tópico Relacionado

Você poderia fazer essa alteração proposta nos arquivos e anexar aqui no fórum os arquivos corrigidos?

Ficaria mais fácil de analisar.

[Filipe Sortica]

Ok.

Estão em anexo.

ACBrEPCBloco_0_Class.pas

ACBrEPCBlocos.pas

[Filipe Sortica]

Olá EMBarbosa!

Será que as alterações entram nos fontes?

[EMBarbosa]

Pelo seu post, acredito que sim.

Mas passei por uma certificação TEF a pouco e estamos nos preparando para homologação PAF-ECF. Por isso e outras coisas não tive o tempo necessário para averiguar suas alterações ainda. Devo analisar ainda essa semana e deixo uma resposta aqui mesmo.

E mesmo que não eu, outro desenvolvedor ACBr pode fazê-lo.

Obrigado pelas sugestões.