BigWings

O certificado deve estar instalado no Windows. Ele deve aparecer na tela Opções de Internet - Conteúdo - Certificados, na aba Pessoal.

Certificado A1 ou A3?

Não, isso é normal, não deve fazer diferença. São todos os forms que são lentos pra abrir ou algum form específico?

Tenho o XE5. Esse tempo aí não é normal. Pra termos um parâmetros, quanto tempo demora pra abrir o Form lá do QC no XE6 e 2007?

Só achei isso. O tempo é em minutos mesmo?

5 a 6 minutos? Achei um QC aberto sobre algo assim desde o XE3: http://qc.embarcadero.com/wc/qcmain.aspx?d=116169 Tente fazer o sugerido e desativar o LiveBindings do projeto pra ver se melhora...

As URL dos webservices foram alterados no ACBrNFeServicos.ini, para utilizar a SVRS, de acordo com este comunicado: http://www.pi.gov.br/materia/sefaz/sefaz-alerta-contribuintes-para-mudanca-no-autorizador-de-emissao-da-nf-e-882.html Entretanto, essa mudança deveria ser feita apenas a partir do dia 31/05/2017. Substitua os arquivos em anexo e tente novamente. ACBrNFeServicos.ini ACBrNFeServicos.res

Informe o passo a passo executado no demo onde ocorre o problema.

Cada chamada ao DistribuicaoDFe vai trazer no máximo 50 documentos, segundo a NT 2014/002, você armazena o NSU retornado e verifica o cStat, caso seja 138, chama novamente o DistribuicaoDFe passando o NSU retornado na última consulta, até que o cStat seja 137. Veja o .txt de exemplo na pasta do demo do ACBr. Sim, o ator é o interessado no documento, pode ser o remetente, destinatário, transportador, terceiro identificado na tag <autXML>...

Basta informar a UF do emitente na guia WebService do demo. Qual UF está tentando?

Se ainda está usando o serviço ConsultaNFeDest, troque logo para DistribuicaoDFe, já que o primeiro será desativado no final do mês. No DistribuicaoDFe você testa o cStat 137 ou 138 para saber se há mais documentos a localizar, e usa o número do último NSU para continuar pesquisando a partir da última consulta.

Para não aparecer as mensagens de comunicação com o WebService, configure a propriedade ACBrNFe1.Configuracoes.WebServices.Visualizar. Para mensagens de rejeição/validação você trata num try..except. Você pode capturar o XML pela propriedade ACBrNFe1.NotasFiscais.Items[0].XMLAssinado, ou pelo arquivo gravado pelo ACBr caso a propriedade ACBrNFe1.Configuracoes.Arquivos.Salvar esteja True. E não deve alterar nada no XML, apenas carregar e enviar. Apenas em caso de rejeição no envio você pode fazer alteração pra corrigir a rejeição e enviar novamente.

Bom dia, Os serviços que serão desativados serão o ConsultaNFeDest e DownloadNF. No lugar deles você deve usar o DistribuicaoDFe. Tem vários tópicos sobre isso aqui no fórum, e um .txt com código de exemplo de uso na pasta do Demo do ACBr. Os serviços de manifestação do destinatário continuarão funcionando da mesma maneira.

Bom dia, O layout de carta de correção para CTe é diferente do layout para NFe. No CTe você deve informar cada correção nas tags grupoAlterado, campoAlterado, e nroItemAlterado, sendo esses itens campos definidos no layout, exemplo: ACBrCTe1.EventoCTe.Evento.Clear; ACBrCTe1.EventoCTe.idLote := idLote; with ACBrCTe1.EventoCTe.Evento.Add do begin InfEvento.chCTe := Chave; infEvento.cOrgao := StrToInt(Copy(Chave, 1, 2)); infEvento.CNPJ := Copy(Chave, 7, 14); infEvento.dhEvento := Now; infEvento.tpEvento := teCCe; infEvento.nSeqEvento := nSequencial; // de 1 a 20 with CTE.EventoCTe.Evento.Items[0].InfEvento.detEvento.infCorrecao.Add do begin grupoAlterado := 'seg'; // Informações do seguro campoAlterado := 'nApol'; // Numero da apólice nroItemAlterado := 2; // referente ao segundo item no grupo 'seg', só informar se o grupo aceitar mais de um item valorAlterado := '1234567890'; // novo valor do campo end; with CTE.EventoCTe.Evento.Items[0].InfEvento.detEvento.infCorrecao.Add do begin grupoAlterado := 'seg'; // Informações do seguro campoAlterado := 'nAver'; // Numero da averbação nroItemAlterado := 2; valorAlterado := '0987654321'; end; { Continuar incluindo as correções para cada campo } end; ACBrCTe1.EnviarEvento(idLote); nProt := ACBrCTe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.nProt;

