Jonatas de Alencar Alves

Olá, estava ocorrendo mesmo problema aqui, verifiquei no gerenciador de dispositivos do Windows, que a balança estava conectada a porta COM4, então alterei a porta de COM1 para COM4, configurei o componente ACBrBAL da seguinte forma: Balança = Toledo Porta = COM4 Baud rate = 2400 Data Bits = 8 Parity = none Stop Bits = s1 Handshaking = Nenhum Esta configuração deu certo aqui, funcionou normalmente. Estou compartilhando com pessoal, que enfrentar a mesma situação, tenta esta configuração pode resolver pra vocês também. Vlw.

Olá, estava tendo o mesmo problema relatado pelo @Ihury Humberto Costa, com cliente do estado de Goiás, então fiz o que ele falou, adicionei o arquivo ACBrNFeServicos.ini na pasta do exe, e o problema foi resolvido. Vlw e forte abç!

Olá, existe um problema na solução aplicada em relação ao problema em MG, onde são geradas namespaces xmlns="http://www.portalfiscal.inf.br/nfe" indiscriminadamente. A solução aplicada foi esta: procedure TNFeWebService.RemoverNameSpace; begin FPRetWS := StringReplace(FPRetWS, ' xmlns="http://www.portalfiscal.inf.br/nfe"', '', [rfReplaceAll, rfIgnoreCase]); end; na unit ACBrNFeWebServices.pas. O problema nesta solução, é que são excluídas todas as ocorrências deste namespace, até mesmo a do a cabeçalho, de forma indiscriminada, ou seja, para todas as UF's. A consequência disto é que em sistemas que utilizam mapeamento de "XSD", e naturalmente, realizam binding do conteúdo "xml", retornam exceção "EIntfCastError", pela ausência do TargetNamespace "http://www.portalfiscal.inf.br/nfe" no "xml". Aplicamos uma adequação de acordo com o cenário, sendo que código é este: procedure TNFeWebService.RemoverNameSpace; begin if UpperCase( FPConfiguracoesNFe.WebServices.UF ) = 'MG' then // Luis 01/11/2019 begin FPRetWS := StringReplace( FPRetWS, ' xmlns="http://www.portalfiscal.inf.br/nfe"', '', [ rfReplaceAll, rfIgnoreCase ] ) ; end ; end; Utilizando a seguinte lógica: Quando a UF do emitente for diferente de MG, o "xml" recebido da SEFAZ será utilizado da forma original, porém quando a UF for MG, então será aplicada a alteração original, e nossa recomendação é que nos sistemas que utilizam a biblioteca "xmldom", reponham o namespace "na mão". Obs: Em anexo a unit mencionada acima, contendo as alterações relatadas. Grato! ACBrNFeWebServices.pas

Olá, após realizar o update (Revision 16132), ao tentar transmitir uma NFC-e (utilizando Certificado digital A1), a operação foi realizada com êxito. obs: Antes de aplicar este update, estava ocorrendo "Assinatura difere do calculado". Sigo acompanhando!

Olá, se você emitiu a NF-e utilizando o trecho de código que exemplifiquei, realmente apenas a data será referenciada pois: SysUtils.date retorna apenas um "TDate". Para resolver isso, você tem duas opções * preencher da seguinte forma: // trecho de código obtido em um projeto compilado em Rad Studio 2010 with <objACBrNFe>.NotasFiscais.Add.NFe do begin ... Ide.dEmi := sysUtils.now ; Ide.dSaiEnt := sysUtils.now ; ... end ; * obter as dateTimes de um dataset em runtime. Até+

Olá @dreamsoft_PR, esta rejeição ocorre pois a SEFAZ não aceita NF-e de saída cujo a data de saída seja menor que a data de emissão da nota fiscal. Fonte: http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=Z1BZoLPWt5k= Para resolver este problema, a data de saída deve ser igual ou maior que a data de emissão da NF-e. Exemplo de preenchimento: // trecho de código obtido em um projeto compilado em Rad Studio 2010 with <objACBrNFe>.NotasFiscais.Add.NFe do begin ... Ide.dEmi := sysUtils.date ; Ide.dSaiEnt := sysUtils.date ; ... end ; Até+

