Erro Nos Registros C481 E C485

[Turbo Drive]

Bom dia

 

Ao gerar o arquivo Sped Contribuições e validar no PVA 2.0.6, me deparei com mais de 5000 erros no arquivo.

O que aconteceu é que a nova versão do PVAa, não aceita que se preencha os registros Quantidade – Base de cálculo PIS/PASEP e a Alíquota do PIS/PASEP (em reais) de forma zerada.

Para corrigir esse equívoco tive que modificar na unit ACBrEPCBloco_C_Class as seguintes funções:

 

Add( LFill('C481')             +

LFill(CstPisToStr(CST_PIS)) +

LFill(VL_ITEM,0,2)        +

DFill(VL_BC_PIS,      2, NullVL_BC_PIS) +

DFill(ALIQ_PIS,       4, False) +

DFill(QUANT_BC_PIS,   3, true) +  // modificado

DFill(ALIQ_PIS_QUANT, 4, true) + // modificado

LFill(VL_PIS,0,       2, NullVL_PIS)         +

LFill(COD_ITEM)           +

LFill(COD_CTA) ) ;

 

Add( LFill('C485')                     +

LFill(CstCofinsToStr(CST_COFINS)) +

LFill(VL_ITEM,0,2)                +

DFill(VL_BC_COFINS,      2, NullVL_BC_COFINS) +

DFill(ALIQ_COFINS,       4, False) + 

DFill(QUANT_BC_COFINS,   3, true) + // modificado

DFill(ALIQ_COFINS_QUANT, 4, true) + // modificado

LFill(VL_COFINS,0,       2, NullVL_COFINS) +

LFill(COD_ITEM)                   +

LFill(COD_CTA) ) ;

 

 

Como está escrito no fonte, ao se usar a função DFill, informando o valor zero e deixando true, o arquivo Sped irá sem nenhum valor, apenas com os delimitadores.

 

Feito isso, validei o arquivo sem problemas na nova versão do PVA.

 

Espero ter ajudado.

 

 

[Juliomar Marchetti]

Bom dia

acho que seu svn está desatualizado, mantenha diariamente ou semanalmente 

 

veja o trecho

          Add( LFill('C481')             +
               LFill(CstPisToStr(CST_PIS)) +
               LFill(VL_ITEM,0,2)        +
               DFill(VL_BC_PIS,      2, NullVL_BC_PIS) +
               DFill(ALIQ_PIS,       4, NullALIQ_PIS) +
               DFill(QUANT_BC_PIS,   3, NullQUANT_BC_PIS) +
               DFill(ALIQ_PIS_QUANT, 4, NullALIQ_PIS_QUANT) +
               LFill(VL_PIS,0,       2, NullVL_PIS)         +
               LFill(COD_ITEM)           +
               LFill(COD_CTA) ) ;

[Isaque Pinheiro]

Veja o link 

[duiliolobianco]

Ontem atualizei e deu este mesmo erro. Não adiantou utilizar a variável ao invés de True ou False porque antes do bloco é setado False para todas as variáveis.

 

...

begin

   NullVL_BC_COFINS := False;

   NullALIQ_COFINS  := False;

   NullQUANT_BC_COFINS := False;

   NullALIQ_COFINS_QUANT := False;

   NullVL_COFINS := False;

....

[francisco.itb]

tem que setar nos fontes essa variavel para true

 NullQUANT_BC_COFINS := True;

   NullALIQ_COFINS_QUANT := True;

 

Eu fiz isso aqui, e funcionou, basta agora o pessoal do acbr corrigir.

[carlosmarian]

Olá,

  só uma dúvida, os valores não deveriam ficar vazios? ao invés de receber zero?

  tbm estou tendo um série de erros gerados em virtude disso.

  Se existe a necessidade de que em alguns casos o valor seja gerado com ZERO e não VAZIO, que fique por conta do implementador, no momento de alimentar os campos(usando o novo método LFILL com variant).

  Só para constar, esta pequena alteração me causou e esta causando muita dor de cabeça.

 

At+

[Juliomar Marchetti]

Olá,

  só uma dúvida, os valores não deveriam ficar vazios? ao invés de receber zero?

  tbm estou tendo um série de erros gerados em virtude disso.

  Se existe a necessidade de que em alguns casos o valor seja gerado com ZERO e não VAZIO, que fique por conta do implementador, no momento de alimentar os campos(usando o novo método LFILL com variant).

  Só para constar, esta pequena alteração me causou e esta causando muita dor de cabeça.

 

At+

Bom dia

verifique a alteração que o Isaque disponibilizou onde o tipo dos campos é tratado como variant e ao estar null ele vai vazio!

[carlosmarian]

Olá Juliomar,

  Obrigado pelo retorno, não quero gerar polêmica ou criticar quem trabalhando esta disponibilizando as atualizações/implementações no ACBr mas este é um exemplo que pode ser usado como cuidado para novas implementações. Se existe a necessidade de atender a um exceção, o padrão deve ser mantido e quem necessitar atender a exceção então deveria ajustar sua implementação, neste caso por exemplo usando o evento "onbeforewriteregistroc481" e "onbeforewriteregistroc485".

  Novamente, não que criticar o senhor ou o Sr. Isaque só verificar a possibilidade de usar este critério durante as implementações.

  

 

At++++

[Isaque Pinheiro]

Se existe a necessidade de que em alguns casos o valor seja gerado com ZERO e não VAZIO, que fique por conta do implementador, no momento de alimentar os campos(usando o novo método LFILL com variant).
  Só para constar, esta pequena alteração me causou e esta causando muita dor de cabeça.

Carlos você não foi bem claro aqui, o que quer dizer? Que o componente fique da forma que tava e que caca usuário se vira em usar o novo método ?

[Lindomar]

Pessoal

 

O que o Hallysson postou no link abaixo funciona 100%. Estava com o mesmo problema apos atualizar o acbr:

 

 

 

 

Add( LFill('C481') +
LFill(CstPisToStr(CST_PIS)) +
LFill(VL_ITEM,0,2) +
DFill(VL_BC_PIS, 2, ( CST_PIS in [ stpisQtdeAliquotaUnidade,
stpisIsentaContribuicao,
stpisSemIncidenciaContribuicao,
stpisSuspensaoContribuicao ])) +
DFill(ALIQ_PIS, 4, ( CST_PIS in [ stpisQtdeAliquotaUnidade,
stpisIsentaContribuicao,
stpisSemIncidenciaContribuicao,
stpisSuspensaoContribuicao ])) +
DFill(QUANT_BC_PIS, 3, ( CST_PIS <> stpisQtdeAliquotaUnidade )) +
DFill(ALIQ_PIS_QUANT, 4, ( CST_PIS <> stpisQtdeAliquotaUnidade )) +
LFill(VL_PIS,0,2) +
LFill(COD_ITEM) +
LFill(COD_CTA) ) ;

[Isaque Pinheiro]

Novamente, não que criticar o senhor ou o Sr. Isaque só verificar a possibilidade de usar este critério durante as implementações.

Carlos, sempre tentamos o máximo, fazer implementações da qual sofra o menor impacto possível, e se possível impacto ZERO. Já sofremos com esses problemas a um bom tempo, fizemos várias tentativas e nenhuma foi a contento de todos por não resolver 100% a situação.

Essa ultima mudança foi analisar juntamente com outros administradores, e chegamos a conclusão de que para atender a todas situações que apareceram e podem aparecer, a melhor opção seria a mudança do tipo para Variant, sendo que essa mudança não afetaria o código já existente dos usuário que usam.

Além disso fiz um comunicado no fórum disponibilizando em anexo os fontes antes de subir, sabe quantos baixaram e testaram para sabermos ser teríamos alguma divergência? Nenhum.

Eu também uso os componentes em meus clientes, antes de subir testei em produção em um de meus maiores clientes, e não vi divergência.

 

Agora você atualizou os fontes pelo jeito, deve algum problema? Nos reporte vamos analisar, e se virmos que é de tal importância, além da mudança que foi feita para resolver N problemas relatados, e que  nosso usuário ficavam de mãos amarradas, pois o componente tava engessado, não os deixando alimentar valores, zero ou vazio em cada situação que aparecia, analisaremos a volta da versão anterior.

 

Estamos aqui para ouvir a todos.

 

Só para constar as implementações foram feitas somente no SPED Fiscal, Contribuição não foi mexido em nada, por acaso ta dando conflito com a função LFIll() ? Se tiver reporte.

[Isaque Pinheiro]

Carlos, voltei a versão anterior, vamos tentar fazer a mudança gradativamente, tentando atender sua solicitação de cautela nas implementações.

 

1o - As funções que recebe o tipo Variant vão ter uma letra V antes do no ficando assim VDFill() e VLFill()

2o - Todos os campos voltaram a ter os tipos anteriores, Currency e Double, só vamos mudando os tipo para Variant os campos que precisarem de ter valor NULL e junto add a letra V antes do nome da função para que não haja risco ambiguidade.

[carlosmarian]

Olá Sr. Isaque.

  Só reiterando minha opinião, em nenhum momento que ofender ou criticar as pessoas que implementam código e disponibilizam junto ao ACBr, pelo contrário agradeço ao empenho de todos.

  Sobre o seu comentário(acima) referente ao impacto da alteração, sim meu problema foi constatado nos registros C481 e C485 do Contribuições.

  No código implementávamos o C481 desta forma :

with Pai.RegistroC481.New do
begin
  CST_PIS        := StrToCstPis(QAux.FieldByName('codcst').AsString) ; 
  VL_ITEM        := QAux.FieldByName('valtot').AsFloat;
  VL_BC_PIS      := QAux.FieldByName('bascal').AsFloat;
  ALIQ_PIS       := QAux.FieldByName('aliimp').AsFloat;
  QUANT_BC_PIS   := 0.00;
  ALIQ_PIS_QUANT := 0.00;
  VL_PIS         := QAux.FieldByName('valimp').AsFloat; 
  COD_ITEM       := QAux.FieldByName('codpro').AsString; 
  COD_CTA        := CampoSpedS(StrRegistro, 'COD_CTA'); 
end; 

  Desta forma com a atualização do ACBr o valor gerado pelo <b>TBloco_C.WriteRegistroC481</b>(ACBrEPCBloco_C_Class), passou a gerar um valor inconsistente, com "0,00" onde deveria ser vazio;

 

  Minha revisão atual do ACBr em uso é 6642.

 

Só um comentário:

  Aqui na empresa não conseguimos manter nossa versão do ACBr sempre atualizada, visto que em virtude e erros anterior do ACBr causaram grandes impactos, e geraram uma grande rejeição por parte dos diretores e demais membros da equipe em manter sempre o ACBr atualizado com a última revisão.

  Para nós existe um grande custo(tempo, profissionais, dinheirooo) envolvido a cada atualização do ACBr.

 

  Talvez isso minimize caso fosse implementado um versionamento das liberações, talvez aé um versionamento para cada componente do ACBr, onde cada versão seria elaborada(montada) identificando quais novas implementações e ajustes iriam compor a versão. Similar como ocorre em outros projetos.

   Mas isso tudo é papo para um outro momento.

 

 

 

 

 

 

[Isaque Pinheiro]

Sei que foi uma opinião e acatamos quando enxergamos fundamentos para a mesma, por isso gostaria que fizesse um teste e me relatasse se voltou ao normal, pois voltei a versão anterior.

[carlosmarian]

Olá,

  Ok vou verificar.
 Só um detalhe...

  analisando as alterações que foram desfeitas, isso esta correto? exemplo "WriteRegistroC405"

  Antes de vc voltar a versão:    

