Ir para conteúdo
  • Cadastre-se
  • Total de ítens

    91
  • Registro em

  • Última visita

  • Days Won

    3

Tudo que [email protected] postou

  1. Sim IMATECH, Estamos testando em mais de um computador e o erro é sempre o mesmo.
  2. Boa tarde Morais e feliz 2026, Você conseguiu resolver o problema de Access Violation na sua aplicação? Se SIM, qual foi a solução? É que estamos enfrentando problema similar quando vamos tentar Assinar um MDFe usando a última versão do ACBrMonitorPlus disponível. Abraço
  3. Continuando... Como os testes feitos com a versão 1.4.0.389 continavam a apresentar o mesmo erro de "Access violation", então eu resolvi instalar uma versão mais antiga que eu tinha aqui. Instalei então a versão 1.4.0.241. Pronto, feito isso o sistema voltou a assinar e validar os XML's das MDFe's. Vejam: Reparem que nas primeiras linhas do LOG apareceram erros porque eu mandei "validar" antes de "assinar", então o sistema apresentou o erro 1871. Logo em seguida eu mandei o comando para "AssinarMDFe" e em seguida "ValidarMDFe" e ambos funcionaram corretamente. Segue também o LOG e o XML do MDFe depois de assinado e validado. LOG.TXT 00000370.XML
  4. Juliomar, bom dia, Antes de mais nada quero desejar um feliz 2026 a todos e também agradecer pelo suporte que os parceiros do forum sempre dispensam. Para tirar a dúvida se o Daniel Santos estaria com compilando o ACBrMonitorPlus com alguma falha eu baixei a última versão "demo" (ACBrMonitorPLUS - DEMO - Windows - 32 bits 1.4.0.389) disponibilizada pelo Daniel Simões recentemente. Rodei tudo dentro da IDE do ACBrMonitorPlus para garantir que não haveria qualquer inteferencia externa e o resultado foi o mesmo: "EAccessViolation - Access violation". Seguem algumas telas para confirmar como está instalado/configurado nosso certificado digital e a tela do teste propriamente dito: C:\ACBrMonP>type LOG.TXT 31/12/2025 11:45:51 - ACBr MonitorPLUS Ver.1.4.0.389 - x86 31/12/2025 11:45:51 - Aguardando comandos ACBr 31/12/2025 11:45:51 - Monitorando Comandos TXT em: C:\ACBrMonP\ENT.TXT 31/12/2025 11:45:51 - Respostas gravadas em: C:\ACBrMonP\SAI.TXT 31/12/2025 11:45:51 - Log de comandos ser├í gravado em: C:\ACBrMonP\LOG.TXT 31/12/2025 11:45:51 - Log de mensagens da NFe/NFCe ser├í gravado em: C:\ACBrMonP\LOG_COMP.TXT 31/12/2025 11:47:45 - EAccessViolation - Access violation 31/12/2025 11:47:45 - Access violation Se alguém tiver alguma dica nós agradecemos. 00000370.XML
  5. A questão é que temos duas soluções, uma feita em DELPHI e outra em Harbour / Clipper. Na solução DELPHI nós usamos os componentes sem problema. A questão está relacionada ao uso da solução que usa o ACBrMonitor (ainda utilizada por muitos de nossos clientes). Enfim, precisamos do ACBrMonitor rodando ok, sem alterar algumas tags do XML conforme antes. Com todo respeito, a questão é: estamos dando volta discutindo o porque usar o ACBrMonitor quando deveríamos estar analisando o motivo desta ferramenta estar alterando o XML de forma indevida.
  6. Entenda, O que eu quis dizer é que quando o Daniel (meu colega de trabalho) baixou a nova versão do ACBrMonitor e compilou usando o Lazarus, ele sequer precisava ter necessidade de dominar integralmente a IDE Lazarus, que inclusive é bem similar à do Delphi 7. Nossa expertize realmente é com DELPHI, o que não impede de gerar o novo EXE usando o Lazarus. Estou afirmando apenas que nenhuma linha do fonte foi alterada de forma que viesse a gerar este tipo de erro. Mas enfim, vou analisar aqui o novo código e tentar descobrir o que está acontecendo. O certo é que o novo EXE continua gerando alterando o XML e gerando estes erros. Por hora, obrigado pela ajuda.
  7. Boa noite Juliomar, Antes de mais nada obrigado por responder e tentar ajudar. Quem gerou o EXE do ACBrMonitor foi meu colega de trabalho, mas ele não conhece Lazarus o suficiente para se meter a alterar alguma linha de código. Basicamente o que ele faz é baixar a nova versão no SVN e rodar o compilador. Amanhã eu vejo com ele se foi feita alguma alteração, só por descarrego de consciência. Detalhe, aparentemente o que está acontecendo é, depois de gerado o XML básico da NFe nós damos o comando para Assinar a NFe conforme abaixo: NFe.AssinarNFe("C:\TECDATA\NFe\00001666.XML") Daí neste momento o ACBrMontir assina o documento mas também faz 3 alterações nas Tags: xNome, xFant e xTexto (lá no final do XML). Vou anexar os dois XMLs (o de antes e o depois) e tambem o arquivo LOG gerado, caso vc queira dar uma olhada. E amanhã eu vejo com Daniel como ele está fazendo para compilar o ACBrMonitor. Abraço LOG.TXT 001666-a.xml 001666-d.xml
  8. Boa tarde, Nós compilamos a versão do ACBrMonitorPlus 1.4.0.347 e após isso ao tentar gerar uma NFe tanto em ambiente de Homologação quanto em ambiente de Produção o ACBr altera nosso XML removendo o conteúdo das Tags "xNome" e "xFantasia" do Emitente com o conteúdo: ![CDATA[ ]] e obviamente a NFe não é validada. Antes de tentar da versão 347 já havíamos tentado com as versões 345 e 343 sem sucesso. Alguém sabe dizer como resolver esta pane? 00001666.XML
  9. Bom dia, Acho que agora descobri a solução: Apesar do ACBrMonitorPlus ter a configuração de VERSÃO, foi preciso eu dar o comando CTe.SetVersaoDF("4.00") (que antes desta versão dava erro) para o sistema assumir a versão 4.00. Resumindo, segue a sequencia de comandos que mandei para o Monitor que resolveu o problema: CTe.SetVersaoDF("4.00") CTe.SetModeloDF("57") CTe.AssinarCTe("C:\TECDATA\NFe\00076265.XML") CTe.ValidarCTe("C:\TECDATA\NFe\00076265.XML") CTe.EnviarCTe("C:\TECDATA\NFe\00076265.XML", 76265,0,0,"",0)
  10. Bom dia, Troquei o comando para usar o método Síncrono, mas o erro permanece. Veja o Log gerado: Gerando Log em: C:\ACBrMonP\LOG.TXT O Log em tela é apresentado apenas com o ACBrMonitor aberto! CTe.AssinarCTe("C:\TECDATA\NFe\00076265.XML") OK: C:\TECDATA\NFe\00076265.XML CTe.ValidarCTe("C:\TECDATA\NFe\00076265.XML") OK: CTe.EnviarCTe("C:\TECDATA\NFe\00076265.XML", 76265,0,0,"",0) ERRO: Erro Interno: 0 Erro HTTP: 404 URL: https://cte-homologacao.svrs.rs.gov.br/ws/cteretrecepcao/CTeRetRecepcao.asmx
  11. Oi André, Compilamos recentemente a versão 1.4.0.239 - x86 Se por acaso você estiver usando esta mesma versão, agradeceria se você pudesse compartilhar os arquivos de parâmetros (*.ini). Agradeço antecipadamente, Abraço
  12. Encontrei estas outras URLs neste endereço: https://dfe-portal.svrs.rs.gov.br/CTE/Servicos#SEFAZ%20Rio%20Grande%20do%20Sul%20/%20SEFAZ%20Virtual%20Rio%20Grande%20do%20Sul%20(RS/SVRS)-Homologa%C3%A7%C3%A3o
  13. Boa tarde Andre, Não ainda não consegui fazer rodar. Descobri apenas que se você for fazendo os processos um por um até dá certo, ou seja, vc executa o comando cte.assinar, depois o cte.validar, depois o cte.enviar (neste vai dar o erro, mas o CTe será protocolado). Daí você executa o CTe.ConsultarCTe e verá que o CTe foi protocolado, então é só imprimir usando o CTe.ImprimirDACTe. Também percebi que o links informados no arquivo de configuração ACBrCTeServicos.ini estão diferentes dos indicados no Portal: https://sefaz.es.gov.br/relacao-de-servico-web Homologação CT-e SVRS Serviço URL CTeRecepcao https://cte-homologacao.svrs.rs.gov.br/ws/cterecepcao/CteRecepcao.asmx CteRetRecepcao https://cte-homologacao.svrs.rs.gov.br/ws/cteretrecepcao/cteRetRecepcao.asmx CteConsulta https://cte-homologacao.svrs.rs.gov.br/ws/cteconsulta/CteConsulta.asmx CteRecepcaoEvento https://cte-homologacao.svrs.rs.gov.br/ws/cterecepcaoevento/cterecepcaoevento.asmx CteInutilizacao https://cte-homologacao.svrs.rs.gov.br/ws/cteinutilizacao/cteinutilizacao.asmx CteStatusServico https://cte-homologacao.svrs.rs.gov.br/ws/ctestatusservico/CteStatusServico.asmx Produção CT-e SVRS Serviço URL CteRecepcao https://cte.svrs.rs.gov.br/ws/cterecepcao/CteRecepcao.asmx CteRetRecepcao https://cte.svrs.rs.gov.br/ws/cteretrecepcao/cteRetRecepcao.asmx CteConsulta https://cte.svrs.rs.gov.br/ws/cteconsulta/CteConsulta.asmx CteRecepcaoEvento https://cte.svrs.rs.gov.br/ws/cterecepcaoevento/cterecepcaoevento.asmx CteInutilizacao https://cte.svrs.rs.gov.br/ws/cteinutilizacao/cteinutilizacao.asmx CteStatusServico https://cte.svrs.rs.gov.br/ws/ctestatusservico/CteStatusServico.asmx Eu até tentei alterar o arquivo com estes endereços mas continua sem funcionar.
  14. Bom dia André, Também estou com o mesmo erro a dias sem conseguir solucionar. Acredito que o problema esteja do arquivo "ACBrCTeServicos.ini". Segue o log: Gerando Log em: C:\ACBrMonP\LOG.TXT O Log em tela é apresentado apenas com o ACBrMonitor aberto! CTe.AssinarCTe("C:\TECDATA\NFe\00076265.XML") OK: C:\TECDATA\NFe\00076265.XML CTe.ValidarCTe("C:\TECDATA\NFe\00076265.XML") OK: CTe.EnviarCTe("C:\TECDATA\NFe\00076265.XML", 76265,0,0,"",1) ERRO: Erro Interno: 0 Erro HTTP: 404 URL: https://cte-homologacao.svrs.rs.gov.br/ws/cteretrecepcao/CTeRetRecepcao.asmx ACBrCTeServicos.ini
  15. Aqui também está apresentando exatamente o mesmo erro.
  16. Acho que descobri o motivo do problema. Precisa saber agora como resolver. Andei lendo as soluções adotadas em outros tópicos deste forum e resolvi fazer uns testes na página do ENCAT e percebi que quando eu retiro o pipe ("|") que separa o idCSC/idToken do CSC/Token aí o HushCode bate. Pelo que vi alguns estados usam o pipe para separar estes campos e outros não. Pelo visto o Piauí não está usando... O problema agora é arrumar uma versão do ACBrMonitor Plus que não tenha este caractere separando estes campos.
  17. Pessoal, bom dia, Estou aqui com dificuldade de configurar adequadamente o ACBrMonitor Plus (versão 1.2.0.18) para emitir as NFCe com a versão 2.0 do QRCODE. Nesta próxima segunda (dia 04/02/2019) o Piauí vai iniciar a validar tanto as URLs quanto o CSC/Token. Já atualizei os Schemas, corrigi o CSC/Token que no Piauí tem 24 dígitos, informei um idCSC/idToken com número aleatório (ex: 123), e quando emito uma NFCe mesmo sendo protocolada normalmente quando digitalizo o QRCODE sou levado ao site da SEFAZ-PI mas aparece a mensagem "HashCode inválido com base nos parâmetros". Já pesquisei aqui no forum mas nenhuma das soluções apontadas resolveu. Alguém tem alguma ideia do que fazer? Estas são as URLs que foram corrigidas no arquivo ACBrnfeServicos.INI: [NFCe_PI_P] Usar=NFCe_SVRS_P URL-QRCode=http://www.sefaz.pi.gov.br/nfce/qrcode URL-ConsultaNFCe=http://www.sefaz.pi.gov.br/nfce/qrcode URL-ConsultaNFCe_2.00=http://www.sefaz.pi.gov.br/nfce/consulta [NFCe_PI_H] Usar=NFCe_SVRS_H URL-QRCode=http://www.sefaz.pi.gov.br/nfce/qrcode URL-ConsultaNFCe=http://www.sefaz.pi.gov.br/nfce/qrcode URL-ConsultaNFCe_2.00=http://www.sefaz.pi.gov.br/nfce/consulta OBS: As URLs que vem quando instalamos a última versão disponível do ACBrMonitor estão erradas. Peguei a informação correta no site do ENCAT: http://nfce.encat.org/desenvolvedor . 00000035.XML 00000035.pdf
  18. Acho que esta versão do ACBrMonitorPlus não consegue funcionar com Certificados A3 pois não há como exportar arquivos PFX. Estou enfrentando esta mesma dificuldade com clientes que só usam Certificado A3.
  19. Boa noite, Tive que reinstalar tudo no meu note e estou tendo problemas em instalar o TRUNK2 no Delphi7 em windows 10. As mensagens de erro são: C:\Program Files (x86)\Borland\Delphi7\ACBr\Fontes\ACBrTCP\ACBrCEP.pas(1612) Error: Invalid compiler directive: 'REGION' C:\Program Files (x86)\Borland\Delphi7\ACBr\Fontes\ACBrTCP\ACBrCEP.pas(1695) Error: Record, object or class type required C:\Program Files (x86)\Borland\Delphi7\ACBr\Fontes\ACBrTCP\ACBrCEP.pas(1750) Error: Invalid compiler directive: 'ENDREGION' ACBr_TCP.dpk(61) Fatal: Could not compile used unit '..\..\..\Fontes\ACBrTCP\ACBrCEP.pas' Compilation failure Erro ao compilar o pacote "ACBr_TCP.dpk". Abortando... Ocorreram erros na compilação dos pacotes. Detalhe, antes de iniciar a instalação eu executei o "ApagarAcbr.Bat", e também removi do Delphi do Library Path. Alguém tem alguma dica?
  20. Diego, como assim "atualizei para a última versão"? Ultima versão de que? do ACBrMonitor Plus (1.1.0.27) ou dos Schemas? Como você conseguiu resolver isso?
  21. Agora voltou tudo ao normal !!!! Tudo funcionando como antes !!! Podem voltar a emitir NFCe ...
  22. No meu caso eu já enviava o numero do lote. Então para resolver eu fiz da seguinte forma: NFe.EnviarNFe ("C:\NFCe\00009621.XML", 9621, 0, 0, 0, 1) Antes eu estava enviando assim: NFe.EnviarNFe("C:\TECDATA\NFCe\00009615.XML", 9615, 0, 1) daí dava erro...
  23. Aumentei aqui mas não adiantou. Quais os parâmetros que você utilizou? Qual a versão do ACBrMonitorPlus você está usando? Tem gente me falando que todo dia primeiro de cada mês acontece isso mas não estou querendo acreditar que isso seja normal...
  24. Até as 09 horas e 04 minutos de hoje estava tudo normal. Tenho NFCe protocoladas antes deste horário.
  25. Acho que não é questão de atualização pois eu já atualizei o ACBrMonitorPlus para a última versão disponível no site (de 29/09/2016 - versão 1.0.0.0) e o problema persiste. O que pode ser é alguma implementação a nivel de XML que não tenhamos feito.
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.