Olá, estava enfrentando este mesmo problema, porém a impressora era uma Bematech MP4200 TH. Quando "chegava" no vigésimo terceiro item, a impressão simplesmente era finalizada, sendo que na venda haviam mais de 30 itens. Para resolver, fiz o seguinte: Em 'Dispositivos e impressoras', cliquei sobre a impressora e então cliquei na opção 'Propriedades do servidor de impressão' e criei um novo formulário ; // atenção aqui, pois o novo formulário deve obrigatoriamente ter o combo altura/largura diferente do formulário usado como base (100mm x 100mm no meu caso) Clicar com o botão direito sobre o ícone da impressora em questão e então clicar na opção 'Preferências de impressão', surgira a janela "Preferência de impressão de <nomeDaImpressora>" e então clicar no botão "Avançado", sugira a janela "Opções avançadas do <nomeDaImpressora>" e na propriedade "Tamanho do papel" selecione o formulário criado anteriormente, clique em "ok" e na janela "Preferência de impressão de <nomeDaImpressora>" clique no botão "Aplicar" ; Clique novamente com o botão direito do mouse sobre o ícone da impressora em questão, clique na opção "propriedades da impressora", será exibida a janela "Propriedades da impressora <nomeDaImpressora>". Nesta janela, clique na guia "Configurações do Dispositivo", e então na propriedade "Automático", selecione o formulário criado anteriormente, após isto, clique em "Aplicar", na sequência clique em "ok" ; Ao enviar a impressão da DANFCe para impressão, usando a impressora citada, foi gerada com sucesso, sem cortes. Grato!

Olá, @Italo Jurisato Junior não consigo testar processos de envio, pois não tenho CD de emitente para o PR, porém fiz o teste de "ping" neste endereço de WS, e o resultado foi o seguinte: usando "https://homologacao.nfe.sefa.pr.gov.br/nfe/NFeRecepcaoEvento4" é apresentada a mensagem " HTTP GET not supported" usando "https://homologacao.nfe.sefa.pr.gov.br/nfe/NFeRecepcaoEvento4?wsdl", são apresentadas as definições da WS. Grato!

Olá, posso estar falando besteira (como sempre), mas me parece que no arquivo "ACBrNFeServicos.ini" o endereço da WS (ambiente de homologação) para Recepção de eventos está incorreto: no arquivo mencionado: RecepcaoEvento_4.00=https://homologacao.nfe.sefa.pr.gov.br/nfe/NFeRecepcaoEvento4 no portal da NFe: https://homologacao.nfe.sefa.pr.gov.br/nfe/NFeRecepcaoEvento4?wsdl Grato!

Olá, as web services de homologação e produção foram desativadas. Não será possível enviar NF-e para teste nem em produção, na versão 4.0. Vide Nota Técnica 2016.002 1.41. Grato!

Olá, os clientes aqui da empresa (na qual atuo), utilizam certificados "A3" de fornecedores diferentes: CertSign, Serasa e etc. E todos eles (não me lembro a quantidade exata) mencionaram o mesmo problema (Erro 12175). Após aplicar as mudanças, fiz os testes utilizando um certificado "A3" da Certsign, e funcionou normalmente. Agradeço muito @Adair Filho !!!! Obs: Só para constar, passei a alimentar o campo <TACBrNFe>.SSL.Senha apenas uma vez, durante todo o ciclo de vida do form responsável pela emissão de NFC-e. Caso este form seja fechado, é necessário preencher novamente a "Senha" no "ACBr". Grato!

Olá, @Adair Filho Muito bom!!! Entendi a ideia, o "A3" após ser invocado permanece na memória aberto - independente se o objeto que o invocou for ou não destruído - com a senha informada inicialmente no Owner. Funcionou aqui... Desculpe minha ignorância, mas e se por algum motivo for necessário trocar a senha? Vlw Adair, agora tenho apenas que aplicar esta regra. Obs: Fiz os testes com revision 13882. Haveria alguma forma de evitar que a instância do "A3" ficasse na memória? Grato!

Olá, só para constar, esta mensagem de erro (12175) é a mesma mensagem exibida quando não se informa a senha do certificado digital A3, ou seja, se ao tentar assinar algum arquivo não for informada a senha do certificado, a mensagem de erro retornada é a mesma: Erro Interno: 12175 Erro HTTP: 0 Falha Recebendo Dados. Erro:Erro: 12175 - Um ou mais erros foram encontrados no certificado Secure Sockets Layer (SSL) enviado pelo servidor ou seja, a mensagem de erro que ocorre na segunda requisição [na rotina normal] ao certificado digital, é igual à mensagem de uma situação onde a senha não é informada, tanto na tela do "PIN" (nativa do certificado) quanto via configuração "ACBr": <TACBrNFe>.Configuracoes.Certificados.Senha Só para constar, no projeto de emissão de 'NFC-e' aqui na empresa, o objeto <TACBrNFe> é criado em runtime, ou seja, todos os processos envolvendo ele, são feitos em tempo de execução: Configuração, Emissão e naturalmente a Destruição ao final do processo. @valdirdill Da forma que você solucionou (temporariamente) realmente funciona, porém os clientes que utilizam a aplicação 'nfc-e', da empresa onde trabalho, são varejista de porte médio e naturalmente o fluxo de compradores é alto, ou seja, o tempo necessário para digitar a senha seria muito "oneroso", de acordo com os próprios clientes. Se alguém puder me ajudar, serei muito grato!

Olá, mesmo trocando o valor definido na propriedade '<TACBrNFe>.SSL.SSLType' para 'LT_SSLv3', o problema persiste, ou seja, na segunda requisição do certificado digital, ocorre a mensagem de erro mencionada anteriormente, independente da forma em que se façam as requisições: * 'status de serviço' e depois 'emissão' = ocorre a mensagem de erro ; * 'emissão' (OK) e depois outra 'emissão' = ocorre a mensagem de erro ; reverti a versão do "ACBr" para a 13740, e então voltou ao "normal", mas isto com certeza não é a resolução. Estou analisando o código fonte e até agora descobri apenas que a mensagem de erro é retornada na seguinte rotina: if not WinHttpReceiveResponse( pRequest, nil) then begin UpdateErrorCodes(pRequest); raise EACBrWinReqResp.Create('Falha Recebendo Dados. Erro:' + GetWinInetError(FpInternalErrorCode)); end; que está na unit ACBrWinHTTPReqResp ; Se alguém puder me ajudar nesta situação, serei muito grato!

Olá, Estou enfrentando a mesma situação reportada pelos colegas anteriores. Realizei uma nova instalação do "ACBr", ou seja, criei o diretório "ACBr", fiz o checkout e então instalei os componentes que utilizo. Tenho uma aplicação cujo objetivo é realizar a emissão de NFC-e, nela utilizo a classe "TACBrNFe". Os dados do certificado digital (Número de série, Senha, e etc) ficam armazenados no banco de dados. O processo de emissão é o seguinte: // considerando que já existe uma venda feita e ela foi definida para a emissão do NFC-e. * Cria o objeto <TACBrNFe> é runtime ; * O objeto <TACBrNFe> é configurado ; // recebe os dados de acordo com o cliente * Defino <TACBrNFe>.SSL.Senha ; * Consulto o status do serviço ; * É construído o arquivo '.xml' referente à NFC-e ; * O arquivo '.xml' é assinado ; * O arquivo '.xml' é enviado para a SEFAZ ; Na primeira vez que esta rotina é executada, não ocorre nenhum problema. A partir da segunda vez, que a rotina é executada (a aplicação permanece aberta), ocorrem os seguintes erros: este problema ocorre somente com clientes [da empresa onde trabalho] que utilizam certificado digital A3. A título de teste, utilizei o método '<TACBrNFe>.SSL.SelecionarCertificado', ao invés de utilizar os dados [armazenados no "banco"]. Alguém pode me ajudar nesta situação por favor, realmente não consegui entender esta situação.