Jump to content
Notícias do ACBr

click.png

click.png

click.png

click.png

click.png

click.png

clube mobile


Cursos grátis para toda base ACBr
+ Promoção Clube Mobile para o ACBr Pro

Saiba mais

adriano santos

click.png

click.png

click.png

click.png

click.png

click.png

Jonatas de Alencar Alves

Membros
  • Content Count

    37
  • Joined

  • Last visited

  • Days Won

    1

Jonatas de Alencar Alves last won the day on January 9 2018

Jonatas de Alencar Alves had the most liked content!

Community Reputation

10 Good

About Jonatas de Alencar Alves

  • Rank
    Membro

Profile Information

  • Sexo
    Masculino
  • Location
    São Paulo - SP

Recent Profile Visitors

778 profile views
  1. 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 sej
  2. 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!
  3. 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é+
  4. 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 ; A
  5. 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 co
  6. 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!
  7. 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!
  8. 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!
  9. 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 preenche
  10. 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!
  11. 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
  12. 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é ago
  13. 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
  14. 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!
  15. 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:
×
×
  • Create New...