Algumas correções em ECFs para PAF-ER 02.03

[Rodrigo Fruhwirth]

Envio alguns ajustes referentes ao PAF-ECF-ER 02.03, ajustes como por exemplo a implementação da expressão "Conta de Cliente" no lugar de "Mesa", das formatações das mensagens da IBPT e mensagens específicas dos estados.

Implementação da impressão do QrCode pela EPSON MFB e correções na utilização da NOTA LEGAL em negrito.

Ajuste do erroSemPapel na ECF Bematech 4000 TH-FI para cumprir o requisito do menu fiscal.

Implementação da ECF ZPM/1-FIT LOGGER na FISCNET e ajuste no método CarregaAliquotas do mesmo modelo para deixar compatível com as demais ECFs.

 

ACBrConsts.pas

ACBrECF.pas

ACBrECFBematech.pas

ACBrECFClass.pas

ACBrECFEpson.pas

ACBrECFEscECF.pas

ACBrECFFiscNET.pas

[Juliomar Marchetti]

Estranho segunda e terça estive homologando e não precisei de alterações no ACBr!

Ficou faltando posto de combustíveis, passagens e pedagio no restante atendi dos os requisitos!

[Rodrigo Fruhwirth]

Não é a questão de você homologar, é a questão do órgão homologador ser chato quanto alguns itens principalmente com as questões das mensagens dos estados que a mensagem da Paraíba estava em 2 linhas e deve ser em 3 linhas e de acordo com o Ato Cotepe a mensagem "CONCESSÃO DE CRÉDITOS - LEI Nº 4.159/2008." estava "CONCESSÃO DE CRÉDITOS - LEI Nº 4.159/08".

Como os homologadores aqui são detalhistas ao extremo tivemos que ajustar.

E quanto as mensagens de conta de cliente é somente para quem desenvolve PAF-ECF com esse controle que a expressão "Conta de Cliente" pode ser utilizado para substituir a expressão "Mesa".

Também tivemos que fazer a emissão da NFC-e em relatório gerencial de acordo com o Requisito XXVIII do AC e a impressão da QrCode. Como nós só temos a Epson que faz isso então implementei para a mesma.

Já a ECF FiscNET ZPM/1-FIT-LOGGER não estava na lista com a quantidade das colunas e quando se tentava montar as mensagens de fechamento de cupom com valores acima de 10.000,00 estava excedendo o número de linhas. Isso claro por causa das mensagens da IBPT.

Editado 2 Setembro, 2016 por Rodrigo Fruhwirth

[Juliomar Marchetti]

Bom como falei homologuei sem necessidade e sim o local que homologuei é minucioso nos testes!

deixarei para outro que queira verificar, mas na nova E. R. a parte de NFC-e não é mais pedido como antes!

então esse código não deverá ser subido ao svn!

quem sabe alguma parte que outra

[Rodrigo Fruhwirth]

Correto.

Quanto ao caso da NFC-e realmente não é mais necessário, mas se quiserem apreciar já tem o código para o QrCODE da Epson MFB,