with RegC400.RegistroC405.Items[intFor] do
begin
  Add( LFill('C405') +
       LFill( DT_DOC ) +
       LFill( CRO,3 ) +
       LFill( CRZ,6 ) +
       LFill( NUM_COO_FIN,6  ) +
       LFill( GT_FIN,0,2  ) +
       LFill( VL_BRT,0,2  ) ) ;
end; 

  Depois de vc voltar a versão:    

with RegC400.RegistroC405.Items[intFor] do
begin
   Add( LFill('C405') +
        LFill( DT_DOC ) +
        LFill( CRO,3 ) +
        LFill( CRZ,6 ) +
               IfThen( DT_INI >= EncodeDate(2013,10,01), LFill( NUM_COO_FIN, 9) , LFill( NUM_COO_FIN, 6) ) +
        LFill( GT_FIN,0,2  ) +
        LFill( VL_BRT,0,2  ) ) ;
end;

Isto confere?

 

OBS: revisão base 6642;

 

at+

Editado 28 Maio, 2014 por carlosmarian

[EMBarbosa]

Só um comentário:

  Aqui na empresa não conseguimos manter nossa versão do ACBr sempre atualizada, visto que em virtude e erros anterior do ACBr causaram grandes impactos, e geraram uma grande rejeição por parte dos diretores e demais membros da equipe em manter sempre o ACBr atualizado com a última revisão.

  Para nós existe um grande custo(tempo, profissionais, dinheirooo) envolvido a cada atualização do ACBr.

 

  Talvez isso minimize caso fosse implementado um versionamento das liberações, talvez aé um versionamento para cada componente do ACBr, onde cada versão seria elaborada(montada) identificando quais novas implementações e ajustes iriam compor a versão. Similar como ocorre em outros projetos.

   Mas isso tudo é papo para um outro momento.

  Sinceramente, se o custo(tempo, profissionais, dinheirooo) sic não é maior que a economia em utilizar os componentes, então é melhor não atualizar, ou talvez até mesmo não utilizar. É simples assim. Questão de custo benefício.

  Se os diretores e/ou demais membros da equipe quiserem se colocar a disposição para testar, corrigir, desenvolver, orientar, etc... ficaremos muito gratos com a ajuda. O projeto é código fonte aberto mantido pela comunidade. Seria bom ter mais ajuda.

  Inclusive, poderiam começar fazendo o tal versionamento das liberações para o público em geral, pois o trunk é realmente para desenvolvedores.

 

  Veja, isso não é uma crítica nem tenho intenção de ofender. Apenas a realidade do projeto. Precisamos de ajuda de quem usa o componente.

[carlosmarian]

OK EMBarbosa,

  Hj no ACBr temos alguns usuários com permissão de commit de alterações.

  O que poderíamos estar iniciando agora seria levantar quais implementações/ajustes estão sendo feitos por estes usuários.

  Identificar com cada responsável quais das datas legais(limite legal para atender solicitações do governo, por exemplo) que devem ser atendidas, desta forma seria(na minha opinião) uma boa forma de agendar as datas previstas de liberação destas versões;

     Dentro de cada versão principal criar pequenos releases de ajustes que possam ser gerados depois de uma liberação de versão.

 

  Para não causar um grande impacto, poderíamos escolher um projeto menor, que hj apresenta um nro menor de melhorias, desta forma poderíamos esta melhorando nosso processo e depois replicar este conhecimento para os demais projetos.

 

 

  Acredito que muitos de vc´s já fazem uso de versionamento de liberação, basicamento seria só colocar em prática no ACBr os mesmo conhecimentos e experiências obtidas em suas vivências profissionais.

 

 

at+

[carlosmarian]

Sr Isaque, 

   Só implantar suas alterações não trouxe uma melhoria muto grande, ainda estava com problemas no C481 e C485 do Contribuições;

   Para contornar, além dos seus ajustes fiz a seguinte alteração:

   De:     

