BigWings

Na minha interpretação desse trecho, significa: vProd = 121,95, vNF = 100,00 ==> vProd contém o valor do ICMS desonerado a ser subtraído ==> deve subtrair vProd = 100,00, vNF = 100,00 ==> vProd não contém o valor do ICMS desonerado, ou seja, já está considerando o abatimento ==> não deve subtrair A palavra CASO é onde entendi que pode ser feito da primeira forma. O resultado será o mesmo, de qualquer forma.

Na parte em que diz que foi considerada a exceção 3 da regra de validação.

Quando você subtrai o valor do ICMS desonerado precisa fazer o cálculo inverso pra saber o valor que o produto teria sem a desoneração, e informar no vProd. Digamos que uma mercadoria é precificada a R$ 100,00, com CST 40, nela o vendedor já está considerando a desoneração de 18% de ICMS. Subtraindo a desoneração do total da nota: vProd = 100,00 / (1 - 0,18) ==> 100,00 / 0,82 ==> 121,95 vICMSDesonerado := 21,95 vNF = 100,00 Não subtraindo a desoneração, precisa calcular apenas o vICMSDesonerado, e informar vProd e vNF = 100,00. Na minha interpretação da resolução, o correto é não subtrair, mas não proíbe expressamente fazer da primeira forma.

Sobre a TRetConsReciCTe, veja: A TRetConsStatServ ainda existe nos fontes, na unit pcnRetConsStatServ.pas.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

O ajuste sugerido pelo @Daniel Simoes foi aplicado no repositório. Favor atualizar novamente os fontes e testar.

Qual cidade/provedor? Já tentou informar o código do IBGE da cidade em vez do literal do nome?

O método DistribuicaoDFe não permite que o próprio emitente baixe o XML novamente. Apenas o destinatário, transportador e terceiros informados na tag autXML podem se utilizar do serviço para baixar o XML. O emitente vai receber pelo método DistribuicaoDFe os eventos emitidos pelo destinatário ou pelo fisco referentes as notas que emitiu, por exemplo, a manifestação do destinatário.

Favor anexar o XML para teste.

Deve ser informado o número, a série e a chave da nfe cancelada, além do código de situação e indicação de tipo de emissão própria ou terceiros. Os demais campos em branco. Se está informando dessa forma e tendo erro, favor mostrar qual erro está sendo mostrado.

Acredito que seja a NT 2016.002 v1.61.

Tem um tópico relacionado aqui: Como regra geral, ele deve ser somado, mas a regra de validação que verifica o valor total não se aplica caso seja uma nota de importação (CFOP iniciando em 3). É bom conversar com um contador pra saber o cálculo correto e se pode haver variação de caso pra caso, UF pra UF, etc...

Habilitou na conta do email a opção de permitir acesso a aplicativos menos seguros? https://support.google.com/accounts/answer/6010255 Sem essa configuração o gmail não aceita.

Essa propriedade não existe mais, já que a geração do QrCode é obrigatória. O QrCode é gerado automaticamente no XML assim que ele é assinado.

Provavelmente algum erro na sua rotina. Veja se não está chamando novamente o método NotasFiscais.Add ao preencher o campo dhCont.

Pode anexar os dois arquivos?

Geralmente isso indica conflito de atualização do svn não resolvidas por você ter modificações locais. Use a opção "Resolve" do Tortoise, ou baixe novamente os fontes em uma nova pasta.

Até agora não vi ninguém interessado em implementar. Quer contribuir?

Como está informando a configuração das margens? Foi feita uma alteração recente no componente, agora as margens devem ser informadas em milímetros, antes eram em centímetros.

Precisa alterar a configuração: ACBrNFe1.Configuracoes.Geral.FormaEmissao := teSVCRS; E na geração do XML informar o tipo de emissão: Ide.tpEmis := teSVCRS;

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Tem o XML com o protocolo de autorização? Se consultar o CTe no portal da SEFAZ do emitente ele consta como autorizado? Existe regra de validação obrigatória para o MDFe para não permitir incluir CTe inexistente, exceto para MDFe emitido em contingência. A consulta é feita na SEFAZ e não no ambiente nacional:

Da data de emissão da nota, tag dEmi. Porém, algumas SEFAZ fazem confusão nas viradas de meses com relação à hora de emissão, se for informado 00:00:00 por diferença de fuso horário interpretam que é do mês anterior. Veja se está informando a hora de emissão.

Nesse caso estaria imprimindo no DANFE informação que não consta no XML (cProd diferente), isso vai contra o que é exigido pelo MOC.