BigWings

A versão do documento fiscal 2.00 foi desativada em 2015. Mude para 3.10.

Você sabe que apenas o MS disponibilizou as URL de homologação, certo?

Não precisa digitar o número de série, basta clicar no botão ao lado e selecionar. E esse erro não tem nada a ver com o certificado, mostre como está a configuração de modelo e versão do documento fiscal e UF do webservice.

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

Boa tarde, A NT 2017/002 prorrogou o prazo de vigência do MDFe 1.0 para 02/10/2017. https://mdfe-portal.sefaz.rs.gov.br/Site/Documentos#

Provavelmente houve alteração do provedor do serviço de NFSe para a cidade. Precisa descobrir qual, verificar se há suporte no componente e fazer a alteração no arquivo Cidades.ini.

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.

Por acaso está alterando a versão do layout para 4.00 em algum momento?

No arquivo ISSNet.ini consta o endereço de homologação: [URL_H] RecepcaoLoteRPS=http://www.issnetonline.com.br/webserviceabrasf/homologacao/servicos.asmx Teste alterando esse endereço.

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: