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.

Olá, A situação é a seguinte. Utilizo o componente 'ACBrBoleto' em uma solução aqui na empresa, para a gestão de cobrança bancária, por enquanto só oferece suporte ao CNAB 400. Recentemente, após atualizar os "fontes" do "ACBr", um dos nosso clientes (que envia arquivos remessa para a instituição bancária Santander S.A.) informou que o arquivo os arquivos '.rem' passaram a ser rejeitados, e o argumento para esta atitude (por parte do Santander) é que o campo 'Complemento (nota 2)' (posição 384-385) estava sendo preenchida incorretamente. Verifiquei alguns arquivos '.rem' gerados e constatei que realmente o campo mencionado, estava preenchido incorretamente. Consultei o código fonte na unit 'ACBrBancoSantander.pas' e concluí o seguinte. O problema é na construção do 'Registro de Movimento', mais especificamente no seguinte trecho: PadRight(Sacado.Avalista, 30, ' ' )) + ' I' + // 352 a 383 Cedente.ContaDigito + Space(6) + // 384 a 391 De acordo com o manual de orientação CNAB 400 (Versão 2.15), fornecido pela instituição bancária Santander S.A. (Em Anexo). O campo 'Complemento' (posições 384-385) deve ser preenchido da seguinte forma: ou seja, caso a conta de cobrança + Dígito seja '000013001-9', o campo 'Complemento' deverá ser preenchido com '19'. Para resolver este problema é necessário fazer o seguinte: PadRight(Sacado.Avalista, 30, ' ' )) + ' I' + // 352 a 383 Copy( Cedente.Conta, length( Cedente.Conta ),1 ) + Cedente.ContaDigito + Space(6) + // 384 a 391 agradeço pela atenção! obs: Em anexo, a unit 'ACBrBancoSantander.pas' com as alterações. Também incluí a mudança na rotina que constrói a "Mensagem". H7800 Layout CNAB 400 com registro (padrão 353) março 2017 v 2.15.pdf ACBrBancoSantander.pas

Olá, Não realizamos alterações nos fontes do "ACBr", regra da empresa. Na primeira vez fiz o download e posteriormente a instalação do framework [em Abril deste ano], depois disto apenas usei os recursos disponíveis, do 'ACBrNFe' para ser mais específico. De qualquer forma, criei um novo diretório chamado "ACBr2" e então fiz o checkout do trunk2. Ao consultar a unit ACBrDFeXsMsXml.pas, realmente BigWings, as linhas que citei no meu último post estão comentadas. //xmldoc.save('c:\temp\xmldoc.xml'); //xmldoc.save('c:\temp\ass.xml'); pessoal, agradeço pela atenção, desculpe qualquer coisa.

Olá, Então BigWings, não uso a biblioteca ACBrTaxaDolar.pas. Os arquivos temporários são criados na rotina TDFeSSLXmlSignMsXml.Assinar, para não floodar o post, vou colocar apenas as linhas que são responsáveis por criar os arquivos temporários: xmldoc.save('c:\temp\xmldoc.xml'); xmldoc.save('c:\temp\ass.xml'); este método que mencionei (TDFeSSLXmlSignMsXml.Assinar) está na biblioteca ACBrDFeXsMsXml. obs: No meu projeto, a propriedade <TACBrNFe>.Configuracoes.Geral.SSLLib, está "setada" como libWinCrypt. Agradeço a todos pela atenção.

Olá, Então Juliomar, não usamos o 'acbrnfe_demo' na prática, desta forma, nenhum dos processos mencionados foi baseado no exemplo que está no svn. Tanto o processo de emissão de NF-e quanto o debug, foram realizados na aplicação que construímos aqui na empresa, ou seja, o 'ACBrNFe_Demo' foi referência apenas como base de consulta no tocante as rotinas implementadas para a emissão da NF-e. Obrigado pela atenção.

