Eder Gilvani

Então, na realidade, respondi no tópico à época pq estava justamente implementando isso, era o que eu tinha entendido lendo manuais, portarias, informações com escritório / depto fiscal de cliente e fóruns de dúvidas contadores. Geralmente sigo as instruções do escritório / depto fiscal do cliente e envio arquivo de testes para validarem e assim indicam ajustes até ficar certo. Finalizei a implementação da forma como citei, gerei arquivos para testes e foram validados. Depois colocamos em produção e clientes conseguiram gerar, validar e enviar os arquivos. Mas cada estado pode até ter algum requisito diferente. Se precisar ainda de ajuda / consultoria específica / especializada e o suporte do ACBrPro atender questões fiscais, pode ser uma alternativa. Há também um outro site/empresa que fornece suporte tributário e fiscal específico para softwares houses (inclusive componentes ACBr): https://www.sacfiscal.com.br

Estou implementando isso e pelo que entendi, todas as NFCEs devem ser incorporadas os registros 61 e 61R. Quanto aos cancelados, denegados e inutilizados apenas não acumulam valores (considera zerados). E no registro 61R que é um resumo mensal por itens constantes nas NFCEs do período, vale então a mesma premissa, acumulando valores das NFCEs normais e não acumulando valores somente daqueles ref. a canceladas e denegadas. Como ainda não finalizei e testei, pode até ser que ocorra rejeição do arquivo por causa deles, então seria só desconsiderá-los no registro 61R.

Cheguei a remover todas as dlls e colocar da versão anterior, mas tbm não resolveu e o windows já havia dado alguns problemas após atualização automática. Botão de pesquisa não pesquisava mais... estava estranho, por isso já optei por formatar... Mas valeu a ajuda...

Formatei notebook, reinstalei windows e as 2 versões Delphi, instalei componentes e funcionou certinho. Algo que eu instalei algum programa antes deve ter corrompido. Já fiz uma imagem do HD por precaução. Agradeço muito pela atenção. Obrigado.

Desculpe demora na resposta, ontem fui fazer procedimento em hospital... Depois destes procedimentos e vários outros realmente não resolveu... Desinstalei todos demais componentes, versões delphi, reinstalei; adicionei só ACBr mas sem sucesso. Tentei combinações de configurações de instalação do ACBr, chegou a acusar erro ao carregar pacote ACBR_OpenSSL. Tentei voltar versões das DLLs OpenSSL anteriores e opção "Não usar OpenSSL" (não sei se sempre instala a última versão automaticamente) mas sem sucesso tbm. Mesmo sendo uma instalação recente do windows, acredito que algum outro programa instalado possa ter interferido em DLLs ou algo assim. O que acho estranho é que ao mesmo tempo, o outro notebook que usava antes há anos, funciona com a pasta ACBR sem últimas atualizações e ao atualizar, acusa mesmo erro, mas também não há mais ninguém no fórum citando problema similar. Então deve ser algo particular com minha instalação. Estou preocupado rsrs. Vou formatar e reinstalar windows e drivers, fazer bkp/imagem do disco, depois só instalar delphi e componentes ACBr atualizados antes de todos demais programas e componentes. Se mesmo assim ocorrer mesmo problema, vou testar também com a versão anterior da pasta ACBr que tenho. Quando terminar, posto o resultado. Agradeço muito pela ajuda por enquanto, obrigado.

Eu também tentei isso, removi a versão nova do openssl e instalei a anterior q estava funcionando antes, mas continou mesmo erro... Só não tenho certeza se fiz o procedimento adequado ao ACBr (caso haja algo especifico), usei instalador openssl shining light... Se tiver alguma instrução diferente sobre isso, posso tentar...

Instalei, mas não resolveu... Eu já havia baixado e reinstalado essa, seguindo tutorial da microsoft sobre este erro.

Após atualizar componentes ACBr, começou a exibir o erro "Runtime error R6034 (Microsoft Visual C++ Runtime)" ao iniciar Delphi 2010, aparentemente ao carregar o pacote ACBr_TCP, conforme imagem anexa. Também ocorre o mesmo erro ao iniciar Delphi 10.3.3 RIO. Segui as instruções de atualização indicadas. Executei "apagarAcbr.bat"como administrador e fiz a instalação, não ocorreu erro. Só ocorre mesmo ao abrir. No delphi 2010 clico em OK e passa, mas ao abrir algum form com componente ACBR, fica processando até fechar o delphi sozinho. No Delphi RIO dá o erro e fica processando até dar erro que não está respondendo. Sempre que atualizo, faço uma cópia da pasta ACBr para manter versão anterior. Removi os componentes, voltei a pasta, refiz a instalação com versão anterior e o erro não ocorre. Windows 10 e os 2 delphi estão atualizados. Notebook novo, instalação recente. Testei também no notebook que usava antes, acontece o mesmo problema com as 2 versões do delphi. Tenho Visual Studio e SQL Server instalados, inclusive Microsoft Visual C++ 2008, 2010, 2012, 2013 e 2015-2019 redistributable (todos x86 e x64) instalados automaticamente pelos sofwares. Já procurei tópicos similares no fórum, pesquisei na internet sobre o erro, mas após 3 dias ainda não consegui resolver. Preciso muito de ajuda e agradeço se puderem.

Corrigido, tudo OK, obrigado!

Atualizei há pouco com SVN e estou com mesmo problema tanto no Delphi 2010 quanto no XE8.

Entendi, tudo bem, realmente seria o ideal, só fiz novo post pq achei q era situação especifica, mas é a mesma.

Oi bom dia, muito obrigado pela sua atenção... Antes de postar eu já tinha consultado todos os tópicos a respeito, inclusive, até havia postado no mesmo tópico uma solução que achei mas que acabei esbarrando (ou descobrindo) outro problema. O componente após ter gerado o NN completo, acusa erro de tamanho máximo do NN, entenda assim, o componente aceita que se informe apenas a parte sequencial do NN e gera o NN completo sozinho (com mais dados, carteira, agencia, etc) e depois acusa erro do tamanho NN gerado por ele mesmo, mas pq está testando com base em cálculo do tamanho apenas do sequencial. Isso já ocorreu no meu sistema com Bradesco, BB em varias carteiras. Quando usava somente para emissão do boleto, funcionava perfeito, descobri o problema quando precisei pegar o NN antes de imprimir e alterei o sistema, acho que outros programadores devem ter passado pelo problema e ter se adaptado. Sugeri o post apenas para que seja avaliado se é mesmo um erro de lógica e sugerir uma melhoria, dados que seria interessante se obter o NN completo calculado a qualquer momento e não apenas em dado momento de processamento do componente e ainda exibir o erro de tamanho.

