BigWings

Aparentemente o que está errado é o código de tributação do município. Já consultou o manual ou a prefeitura?

Algumas razões possíveis: - Não foi compilado o ACBrNFeServicos.res depois de alterar o ACBrNFeServicos.ini; - O compilador encontrou um ACBrNFeServicos.res desatualizado e usou ele em vez do correto; - Existe um arquivo ACBrNFeServicos.ini desatualizado no diretório da aplicação

Não existe mais frete por conta do emitente, desde a NFe 4.00.

Tópico dividido de: Essa é a URL que consta no ACBrNFeServicos.ini, provavelmente o seu arquivo está desatualizado.

Tanto o DistribuicaoDFePorUltNSU, DistribuicaoDFePorNSU ou DistribuicaoDFePorChaveNFe se utilizam do mesmo webservice, mesma URL de acesso, então se o ambiente nacional estiver com problemas, provavelmente afetará todos esses serviços.

3.2 - Não faça "bump" de forma excessiva (postar simplesmente para que um tópico vá para o topo da lista). Isso é considerado flooding. Favor leia as regras do fórum. 3.1 - Não faça flooding - Inundar o fórum com posts repetidos, com a mesma dúvida ou as mesmas palavras é chamado de flooding. Isso é proibido. Apenas um post feito no lugar certo é suficiente. Pesquise antes de postar, talvez sua dúvida já está respondida em outro post. Favor leia as regras do fórum.

Obrigado pela contribuição. Entretanto, veja que já existe propriedade no componente DANFE para não imprimir dados de detalhamento específico para armamento, combustíveis, medicamentos e veículos, com opção individual de tags a imprimir. Se não quiser imprimir dados de veículos, por exemplo, posso fazer: ACBrNFeDANFeRL1.DetVeiculos := []; A nova propriedade então é redundante. Não existe propriedade desse tipo para o grupo Rastro, o ideal seria seguir esse padrão.

Após o envio da manifestação do destinatário é gerado um novo NSU com a NFe completa. Então você pode: - Continuar consultando por NSU até encontrar o NSU com o XML completo da NFe; - Usar o método DistribuicaoDFePorChaveNFe informando a chave de acesso.

Leia o manual de contingência off-line da NFCe. http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=YbZEjEHCuHQ= Caso você tente enviar uma NFCe no modo normal e haja falha de comunicação, você já deve emitir uma segunda NFCe em contingência, e marcar a primeira para cancelamento ou inutilização. A NT 2018.004 implantou o cancelamento por substituição que valida o conteúdo de ambas as notas para garantir que sejam referentes à mesma venda, estende o prazo do cancelamento por substituição para 168 horas, e reduz o cancelamento normal para 30 minutos. No cancelamento por substituição você deve informar a chave da NFCe emitida em contingência que acoberta a NFCe sendo cancelada. A única diferença é que hoje a série da NFCe em contingência não é reservada, então você pode ter NFCe série 1 número 20 em modo normal, e NFCe série 1 número 21 em contingência off-line. Com a reserva da série, você terá NFCe série 1 número 20 em modo normal, e NFCe série 890 número 1 em contingência, por exemplo.

Sempre que iniciar uma série diferente a numeração deve reiniciar do 1. Que saiba não houve nenhuma orientação em contrário no caso da série reservada para contingência off-line.

Separei o tópico por se tratar de assunto diferente. Tópico original: Evite colar código como corpo da mensagem, anexe os arquivos modificados.

Pela chave informada na tag chNFeRef é possível determinar o tpEmis da NFCe referenciada, já que a tag compõe a chave de acesso. Então se você informar uma chave de uma NFCe que não foi emitida em contingência off-line terá a rejeição. No caso essa NFCe foi emitida no modo normal.

Com a chave e protocolo de autorização você pode fazer o cancelamento. No portal do MDFe você pode baixar o XML usando a chave (necessita de certificado digital). https://dfe-portal.sefazvirtual.rs.gov.br/MDFESSL/DownloadXMLDFe

Após testes notei que o problema ainda acontecia. Enviei ajuste para o arquivo tiposGeralCTe_3.00.xsd, rev. 17022. Quem estiver com o erro favor atualizar os fontes e testar novamente.

Me referia à rejeição e não ao erro de validação, para esse caso você deve informar a IE correta do remetente. Para o erro de validação, verifique a sua pasta de Schemas se está atualizada conforme indicação do Italo. O arquivo tiposGeralCTe_3.00.xsd da pasta de Schemas do ACBr já contempla um ajuste para funcionar com a libxml2.dll, caso você use os Schemas oficiais com a xsLibXML2 ou xsXmlsSec pode ter esse erro mesmo.

Geralmente essa rejeição indica que o remetente/destinatário/etc é contribuinte ICMS e tem IE, assim não aceita informar como ISENTO.

O método Det.Add é o que cria o item no componente, então essa linha tem que estar dentro do loop.

Para configurar o componente para gerar o XML na versão 4.00: ACBrNFe1.Configuracoes.Geral.VersaoDF := ve400; Se estiver gerando NFCe precisa ainda configurar a versão do QR-Code: ACBrNFe1.Configuracoes.Geral.VersaoQrCode := veqr200; Estude o demo do componente, na pasta ACBr\Exemplos\ACBrDFe\ACBrNFe, certeza que vai ajudar nas suas dúvidas.

Verifique o valor informado para a tag tpEmis. No seu XML está: <tpEmis>2</tpEmis> É o tpEmis que compõe a chave e não o tpAmb.

1.2.0.59? O manual em formato .chm deve ser o mesmo do manual online, eles tem a mesma fonte.

Uma URL de homologação no grupo de produção? De qualquer forma, a URL atual do arquivo é: URL-ConsultaNFCe_2.00=www.sefaz.es.gov.br/nfce/consulta Foi corrigida por alterações recentes no webservice da SVRS que começou a validar a URL de consulta. Você chegou a alterar o arquivo ACBrNFeServicos.ini e fez testes pra saber se a NFCe é autorizada?

Se foi retornado o resumo da NFe, o destinatário é o CNPJ informado no pedido. Para os outros interessados, inclusive terceiros constantes na tag autXML, não é retornado resumo, mas o XML completo da nota.

Analisando o cabeçalho do XML de retorno: <resNFe xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" versao="1.35" xmlns="http://www.portalfiscal.inf.br/nfe"> Está sendo retornado na versão 1.35. Isso não é usual se você estiver usando ACBr com os Schemas disponibilizados pelo projeto NFe e constantes na pasta Schemas do ACBr, que está na versão 1.01. Essa versão 1.35 é usada pelo aplicativo gratuito de manifestação da SEFAZ-SP, ela não é pública e não tem documentação disponível pra ela, por isso não foi incluído no componente. Um usuário do fórum conseguiu via engenharia reversa esses Schemas, conforme post abaixo: Se você tiver esses arquivos da versão 1.35 na sua pasta de Schemas, o ACBr vai gerar nessa versão, e vai retornar o cSitConf, mas o componente não encapsula essa tag como propriedade. Você também perderá funcionalidade, como o método DistribuicaoDFePorChaveNFe que deixará de funcionar nessa versão dos Schemas.

Estranho... pode anexar o XML? E também esse arquivo foi obtido via ACBr ou via aplicativo gratuito da SEFAZ?

Essa tag era do serviço antigo de consultar notas destinadas NFeConsultaDest, já desativado pela SEFAZ e substituído pelo DistribuicaoDFe pela NT 2014.002. O serviço também já foi removido do componente.