BigWings

Pela validação do XML, a tag cServTribMun deve ter 20 caracteres, o conteúdo informado "00120200" tem apenas 8.

Não tinha testado o código, está sobrando um ) antes do then ali. Mesmo em homologação, deve sair a mensagem de contingência, está gerando o XML com tpEmiss = 9? Pra saber se foi transmitido você deve testar o cStat após o envio. O digestValue deve se manter o mesmo, desde que não faça alteração no XML. Está mudando pra Offline antes de tentar enviar a nota? Lembre do que diz o manual de contingência, caso tente enviar, não pode simplesmente alterar a mesma nota pra offline e sim gerar uma nova. Também tem que trocar o tipo de emissão na nota, se não tentou enviar, é claro. ACBrNFe1.NotasFiscais.Items[0].NFe.Ide.tpEmis := teOffline; Assim você está gerando duas vias do estabelecimento. Chame o Imprimir, troque o ViaConsumidor, depois chame o Imprimir novamente. Você pode preencher a propriedade "Impressora" do componente DANFCe com o nome da impressora pra sair automaticamente. Para impressora conectada na porta serial, você pode usar o ACBrNFCeDANFeESCPOS e imprimir diretamente na porta.

Veja que o post do Italo é antigo, de lá pra cá houve mudanças nos procedimentos exigidos pela SEFAZ, conforme manual postado pelo Ricardo ali em cima. Agora não é preciso fazer a consulta imediatamente, em caso de erro de conexão, você marca a NFCe para tratar depois, e gera uma nova, em contingência off-line. Eu tinha entendido que você não queria tratar erro de conexão, e sim testar ela antes de enviar, por isso mostrei a dica do InternetCheckConnection. Quanto ao evento OnTransmitError, nunca usei, não posso ajudar. Eu faço o tratamento do exception do Enviar, pra verificar se houve erro de conexão, conforme esta dica: Exemplo: try ACBrNFe1.Enviar(nLote, False, True); except on E: Exception do begin if (pos('12007 - ', UpperCase(E.Message)) > 0) or // erro de conexão (pos('12002 - ', UpperCase(E.Message)) > 0) or // timeout (pos('12029 - ', UpperCase(E.Message)) > 0) or // limite de tempo de conexão (pos('ERRO HTTP:', UpperCase(E.Message)) > 0) or // erro http genérico (pos('ERRO NAO CATALOGADO', UpperCase(E.Message)) > 0)) then // erros de tratamento do webservice begin // Enviar NFC-e offline end else raise; end; end;

Leia os seguintes tópicos:

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.