Após vários dias tentando adaptar meu sistema para a forma de geração do campo nosso número do ACBrBoleto, comecei a debugar as rotinas do ACBr e em alguns momentos me deparei com uma situação onde posso não estar seguindo ou entendendo a sequência correta de operação com ACBr ou então há um erro de lógica nas rotinas. Apesar de funcionar sem erro para emitir boletos, no meu caso, para salvar no título, era necessário obter o NN gerado completo pelo componente e isso ocorre apenas em determinado momento, sendo assim, tentei de 2 formas: Forçar o cálculo antes de imprimir ou obter o NN gerado após imprimir. Neste ponto que começou a acusar erro de tamanho máximo do NN pelo componente e também o NN do banco do brasil com registro foi gerado diferente do manual, onde devia ter 12 posições tinha 17. Para entender e simular os passos: 1. No primeiro momento, passa-se para o componente apenas o sequencial do NN e ele calcula o tamanho máximo do NN somente da parte sequencial dele. 2. Após componente gerar o NN completo que, em alguns casos, são adicionados carteira (bradesco), código do cedente (banco do brasil, carteira 18), DV, barra, e/ou traço, etc. ao NN, em determinado momento, o componente faz a validação do tamanho do NN completo mas com base no tamanho apenas da parte sequencial do NN, acusando erro de tamanho máximo. Exemplo Bradesco: NN completo = CC SSSSSSSSSS D C=carteira (2) S=sequencial (11) D=DV (1) Tamanho total = 14 (só números) 1. Componente seta tamanho máximo como 11 (somente parte do sequencial) 2. Gera NN completo conforme especificação 3. Na validação de tamanho com NN completo acusa erro, pois NN tem 14 digitos e tamanho máximo está definido como 11 Exemplo BB convênio com 4 posições, sem registro: NN completo = SSSSSSSSSSSSSSSSS S = sequencial (17) Tamanho total = 17 (só números, sem DV sem mais nada) 1. Se passar sequencial do NN ao componente com tamanho menor que 10, seta tamanho máximo como 05 (somente parte do sequencial, mas que seria tamanho máximo apenas da parte sequencial da carteira com registro) 2. Gera NN completo conforme especificação com 17 posições, e na rotina que calcula o tamanho máx. do NN passa para 17 no meio do processamento. 3. Na validação de tamanho com NN completo passa, tendo em vista que o tamanho do NN completo é maior que 10 (código que calcula tamanho máximo do sequencial do NN) Exemplo BB convênio com 4 posições, com registro: NN completo = CCCCCC SSSSS D C = Cod.convenio (6) S = sequencial (5) D = DV (1) Tamanho total = 12 (só números) 1. Componente seta tamanho máximo da parte do sequencial do NN como 5. 2. Gera NN completo conforme especificação acima com 12 posições, mas recalcula o tamanho máx. do NN para 17 agora (trecho do código que verifica se tamanho do NN é maior que 10 para setar tam. max. para 17). 3. Em determinado momento, formata o NN acima com 17 posições, mantendo a numeração gerada, adicionando zeros a esquerda por causa do novo tamanho. 4. Na validação de tamanho com NN completo passa, tendo em vista que o tamanho do NN completo é maior que 10 (código que calcula tamanho máximo do sequencial do NN) Inclusive nesta validação de tamanho, considera também os traços, barras, etc. não validando apenas os digitos numericos. Na minha opinião, a solução seria alterar o código fonte do ACBR com as sugestões seguintes: 1. Adicionar propriedade no ACBrTitulo para informar apenas sequencial do NN com cálculo e validação apenas do tamanho desta parte sequencial dele; 2. A propriedade "NossoNumero" do ACBrTitulo gerar automaticamente o NN completo calculado com cálculo e validação de seu tamanho completo. 3. Adicionar função (pública) no componente para retornar ou gerar o NN calculado a fim de se obtê-lo a qualquer momento, de acordo com a necessidade de cada sistema. 4. Adicionar propriedade "SemRegistro" tipo boolean no ACBrBanco que será setada pelo usuário e será usada pelo ACBrBancoBrasil (e por ventura outro banco) no cálculo do tamanho máximo do NN para carteira 16 e 18 sem registro, em substituição ao código fonte "If Length(trim(NossoNumero)) > 10" que se torna true no meio do processo, quando NN está completo e pode ser um erro de lógica.

