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 }