Olá, Desde o início (01/06/2016) do projeto "NF-e" aqui da empresa, usamos o trunk2, ou seja, não houve a migração do trunk para o trunk2. Desta forma RicadorVoigt , respondendo sua questão, nunca precisei fazer atualização para o trunk2. obs: Baseado no fato em que usamos o 'trunk2' desde o início, e pelo debug que fiz, posso dizer que o "ACBrNFe" sempre (Vou estudar um pouco mais os fontes pra ver se isso é possível de ser alterado) tenta salvar os arquivos temporários em 'C:\temp', tanto antes de assinar quanto antes de validar o arquivo '.xml'. agradeço pela atenção!

Olá, Segui a dica do RicardoVoigt, e então fiz o debug para verificar onde o arquivo '.xml' construído pelo "ACBrNFe" era salvo. Descobri que ele tenta gravar alguns arquivos temporários em 'c:\temp' (Posteriormente vou verificar se isto pode ser alterado) antes de assinar o arquivo '.xml', porém no computador da cliente não existia esta pasta ('C:\temp'), logo quando o objeto "ACBrNFe" tentava assinar o arquivo, ocorria a mensagem de erro que relatei. Para resolver, apenas criei manualmente o diretório 'C:\temp'. Ao tentar emitir a NF-e, a operação foi realizada com sucesso. agradeço a todos pela atenção. Resolvido!!!

Olá, Vou fazer este procedimento e respondo. obrigado pela atenção. Obs: No cliente, tentei emitir a NF-e em ambiente de Homologação e o problema persistiu. Obs II: No meu computador, tenho um certificado A1, o do cliente é A3. grato!

Olá, Só para constar, também colei uma cópia da pasta dos arquivos 'xsd' (cópia da que utilizo no meu computador), no computador do cliente e o problema persistiu. Por favor, se alguém puder me ajudar ficarei extremamente agradecido. Já estou nesta luta a algumas horas.

Olá, Procurei no forúm do ACBr e este foi o que melhor representou meu problema. A situação é a seguinte. Quando tento emitir uma NF-e utilizando o 'ACBrNFe', funciona normlamente, porém um dos clientes aqui da empresa é residente na BAHIA, lá é obrigatório informar o grupo 'autXML'. Então coloquei as seguintes linhas de código no meu projeto: begin with autXML.Add do begin CNPJCPF := sAutXML ; end ; end ; fiz alguns testes no meu computador, e a NF-e foi emitida normalmente (ambiente de Homologação). Já no cliente, no ambiente de Produção, quando ele tenta emitir a NF-e, ocorre a seguinte mensagem de erro: "O sistema não pode encontrar o caminho especificado." nenhum arquivo '.xml' referente à NF-e foi é gerado, ou seja, o problema é antes do envio. se eu tirar as linhas de código, mencionadas acima, a situação muda completamente. Quando o cliente tenta emitir a NF-e, ocorre a seguinte mensagem: " Ocorreu um erro ao tentar emitir NF-e. Mensagem de erro nota não confirmada 114. Rejeição: Não informado o grupo de autorização para UF que exige a identificação do escritório de contabilidade na nota fiscal, caso não possua, informar o CNPJ na SEFAZ BA 13.937.073/0001-56 validação a partir de 01/01/2016". ou seja, a NF-e é enviada porém é rejeitada, como era de se esperar. Alguém poderia me dar uma luz, já debugei a aplicação, e o problema sempre ocorre antes da validação, mesmo o path do schemas estando corrreto. Teste em outro computador do cliente e o problema persiste. Desde já agradeço pela atenção.

Olá, Consultei no Manual de orientação e concluí que não está havendo nenhuma inconsistência nas informações passadas. Peço pra que você tente gerar o arquivo '.xml' utilizando o acbrnfe_demo.exe ao invés de submeter o arquivo '.txt' no ACBrMonitor. Não uso o ACBrMonitor então evito fazer testes por ele. grato!