Mesmo com código fonte acima, acabei caindo em outro problema, voltei ao código original, acho que a causa do problema é outra: a checacem do tamanho do campo Nosso Número em 2 momentos distintos: 1. No primeiro momento, passa-se para o componente apenas o sequencial do NN e ele calcula o tamanho máximo do NN somente para a parte sequencial dele. 2. Após gerar o NN completo, em alguns casos, são adicionados carteira (bradesco), código do cedente (banco do brasil, carteira 18 com registro), DV, barra, e/ou traço, etc. ao NN e em determinado momento, o componente faz a validação do tamanho do NN completo mas com base no tamanho apenas da parte sequencial do NN, acusando erro de tamanho máximo excedido. Exemplo Bradesco: NN completo = CC SSSSSSSSSS D C = carteira (2) S = sequencial (11) D = DV (1) Tamanho total = 14 (só números) 1. Componente seta tamanho máximo como 11 (somente parte do sequencial) 2. Gera NN completo conforme especificação acima 3. Na validação de tamanho com NN completo acusa erro, pois NN tem 14 digitos e tamanho máximo está definido como 11 Exemplo BB convênio com 4 posições, sem registro: NN completo = SSSSSSSSSSSSSSSSS S = sequencial (17) Tamanho total = 17 (só números, sem DV sem mais nada) 1. Se passar sequencial do NN ao componente com tamanho menor que 10, seta tamanho máximo como 05 (somente parte do sequencial, mas que seria tamanho máximo da parte sequencial da carteira com registro) 2. Gera NN completo conforme especificação acima com 17 posições, recalculando o tamanho máx. do NN para 17 agora. 3. Na validação de tamanho com NN completo passa, tendo em vista que o tamanho do NN completo é maior que 10 (código que calcula tamanho máximo do sequencial do NN) Exemplo BB convênio com 4 posições, com registro: NN completo = CCCCCC SSSSS D C = Cod.convenio (6) S = sequencial (5) D = DV (1) Tamanho total = 12 (só números) 1. Componente seta tamanho máximo da parte do sequencial do NN como 5. 2. Gera NN completo conforme especificação acima com 12 posições, mas recalcula o tamanho máx. do NN para 17 agora. 3. Em determinado momento, formata o NN acima com 17 posições, mantendo a numeração gerada, adicionando zeros a esquerda por causa do novo tamanho. 4. Na validação de tamanho com NN completo passa, tendo em vista que o tamanho do NN completo é maior que 10 (código que calcula tamanho máximo do sequencial do NN) Inclusive nesta validação de tamanho, considera também os traços, barras, etc. não validando apenas os digitos numericos. Na minha opinião, teria que ajustar o código fonte do ACBR, para calcular o tamanho apenas da parte do sequencial do NN e outra que calcule tbm o tamanho do NN completo. A validação de tamanho teria que corresponder ao tamanho completo do NN.

Só consegui resolver alterando o código fonte do ACBrBoleto e ACBrBancoBrasil da seguinte forma: 1. Adicionei propriedade "SemRegistro" tipo boolean na classe TACBrBanco property SemRegistro: boolean read fSemRegistro write fSemRegistro; No meu sistema, adicionei um campo checkbox "Sem registro" na configuração da conta de cobrança. Na conta do Banco do Brasil, se carteira for 16 ou 18 e sem registro, seto o campo em true. Ao setar as propriedades do componente em runtime, seto o referido campo. 2. Alterei a rotina "CalcularTamMaximoNossoNumero" na unit ACBrBancoBrasil (alterações estão em negrito): function TACBrBancoBrasil.CalcularTamMaximoNossoNumero( const Carteira: String; NossoNumero : String = ''): Integer; var wCarteira : String; wTamConvenio: Integer; begin Result := 12; //10; { Alterado para compatibilizar o tamanho do NN final gerado } if (ACBrBanco.ACBrBoleto.Cedente.Convenio = '') then raise Exception.Create(ACBrStr('Banco do Brasil requer que o Convênio do Cedente '+ 'seja informado.')); if (Carteira = '') then raise Exception.Create(ACBrStr('Banco do Brasil requer que a carteira seja '+ 'informada antes do Nosso Número.')); wCarteira:= Trim(Carteira); wTamConvenio:= Length(Trim(ACBrBanco.ACBrBoleto.Cedente.Convenio)); { Alterado, antes era "Length(trim(NossoNumero)) > 10", no inicio fica certo, pois recebia apenas o sequencial do NN, após gerar NN completo com cod.cedente 12 digitos, atingia condição errada, como 17, deixando o NN errado } if ACBrBanco.SemRegistro and (wTamConvenio = 6) and ((wCarteira = '16') or (wCarteira = '18')) then Result:= 17 else if (wTamConvenio <= 4) then Result := 12 //7 { alterado, não considera o tamanho do NN final completo, onde campo cod.cedente é adicionado ao sequencial do NN } else if (wTamConvenio > 4) and (wTamConvenio <= 6) then Result := 12 //5 { idém } else if (wTamConvenio = 7) then Result := 17; //10; { idém }

No item "b" quando digo que o sistema gera o NN corretamente, deve-se entender o componente ACBrBoleto (BB)

Percebi o mesmo problema no meu sistema usando ACBrBoleto para Banco do Brasil, carteira 18, cod.convênio de 6 posições. Fiz várias alterações a fim de adaptar meu sistema, mas em vão. Tive que debugar o código fonte do ACBr e acho que encontrei um erro de lógica. Para carteira 18 e cód. convênio de 6 posições, há 2 formatações de Nosso Número, sendo: a) 17 posições livres. Onde teria que sair o código "21" na posição 43 e 44 do código de barras; ACBr acusa erro de tamanho máximo de NN de 11 posições (pois considera apenas o sequencial e neste caso, deveria considerar todas as posições pois seria livre. Nosso número de 11 posições + DV formado por 6 digitos do código do cedente + 5 digitos do sequencial do cliente + DV. Até certo ponto o sistema gera o NN corretamente, porém após gerar o NN completo (cod.cedente + sequencial + dv) em determinado momento verifica novamente o tamanho máximo do NN, onde retorna 12 (NN já formado e completo) mas deveria ser 5 (apenas parte do sequencial) como no primeiro momento, ai já começa a processar e forma novamente o NN conforme o item "a" que citei, mas agora com 17 posições, tendo o cód.cedente junto. Acho que o momento que dá problema é quando forma o código de barras, que chama novamente a função que verifica o tamanho do NN. A correção acho que consiste em mudar a variável wTamNossoNum de local nas procedures e funções como propriedade, sendo setada apenas no primeiro momento e sendo usada pelas demais procedures. O problema ocorre devido a passar para o componente apenas o sequencial do NN e depois ele formar o NN completo e continuar chamando a função que retorna o tamanho do NN, mas após ter gerado NN completo, onde já retorna tamanho total.

O tópico é antigo, mas tive esse problema recentemente, não consegui resolver a tempo, acabei perdendo um cliente há um ano aproximadamente, tratava-se de uma situação muito específica para acontecer. Neste mês, ocorreu novamente em novo cliente, mas o engraçado é que tenho vários clientes com ECFs de diversas marcas, mais especificamente de EPSON e que o problema não ocorre. Como eu disse é uma situação muito especifica e não sei se conseguirei explicar bem. - O problema ocorre quando a configuração do nosso sistema está diferente da configuração interna do ECF. Aparentemente seria um erro de lógica ou conflito de lógica entre os codigos fontes do nosso sistema e o do ACBRECF; - Ao enviar o ECF para intervenção e solicitar configuração correta, por algumas vezes, os técnicos dizem já estar certo e não está. Parece que eles confundem configuração de decimais de preço com qtde e vice versa. - O problema ocorre na unit ACBrECFEpson na procedure TACBrECFEpson.Ativar_Epson. No código do nosso sistema, as propriedades do componente ACBRECF são setadas primeiro com as configurações salvas no nosso sistema, depois executa-se o comando para iniciar (ativar)o ECF. - A unit TACBrECFEpson.Ativar_Epson envia alguns comandos para o ECF para ele retornar as configurações internas de qtde de colunas, casas decimais de preço e qtde e sobrepõe as propriedades do componente (aquelas que nosso sistema setou primeiro, deixando-as compatíveis com o ECF) - Na lógica e estrutura do nosso sistema, o componente ACBRECF fica em um datamodule que é instanciado apenas ao iniciar e permanece, portanto o dm e o componente não são destruídos até fechar o sistema. A nossa tela PDV (que usa o ECF) não é única e pode ser aberta e fechada durante o uso do sistema, alterando-se com outras telas. - Quando inicia a tela PDV pela primeira vez, o ECF é ativado e ao fechar é desativado e é aqui que há o conflito de lógica e onde inicia-se o problema. Se qualquer sistema ativa o ECF apenas 1x ou destroi o componente após o uso, o problema nunca ocorre, pois suas propriedades são "zeradas", "inicializadas" sempre. O problema só ocorre quando o ECF pode ser ativado e desativado e o componente é instanciado apenas 1x durante toda execução do sistema. - A simulação e sequência em que ocorre o problema resume-se: - Quando a tela PDV é aberta pela primeira vez, as propriedades do componente são carregadas com as configurações do sistema, o ECF é ativado e as propriedades são sobrepostas com as do ECF. - Quando a tela é fechada, executa-se uma outra tarefa e a reabre novamente, a mesma sequência é executada, mas no código que deveria sobrepor as propriedades obtidadas do ECF, há um IF de condição "if fpColunas < 0 then" que impede que as propriedades de casas decimais do componente sejam sobrepostas com as configurações do ECF. A propriedade fpColunas foi setada já na primeira inicialização do ECF e como o componente nem o datamodule dele não são destruídos, a propriedade se mantém, impedindo as atualização das demais propriedades de casas decimais. - Portanto, se a configuração de casas entre nosso sistema e o ECF estiverem diferentes e houver a tela for fechada e reaberta (reiniciando o ECF), quando o componente ACBRECF envia a string do comando VenderItem, o preço e/ou qtde são enviados com divergência de casas decimais e o ECF processa o posicionamento da fração decimal de acordo com sua configuração interna. Um valor e/ou qtde de 10,00 originais podem ser convertidos em 100,00 ou 1,00 dependo da diferença de configuração salva no nosso sistema e a do ECF. - A solução consistem em: 1. Desativar/comentar os códigos "if fpColunas < 0 then", "begin" e "end" e deixar sempre executar os comandos ao iniciar ECF ou ao desativar, zerar as propriedades para os valores iniciais (principalmente fpColunas); 2. Criar código após iniciar o ECF para verificar se a configuração do nosso sistema está diferente da propriedade do componente do componente ACBRECF, emitir aviso de conflito e necessidade de solução e desativar o ECF, impedindo seu uso. Neste caso, ou corrige-se a configuração do nosso sistema para compatibilizar com ECF ou envia o ECF para intervenção e ajuste da configuração. procedure TACBrECFEpson.Ativar_Epson ; begin try //if fpColunas < 0 then { DESATIVAR/COMENTAR } //begin { DESATIVAR/COMENTAR } EpsonComando.Comando := '0905' ; // Obtendo o numero de colunas EnviaComando ; fsTentaDetectarVelocidade := False; fpColunas := max( StrToIntDef( EpsonResposta.Params[0], 0 ), 48) ; EpsonComando.Comando := '0585' ; // Obtendo o numero de Decimais EnviaComando ; fpDecimaisQtd := StrToIntDef( EpsonResposta.Params[0], fpDecimaisQtd) ; fpDecimaisPreco := StrToIntDef( EpsonResposta.Params[1], fpDecimaisPreco) ; EpsonComando.Comando := '090A' ; // Obtendo se a ECF Imprime Cheque, e Le CMC7 EnviaComando ; fsImprimeCheque := EpsonResposta.Params[4] = 'S'; fsLeituraCMC7 := EpsonResposta.Params[14] = 'S'; //end ; { DESATIVAR/COMENTAR } fsIsFBIII := (pos( 'FBIII', SubModeloECF ) > 0) ; except On E : Exception do begin raise EACBrECFNaoInicializado.Create( ACBrStr( 'Erro inicializando a impressora '+fpModeloStr) + sLineBreak + E.Message ); end; end ;