Jump to content
Notícias do ACBr

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

consultoria_sticker.png

Conteúdo para desenvolvedores
 ao vivo de terça a quinta!
Saiba mais

dev.png

logo_acbr_paygo.png

TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


Saiba mais

beneficios.png

Eder Gilvani

Membros
  • Content Count

    17
  • Joined

  • Last visited

Community Reputation

6 Neutral

About Eder Gilvani

  • Rank
    Novato

Profile Information

  • Sexo
    Masculino
  • Location
    Americana-SP

Recent Profile Visitors

629 profile views
  1. 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.
  2. 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...
  3. 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.
  4. 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 ou
  5. 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...
  6. Instalei, mas não resolveu... Eu já havia baixado e reinstalado essa, seguindo tutorial da microsoft sobre este erro.
  7. 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é da
  8. Atualizei há pouco com SVN e estou com mesmo problema tanto no Delphi 2010 quanto no XE8.
  9. Entendi, tudo bem, realmente seria o ideal, só fiz novo post pq achei q era situação especifica, mas é a mesma.
  10. 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 s
  11. 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 gera
  12. 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 taman
  13. 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 (alt
  14. No item "b" quando digo que o sistema gera o NN corretamente, deve-se entender o componente ACBrBoleto (BB)
×
×
  • Create New...