procedure TBloco_C.WriteRegistroC481(RegC405: TRegistroC405);
var
  intFor: integer;
  NullVL_BC_PIS: Boolean;
  NullALIQ_PIS: Boolean;
  NullQUANT_BC_PIS: Boolean;
  NullALIQ_PIS_QUANT: Boolean;
  NullVL_PIS: Boolean;
begin
   NullVL_BC_PIS := false;
   NullALIQ_PIS  := false;
   NullQUANT_BC_PIS := false;
   NullALIQ_PIS_QUANT := false;
   NullVL_PIS := false; 

   Para:

procedure TBloco_C.WriteRegistroC481(RegC405: TRegistroC405);
var
  intFor: integer;
  NullVL_BC_PIS: Boolean;
  NullALIQ_PIS: Boolean;
  NullQUANT_BC_PIS: Boolean;
  NullALIQ_PIS_QUANT: Boolean;
  NullVL_PIS: Boolean;
begin
   NullVL_BC_PIS := true;
   NullALIQ_PIS  := true;
   NullQUANT_BC_PIS := true;
   NullALIQ_PIS_QUANT := true;
   NullVL_PIS := true;

Mudei o valor padrão dos flags de FALSE para TRUE.

Mesmo critério foi aplicado ao "WriteRegistroC485".

 

 

 

 

Obrigado pela  atenção.

[EMBarbosa]

OK EMBarbosa,

  Hj no ACBr temos alguns usuários com permissão de commit de alterações.

  O que poderíamos estar iniciando agora seria levantar quais implementações/ajustes estão sendo feitos por estes usuários.

  Identificar com cada responsável quais das datas legais(limite legal para atender solicitações do governo, por exemplo) que devem ser atendidas, desta forma seria(na minha opinião) uma boa forma de agendar as datas previstas de liberação destas versões;

     Dentro de cada versão principal criar pequenos releases de ajustes que possam ser gerados depois de uma liberação de versão.

Fique a vontade para fazer os levantamentos.

[carlosmarian]

Como eu tenho acesso a lista com os responsáveis por cada projeto?

Na sua opinião, qual seria o projeto mais adequado para tentar iniciar este tipo de gerenciamento? LEvando em conta tamanho, nro de commits e tbm o fator humano, onde possua um colaborar disposto e de fácil acesso para tentar implantar isso

Editado 28 Maio, 2014 por carlosmarian

[EMBarbosa]

Como eu tenho acesso a lista com os responsáveis por cada projeto?

Até onde eu sei, não existe uma lista deste tipo.

 

Na sua opinião, qual seria o projeto mais adequado para tentar iniciar este tipo de gerenciamento? LEvando em conta tamanho, nro de commits e tbm o fator humano, onde possua um colaborar disposto e de fácil acesso para tentar implantar isso

Não faço a menor ideia. o.o''

[Marcio Lopes ACBr]

Bom Dia,

 

Sempre que atualizo o Acbr tenho que setar a variáveis abaixo para "True" senão continua com problema no Bloco C491 e C495, conforme o erro no print anexado.

 

 

 

unit ACBrEPCBloco_C.pas

  NullQUANT_BC_PIS := True;
  NullALIQ_PIS_QUANT := True;

Att,

[Juliomar Marchetti]

Assim que der subo a alteração!

[EMBarbosa]

Mas é para isso que o Isaque criou os eventos nos registros C481 e C485. Você deve passar true para as variáveis:

 

NullVL_BC_PIS := True;

NullALIQ_PIS := True;

NullQUANT_BC_PIS := True;

NullALIQ_PIS_QUANT := True;

NullVL_PIS := True;

 

Atribua True para que fique em branco, nos campos que precisar.

 

[Marcio Lopes ACBr]

Blz EMBarbosa, agora que vi, esses eventos. Obrigado