BigWings

Bom dia, Informe a chave do CFe na mesma tag onde referencia NFe: ACBrNFe1.NotasFiscais.Items[0].NFe.Ide.NFref.Add.refNFe := <chCFe>;

Veja esta solução:

No caso do Delphi é só mandar ignorar e salvar.

Não consegui replicar o erro, chamando na sequência GravarXML, Clear, LoadFromFile, Enviar, o MDFe foi autorizado sem erros. Use o demo do ACBr e gere um caso de teste onde o problema ocorra, informando as configurações e alterações necessárias.

Como o problema são os espaços em branco no XML, continue no outro tópico, vou fechar este.

Muitos espaços em branco mesmo. Esse XML foi gerado apenas chamando o comando GravarXML?

Poste o XML gravado por este comando.

Tópico movido para fórum mais adequado. Até onde sei, não existe CST de 4 dígitos. Lembro de um decreto/ato/normativa que incluía um dígito no CST mas ainda não está em vigor.

Bom dia, Toda a documentação sobre a NFe você encontra no portal nacional, https://www.nfe.fazenda.gov.br, na seção Documentos.

No código do ACBr a UF do veículo sempre é gerada, então provavelmente é algo no seu código. Coloque um breakpoint logo antes de enviar o MDFe pra ver se o conteúdo da tag ACBrMDFe1.Manifestos.Items[0].MDFe.Rodo.veicTracao.UF está preenchido, provavelmente você está limpando o campo em algum momento.

Já testou o certificado pra saber se a chave privada está intacta?

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.

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.

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.