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.

Caso você não use pagamento integrado (TEF) na aplicação, pode informar apenas a tag tpIntegra = 2. with pag.Add do begin ... tpIntegra := tiPagNaoIntegrado; Os demais dados devem ser informados caso tpIntegra seja 1.

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.

Se você olhar a informação do portal da NFe: RR está entre os estados que usam a SVRS como autorizador NFe mas não implementam o método de consulta de cadastro. Então não é possível fazer a consulta do cadastro para AL, AP, DF, ES, PI, RJ, RO, RR, SE ou TO.

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.

O cancelamento por substituição pode ser feito em até 168 horas.

Tem erro no valor informado para a tag nSeqEvento: nSeqEvento=44 Para a carta de correção o nSeqEvento deve ser de 1 a 20, na sequencia de correções feitas para a mesma NFe. Lembrando que as correções não são cumulativas, a correção que vale é apenas a última enviada.

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

Você precisa comparar a chave da NFe que está enviando com a chave da NFe retornada na mensagem de rejeição. No caso a NFe que está enviando tem a chave: 29190415914452000237650550000010479000010477 Onde ocorreu a rejeição de duplicidade com diferença na chave, sendo a chave já autorizada: 29190415914452000237650550000010471000010471 A diferença é o tipo de emissão da NFe, ela foi autorizada no tipo de emissão normal e você está tentando enviar a mesma numeração com tipo de emissão em contingência off-line. Provavelmente tem algo errado na sua rotina para ter gerado duas chaves diferentes para a mesma numeração, veja este tópico para dicas de como tratar a contingência: