BigWings

Testou novamente na versão antiga? Improvável que tenha algo a haver com a versão do ACBr já que essa mensagem vem da SEFAZ e qualquer software emissor geraria o mesmo erro. Verifique novamente se não houve algum problema com o cadastramento do emitente como emissor de MDFe na SEFAZ.

Continue no outro tópico então.

A empresa emitente já foi habilitada pela SEFAZ a emissão do MDFe?

Você vai usar o ACBrMonitorPlus ou o componente Delphi/Lazarus?

Emitir com série 0 significa que não vai usar nenhuma outra série para aquele CNPJ. Ou seja, usando 0, teria que usar 0 sempre e nunca mudar pra 1, ou qualquer outra, mesmo esgotando a numeração.

Alterar a série não é possível, de qualquer forma ela terá que ser contabilizada, mesmo sendo feito a anulação, substituição ou mesmo cancelamento... Veja este link para procedimentos para anulação ou substituição: http://www.ophos.com.br/app/publicacoes/detalhe/ct-e-de-anulacao-e-substituicao/

Na chave já consta o ano e mês de emissão. Para saber a data, somente com o XML ou via consulta pública na página da SEFAZ.

Aqui você gerou adicionou uma nova nota no componente. with ACBrNFe1.NotasFiscais.Add.NFe do E dentro dessa nova nota acrescentou um pagamento: with pag.Add do Então você tem duas notas no componente, a primeira sem informação de pagamentos, e a segunda apenas com o pagamento, por isso o erro de UF vazia.

Não.

Depende qual webservice está retornando o erro. O XML enviado ao webservice de recepção também precisa estar na estrutura <enviCTe ...>, conforme o exemplo do manual: <?xml version="1.0" encoding="UTF-8"?> <enviCTe xmlns="http://www.portalfiscal.inf.br/cte" versao="2.00"> <idLote>200602220000001</idLote> <CTe xmlns="http://www.portalfiscal.inf.br/cte"> <infCte Id="CTe41100600242640000108570000000446060832911308" versao="2.00"> ... <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> ... </CTe> <CTe xmlns="http://www.portalfiscal.inf.br/cte"> <infCte Id="CTe41100600242640000108570000000446060832911308" versao="2.00"> ... <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> </CTe> </enviCTe>

Parece instalação incorreta do SafeSign. Entre em contato com o suporte da certificadora.

Se não me engano apenas para NFCe o grupo de PIS e COFINS pode ser suprimido do XML, para isso informe o CST 99 na geração.

O ACBr que gerou esse arquivo? Olhando por cima, falta o cabeçalho do XML: <?xml version="1.0" encoding="UTF-8"?>

Linhas mesmo, o componente chama o Imprimir cada vez que a quantidade de linhas a imprimir chega nesse valor, reduzindo o tempo de resposta.

O campo idDest – “Identificador de local de destino da operação” deve ser igual a 1 – “Operação interna”;O campo indFinal – “Indica operação com Consumidor final” deve ser igual a 1 – “Consumidor final;”O campo modFrete – “Modalidade do frete” deve ser igual a 9 – “Modalidade do frete”.

Tópico movido para um local mais apropriado. Sugiro que entre em contato com a empresa e informe o erro na emissão da nota para que façam a emissão da nota complementar. Caso se recusem e você já tenha feito o pagamento, é fraude fiscal, e sim, pode entrar com processo no Procon, ou denuncie diretamente para a SEFAZ.

Está usando o ACBr pra gerar o XML? Poste como anexo para análise.

Tente configurar a propriedade LinhasBuffer do ACBrPosPrinter.

Houve uma correção quanto a esse assunto, uns dias atrás. Seus fontes estão atualizados?

As tags indFinal e modFrete estão inválidas pra esse tipo de operação, veja o post do André acima.

O demo compilado em Lazarus valida a nota sem problema. Já o compilado em Delphi, não. O problema no arquivo, que não passa na validação, é a codificação do arquivo, que está em "UTF-8 No Mark", e contém caractere 'acentuado', a unidade "PÇ". Só consegui validar o arquivo após alterar a codificação para Ansi, em um editor de texto. Veja na sua versão do Delphi como fazer a conversão de codificação dos XML de entrada para Ansi.

Não faz.

O erro está na geração das casas decimais da tag pICMSInter. No seu XML rejeitado: <pICMSInter>7.0000</pICMSInter> No XML autorizado: <pICMSInter>7.00</pICMSInter> Consultando os fontes, vejo que essa correção foi feita em 24/11/2015. Não verifiquei diferença na geração do XML em produção e homologação, então: - Qual versão do ACBrMonitorPlus está usando? - Os testes em produção e homologação foram feitos na mesma versão do ACBrMonitorPlus?

Você disse que baixou o trunk2, os exemplos estão na pasta ACBr\Exemplos\ACBrDFe\ACBrNFe. Se conseguir reproduzir o problema usando ele, poste o passo a passo aqui.

Não uso o ACBrMonitorPlus, testei pelo demo, sem problema algum.