Tinha um probleminha no vetor das descrições dos códigos de barras que nos códigos estava com 14 posições e nas descrições com 13..

  cTAGS_BARRAS: array[0..14] of String = (
  cTAGS_BARRAS_HELP: array[0..13] of String = (

Pelo o que eu entendi é que "'Cod.Barras UPCE - 11 numeros e 1 dig.verificador'" foi removido mas o enumerador acima cTagBarraUPCE não, algum motivo para isso?

Também teve algo que achei muito estranho que o componente esta fazendo, que é o caso da desativação da mensagem de erro de falta de papel dentro do componente para as leituras de estado e do GT e não volta como estava na aplicação, tem alguma lógica para que o componente simplesmente desative isso?

Outra coisa que eu ajustei também é que o ACBrECFBematech não estava testando o bit 7 de sem papel como as demais ECFs fazem nas execuções dos comandos, algumas até retornam que estão fora de linha nesse caso, isso é de propósito ou tem alguma explicação para que na bematech 2100/4000 não houvesse essa tratativa?

Editado 8 Setembro, 2016 por Rodrigo Fruhwirth

[Juliomar Marchetti]

Farei as devidas analises conforme comentou acima e dai subo ao svn!

Obrigado

[Daniel Simoes]

Notei que são muitas mudanças sugeridas... mas não há uma atualização no ACBrSerial-Change-Log.txt... e portanto fica difícil compreender a necessidade das modificações, se elas são melhorias, correção de bugs, etc...

 

[Rodrigo Fruhwirth]

Boa tarde Daniel, a quanto tempo...

Me desculpe Daniel, segue. 

ACBrComum-change-log.txt

ACBrSerial-change-log.txt

Editado 8 Setembro, 2016 por Rodrigo Fruhwirth

[Daniel Simoes]

Apliquei parcialmente as modificações sugeridas, e promovi alguns ajustes e refatoração no código proposto...

Citar

-- ACBrECF --
[-] Método FechaCupom após obter GetRodapePaf não estava sendo feito a mesma tratativa de troca de
    caracteres que é feito nas observações.
    (por: Rodrigo Frühwirth)

  Não aplicado, pois ACBrECF suporta acentos, desde qua a Página de código esteja corretamente configurada
  Troca de #13+#10 por #10 já ocorre, em "AjustaLinhas"...
 

Citar

-- ACBrECF --
[*] Método GetRodapeImposto ajustado as mensagens da IBPT para que quando efetuado vendas de valores
    grandes (acima de 15.000,00) e o valor dos impostos ultrapassarem a largura da ECF no modo compacto
    que o mesmo ajuste a mensagem para não cortar no meio dos valores e nem das expressões.
    (por: Rodrigo Frühwirth)

    Não aplicado, pois ocorre o mesmo efeito da implementação atual
    

Citar

-- ACBrECF --
[-] Método GetRodapeUF ajuste das mensagem da Paraíba Legal que de acordo com o AC deve ser em 3 linhas
    e Nota Legal com programa de concessão de créditos o número da lei esta em desacordo com o AC.
    (por: Rodrigo Frühwirth)  

       Não aplicado. Precisamos de embasamento legal para a modificação e não apenas a opinião do Homologador
 
 

Citar

-- ACBrECF --
[-] Método GetEstadoClass IgnorarErroSemPapel deve ser uma decisão da aplicação e não do componente,
    ainda mais porque não retorna o mesmo não retorna o estado original da flag.
    (por: Rodrigo Frühwirth)

-- ACBrECF --
[-] Método GetGrandeTotalClass IgnorarErroSemPapel deve ser uma decisão da aplicação e não do componente,
    ainda mais porque não retorna o mesmo não retorna o estado original da flag.
    (por: Rodrigo Frühwirth)    

 Não aplicado. Recentemente foi aplicada modificação por Juliomar, com Try/Finally    

Citar

-- ACBrECFEscEcf --

TACBrECFEscECF.LinhaRelatorioGerencial

  if IsEpson and (LeftStr(Linha, 2) = #27#128) then //código de barra
    Linha := #27+Trim(Linha);
  if IsEpson and (LeftStr(Linha, 2) = #27#64) then //código de barra
    Linha := #27+Trim(Linha);

Não compreendi a necessidade. Parece que irá interferir em outros comandos.
Favor detalhar qual é o problema e como reproduzir o mesmo...

Citar

-- ACBrECFFiscNET --
[+] Implementado método PafMF_GerarCAT52. (por: Rodrigo Frühwirth)

Não aplicado... O código sugerido, parece ter a mesma implementação da classe Pai

Citar

-- ACBrECFFiscNET --
[-] Método LinhaRelatorioGerencial ajuste de linhas para a marca Dataregis.
    (por: Rodrigo Frühwirth)

Não aplicado. Não compreendi a necessidade. Remover as quebras de linha, não parece correto

Citar

-- ACBrECFFiscNET --
[-] Método CarregaAliquotas removido tratativa de erro interno no componente pois em qualquer situação
    de erro o componente estava limpando a fpAliquotas impedindo a aplicação de ler as mesmas.
    (por: Rodrigo Frühwirth)

A implementação sugerida pode ocultar outros Exceptions, como por exemplo falha na comunicação. A implementação atual já irá processar pulos na programação de alíquotas, pois ignora os erros quando "ErroCMDAliquotaNaoCarregada"

Citar

-- ACBrECFBematech --
[*] Método EnviaComando_ECF ajustado para testar o bit 7 do ST1 e deixar a aplicação decidir se quer
    dar erro de sem papel nas leituras dos totalizadores e não somente quando houver alguma impressão.
    (por: Rodrigo Frühwirth)

Não aplicado. O teste já existe no final do mesmo método:

        if (fsST1 = 128) or (fsST3 = 11) then   // 127 = Bit 7 ligado
           DoOnErrorSemPapel
        else
           raise EACBrECFSemResposta.create(ACBrStr(ErroMsg)) ;

   

[Daniel Simoes]

Apliquei a seguinte melhoria, seguindo a sugestão para a Bematech:
 

-- ACBrECFBematech --
[-] Ajuste para correta verificação do Erro "Sem Papel"  (por: DSA)

        if TestBit(fsST1, 7) or (fsST3 = 11) then
           DoOnErrorSemPapel             

 

[Rodrigo Fruhwirth]

Desculpa Daniel não ter tido tempo para responder todas as citações acima e explicar cada caso, mas farei isso hoje a noite ainda.

[Daniel Simoes]

Ok.. sem problemas rodrigo, e obrigado pelas correções...

[Rodrigo Fruhwirth]

Imagina Daniel, sempre que eu puder contribuir...

Então vamos iniciar pela Mensagem da Paraíba. Vejamos o que diz o AC.

https://www.confaz.fazenda.gov.br/legislacao/atos/2015/ac023_15

Requisito IX 2c

Exemplo:

Dados do Cupom Fiscal: IE: 161444539 Data: 19/06/2013 COO: 127564 Valor Total: R$ 125,45

Formação do código:

PARAÍBA LEGAL - RECEITA CIDADÃ

TORPEDO PREMIADO:

161444539 19062013 127564 12545

Observe que a mensagem é em 3 linhas e porque isso? Porque se for um valor grande maior do que 1000,00 ou o número do COO tiver mais do que 6 dígitos já iria quebrar para a terceira linha deixando os dados com menor compreensão.

--------------------------------------

Quanto as mensagens da IBPT deixei de acordo com o manual da AFRAC versão 0.13 de 01/06/16. Manual em anexo.

-------------------------------------

-- ACBrECFFiscNET --
[-] Método CarregaAliquotas removido tratativa de erro interno no componente pois em qualquer situação
    de erro o componente estava limpando a fpAliquotas impedindo a aplicação de ler as mesmas.

Porque isso? Porque quando houver algum erro do tipo  ErroCMDAliquotaNaoCarregada a tratativa que tem no componente impede a aplicação de ler as alíquotas da ECF e já que o fpAliquotas esta sendo setado como nil, nesse caso eu deixaria exatamente como é nas demais ECFs que não há nenhum tipo de tratamento, exemplo a bematech, ou talvez em conjunto com os colegas pensarmos em uma forma melhor de fazer para não simplesmente zerar o fpAliquotas.

-------------------------------------

E quanto ao caso de IgnorarErroSemPapel eu sinceramente não entendi o porque disso somente nos comandos de status e GT sendo que a maioria das ECF retornam erro de fora de linha quando estão sem papel e se fosse o caso, deveria ter para todas as leituras de valores da ECF e não somente para STATUS e GT concorda? Agora da forma como esta, simplesmente a aplicação não tem o controle para dar ou não esse erro nas leituras. Talvez eu não tenha entendido corretamente o motivo.

---------------

Para as demais alterações, eu não estava com o componente atualizado e irei proceder novamente com novos testes para detalhar melhor as necessidades mostradas acima se é que ainda são necessárias.

MANUAL DE OLHO NO IMPOSTO 0 13 - DESENVOLVEDORES - OUTROS ESTADOS-1.pdf

Editado 13 Setembro, 2016 por Rodrigo Fruhwirth

[Daniel Simoes]

• Apliquei a correção para o "Paraíba Legal"...
• Em relação a modificação proposta em "TACBrECFFiscNET.CarregaAliquotas"... note nos fontes atuais, que caso o erro seja exatamente do tipo, "ErroCMDAliquotaNaoCarregada" não será disparado um Exception

     except
        on E : Exception do
        begin
           Erro := (pos('ErroCMDAliquotaNaoCarregada',E.Message) = 0)
        end ;
     end;  

• Em relação as modificações das linhas de apresentação dos Impostos... vou pedir ajuda "aos universitários" (time do ACBr)...

 

16 horas atrás, Rodrigo Fruhwirth disse:

E quanto ao caso de IgnorarErroSemPapel eu sinceramente não entendi o porque disso somente nos comandos de status e GT sendo que a maioria das ECF retornam erro de fora de linha quando estão sem papel e se fosse o caso, deveria ter para todas as leituras de valores da ECF e não somente para STATUS e GT concorda? Agora da forma como esta, simplesmente a aplicação não tem o controle para dar ou não esse erro nas leituras. Talvez eu não tenha entendido corretamente o motivo.

Eu não implementei essa modificação... mas acho que ela foi motivada, devido a integração com o ACBrAAC (Arquivo Auxiliar Criptografado)

[Rodrigo Fruhwirth]

Boa tarde Daniel.

Então vejamos:  TACBrECFFiscNET.CarregaAliquota, o que ocorre. Quando há índices em branco na ECF a aplicação jamais saberá as alíquotas da ECF. Ex.:

T01 = 1200

T02 = null

T03 = 0700

T04 = 2500

Nessa situação quando o componente ler a alíquota 2 da ECF a mesma irá retornar o erro. 

ErroCMDAliquotaNaoCarregada

Após isso o fpAliquotas simplesmente será limpo e setado como null. Se é por algum motivo específico que tem esse tratamento o mesmo esta errado pelo menos na X5 e na ZPM/1-FIT LOGGER ocorre o mesmo problema.

---------

Voltando ao caso do IgnorarErroSemPapel não vejo problema algum em outros locais do componente setarem essa flag para true e depois voltar para o que a aplicação tinha inicialmente setado, o que eu não acho certo é simplesmente a classe base tomar essa decisão e não permitir que a aplicação mude esse tratamento. Quanto ao AAC entendo que é necessário ler do GT sempre, mas a maioria das ECFs retornam erro de fora de linha quando estão sem papel o que também inutiliza essa flag.

[Daniel Simoes]

Rodrigo... veja nos fontes... se o "E.message" contiver, "ErroCMDAliquotaNaoCarregada", então o Exception não será disparado...

[Rodrigo Fruhwirth]

Desculpa Daniel, mas acho que você não entendeu o caso, vou te mandar o log da ECF.

15/09/2016 10:52:06.265 -> {103;LeAliquota;CodAliquotaProgramavel=1;40}
15/09/2016 10:52:06.296 <- {103;0;AliquotaICMS=Y CodAliquotaProgramavel=1 DescricaoAliquota="7,00%" PercentualAliquota=7,00;96}
15/09/2016 10:52:09.965 -> {104;LeAliquota;CodAliquotaProgramavel=2;40}
15/09/2016 10:52:09.996 <- {104;0;AliquotaICMS=Y CodAliquotaProgramavel=2 DescricaoAliquota="" PercentualAliquota=17,00;92}
15/09/2016 10:52:12.890 -> {105;LeAliquota;CodAliquotaProgramavel=3;40}
15/09/2016 10:52:12.921 <- {105;0;AliquotaICMS=Y CodAliquotaProgramavel=3 DescricaoAliquota="" PercentualAliquota=25,00;92}
15/09/2016 10:52:15.616 -> {106;LeAliquota;CodAliquotaProgramavel=4;40}
15/09/2016 10:52:15.644 <- {106;8005;NomeErro="ErroCMDAliquotaNaoCarregada" Circunstancia="Aliquota nao carregada";87}
15/09/2016 10:52:18.451 -> {107;LeAliquota;CodAliquotaProgramavel=5;40}
15/09/2016 10:52:18.483 <- {107;8005;NomeErro="ErroCMDAliquotaNaoCarregada" Circunstancia="Aliquota nao carregada";87}
 

Como é um for de 0..15 sempre, sempre, sempre irá dar esse erro exceto se a ECF estiver com 100% das alíquotas cadastradas. Vou anexar até o print do demolog2 para comprovar.

[Daniel Simoes]

Sim o erro ocorrerá, pois a alíquota não foi programada... mas não ocorrerá o Exception, pois o mesmo é tratado no Loop

[Rodrigo Fruhwirth]

Blz, show de bola, até ai esta tudo 100%, o problema é quando a ECF da erro nos totalizadores/alíquota, nos casos onde a memória da ECF esta com lixo por problemas de queda de energia que no percentual retorne caracteres estranhos, só por isso, ai se der algum erro na alíquota 1 por exemplo as demais alíquotas não são carregadas.

Tirando isso a regra vai funcionar.