Se a NFC-e foi emitida em contingência no mês de Abril, ao transmitir ela deve continuar com a data de emissão de Abril. A chave só vai alterar se a data de emissão também for alterada. Alterando a data você terá problema de sequência de numeração. E alterando a chave, o consumidor que recebeu a NFC-e em contingência nunca conseguirá consultar a nota. A NFC-e emitida em contingência deve ser transmitida da forma como foi gerada, só é permitido alteração caso haja rejeição por dados incorretos.

O mês e ano na chave são referentes à data de emissão. Esse é o prazo pela legislação, mas os estados podem a seu critério acatar NFCe com prazos maiores, pelo cStat 150 - Autorização fora do prazo.

Está usando os Schemas da pasta do ACBr?

Você deve ter alterações locais nos fontes, revise e faça um revert pelo svn. No repositório essas linhas estão comentadas:

Verifique pelo gerenciador do token se a chave privada ainda se encontra no cartão. Caso contrário, terá que emitir outro certificado. Já viu este tópico?

Certificado A3?

Fiz uma busca nos fontes do ACBr e todas as chamadas a pasta c:\temp estão comentadas, ou desativadas por diretiva, então veja se não tem alterações locais no seu fonte. A única referência não comentada está na unit ACBrTaxaDolar.pas, você usa este componente? function TACBrTaxaDolar.Consulta: Boolean; var Buffer : String ; begin Self.HTTPGet('http://www4.bcb.gov.br/pec/taxas/batch/taxas.asp'); Buffer := StripHTML( Self.RespHTTP.Text ); //DEBUG WriteToTXT( 'c:\temp\bobo.txt', Buffer, False) [...] Segue correção. ACBrTaxaDolar.pas

Pela validação do XML, a tag cServTribMun deve ter 20 caracteres, o conteúdo informado "00120200" tem apenas 8.

Não tinha testado o código, está sobrando um ) antes do then ali. Mesmo em homologação, deve sair a mensagem de contingência, está gerando o XML com tpEmiss = 9? Pra saber se foi transmitido você deve testar o cStat após o envio. O digestValue deve se manter o mesmo, desde que não faça alteração no XML. Está mudando pra Offline antes de tentar enviar a nota? Lembre do que diz o manual de contingência, caso tente enviar, não pode simplesmente alterar a mesma nota pra offline e sim gerar uma nova. Também tem que trocar o tipo de emissão na nota, se não tentou enviar, é claro. ACBrNFe1.NotasFiscais.Items[0].NFe.Ide.tpEmis := teOffline; Assim você está gerando duas vias do estabelecimento. Chame o Imprimir, troque o ViaConsumidor, depois chame o Imprimir novamente. Você pode preencher a propriedade "Impressora" do componente DANFCe com o nome da impressora pra sair automaticamente. Para impressora conectada na porta serial, você pode usar o ACBrNFCeDANFeESCPOS e imprimir diretamente na porta.

Veja que o post do Italo é antigo, de lá pra cá houve mudanças nos procedimentos exigidos pela SEFAZ, conforme manual postado pelo Ricardo ali em cima. Agora não é preciso fazer a consulta imediatamente, em caso de erro de conexão, você marca a NFCe para tratar depois, e gera uma nova, em contingência off-line. Eu tinha entendido que você não queria tratar erro de conexão, e sim testar ela antes de enviar, por isso mostrei a dica do InternetCheckConnection. Quanto ao evento OnTransmitError, nunca usei, não posso ajudar. Eu faço o tratamento do exception do Enviar, pra verificar se houve erro de conexão, conforme esta dica: Exemplo: try ACBrNFe1.Enviar(nLote, False, True); except on E: Exception do begin if (pos('12007 - ', UpperCase(E.Message)) > 0) or // erro de conexão (pos('12002 - ', UpperCase(E.Message)) > 0) or // timeout (pos('12029 - ', UpperCase(E.Message)) > 0) or // limite de tempo de conexão (pos('ERRO HTTP:', UpperCase(E.Message)) > 0) or // erro http genérico (pos('ERRO NAO CATALOGADO', UpperCase(E.Message)) > 0)) then // erros de tratamento do webservice begin // Enviar NFC-e offline end else raise; end; end;

Leia os seguintes tópicos: