Jonatas de Alencar Alves

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.

Olá, Primeiramente agradeço pela resposta. Realmente, foi um erro da minha parte. Não vou me justificar aqui, porém visto que tanto a 'msxml5.dll' quanto a 'libxml2.dll' são parser's imaginei que a primeira fosse descartada juntamente com a 'capicom.dll' visto que sempre (erroneamente) associei as duas. grato!

Olá, Após pesquisar no fórum, esta conversa foi a que mais se aproximou da situação que estou passando. O que está ocorrendo é o seguinte: Fiz uma nova instalação do framework ACBr nesta semana e então iniciei um projeto que tem como objetivo Inutilizar uma ou mais numerações de NFC-e (ainda na versão 3.10 da NF-e). Após a instalação, retirei o comentário do arquivo 'ACBr.inc', ficando desta forma: {$DEFINE DFE_SEM_CAPICOM} Após isto, construí toda a rotina (para testes), inclusive (e muito importante na minha opinião), defini a propriedade SSLLib com o valor libWinCrypt: ACBrNFe.Configuracoes.Geral.SSLLib := libWinCrypt Após isto, quando realizei a tentativa de inutilização, foi apresentada a seguinte exception: EACBrDFeException with message 'Falha ao assinar inutilização Nota Fiscal Eletrônica Não foi possível encontrar o módulo especificado, ClassID: {88D969E5-F192-11D4-A65F-0040963251E5}' conferi as configurações, que são estas inclusive: ACBrNFe.Configuracoes.WebServices.Ambiente := taHomologacao ; ACBrNFe.Configuracoes.Geral.ModeloDF := moNFCe ; ACBrNFe.Configuracoes.Geral.VersaoDF := ve310 ; ACBrNFe.Configuracoes.WebServices.UF := edtUF.Text ; ACBrNFe.Configuracoes.Geral.IdCSC := edtCSC.Text ; ACBrNFe.Configuracoes.Arquivos.PathSchemas := PastaXSD ; ACBrNFe.Configuracoes.Arquivos.PathSalvar := SICNET.AllUserProfile + '\SICNET\NFCe.exe\XML\' ; ACBrNFe.Configuracoes.Geral.SSLLib := libWinCrypt ; ACBrNFe.SSL.SelecionarCertificado ; ACBrNFe.WebServices.Inutiliza( edtCNPJ.Text, memJustificativa.Text, strtoint( trim( RightStr( edtAno.Text, 2 ) ) ), 65, StrToInt( edtSerie.Text ), StrToInt( edtNumInicial.Text ), StrToInt( edtNumFinal.Text ) ) ; Não encontrei nenhuma inconsistência (usei o ACBrNFe_demo.exe como exemplo). Analisando as classes que fazem parte do escopo da assinatura, encontrei a seguinte instrução, que (após o debug) se provou culpada pela exception: // UNIT ACBrDFeXsMsXml xmldoc := CoDOMDocument50.Create; pesquisando sobre esta classe, cheguei a conclusão de que ela está inserida na Type Library ACBrMSXML2_TLB. Esta é por sua vez, a intermediária da C:\WINDOWS\SysWow64\msxml5.dll. Então surgiu a dúvida: A dll msxml5.dll ainda é necessária? Visto que ela faz parte do pacote "Capicom", e este recurso não é mais utilizado no framework, de acordo com a postagem: Por favor, me ajudem nesta questão. Desde já, agradeço pela atenção.