BigWings

Por ser um grupo opcional, ele só será gerado caso seja informado valor diferente de zero para um dos campos. A questão é: se a UF está exigindo o preenchimento do grupo, é correto gerar com valores zerados?

A leitura correta do XML depende da configuração do provedor no componente. Então antes de importar um XML emitido por terceiros é preciso saber os dados do prestador, como a cidade do mesmo. Muitos XML de NFSe não contém todos os dados do prestador, importar um XML de serviços para entrada pode realmente não ser vantajoso.

A rejeição 938 refere-se a falta de preenchimento do grupo das tags vBCSTRet, pST, vICMSSubstituto e vICMSSTRet. Aparentemente a SEFAZ ainda não implementou a mensagem de erro correspondente.

Muito provavelmente os fontes do ACBr não estão atualizados no D2007, já que ainda está gerando as tags pST e vICMSSubstituto mesmo com os valores zerados. Esqueça o arquivo de schema leiauteNFe_v4.00-homologacao.xsd. Ele não é mais necessário após a NT 2018.005 v1.20 que tornou as tags opcionais.

Se você tem o retorno do envio do evento de cancelamento por substituição, protocolado, referenciando a NFCe emitida em contingência, o processo está concluído. Quanto à NFCe não aparecer como cancelada no portal da SEFAZ pode ser que ainda não tenham adequado a página de consulta ao novo tipo de cancelamento. Entre com contato com a SEFAZ e reporte o problema.

Pode anexar os arquivos XML de envio e retorno?

Como você informa a NFCe substituta sendo que só vai transmitir após o cancelamento? O processo esperado pela SEFAZ é: 1 - Emissão da NFCe nº 100 no modo normal, houve falha de comunicação no momento da transmissão. 2 - Automaticamente deve ser emitida a NFCe nº 101 com os mesmos dados, em contingência off-line e marcar a NFCe nº 100 para cancelamento ou inutilização. 3 - Ao retornar a comunicação deve-se: 3.1 - Transmitir a NFCe nº 101 emitida em contingência; 3.2 - Consultar a NFCe nº 100; 3.3 - Caso a NFCe nº 100 não tenha sido autorizada, fazer a inutilização da mesma; 3.4 - Caso a NFCe nº 100 tenha sido autorizada, fazer o cancelamento da mesma por substituição, informando a chave da NFCe nº 101 como NFCe substituta. A rejeição tem haver com o fato de a chave informada como NFCe substituta não ter sido emitida em contingência off-line. Adendo: As numerações do meu exemplo são das Notas Técnicas atuais, há legislação pendente de NT que determina uso de série diferente na emissão da NFC-e em contingência off-line:

Você não chama ela, é uma configuração do componente, caso True ela evita que um XML seja atualizado com o protocolo de autorização de outra nota, por exemplo. ACBrNFe1.Configuracoes.Geral.ValidarDigest := True; ACBrNFe1.Consultar; Caso o DigestValue da assinatura não seja o mesmo do DigestValue do protocolo de autorização, o XML não será atualizado.

Usando o certificado do próprio emitente, não. O que você pode fazer é carregar no componente o mesmo XML que foi usado na tentativa de transmissão, ou gerar ele novamente com os dados da venda, assinar novamente, e executar o método ACBrNFe.Consultar. Você pode usar a propriedade ValidarDigest para garantir que os dados do XML carregado estejam conforme o que foi transmitido. Caso esteja tudo certo o componente vai atualizar o XML com o protocolo de autorização.

Você pode fazer a impressão do evento de alteração de condutor e anexar ao MDFe.

Qual componente DACTE está usando?

Veja se a propriedade MostraSetup do componente DANFE está marcada. Ela por padrão é False.

Você informou que está emitindo um CTe no modal 02 (Aéreo): <modal>02</modal> Mas incluiu na seção infModal o trecho de XML de um modal Rodoviário. Por isso o erro.

A NFCe substituta foi emitida em contingência off-line?

Está usando a versão comercial do FastReport ou a básica que vem junto ao Delphi? Se estiver usando a básica tente os arquivos *BASIC* da pasta Obsoletos.

Isso provavelmente não vai funcionar já que o método PreparedReport executa internamente o PrepareReport do relatório. Se no seu DANFE essa variável é necessária o método vai falhar e retornar nil.

Mesmo após o prazo de 24 horas o XML será acatado com o cStat 150 (Autorizado fora do prazo). Nada mais precisa ser feito, o único porém é que a SEFAZ pode vir a pedir explicações pelo atraso.

Experimente marcar a opção ACBrNFe1.Configuracoes.Arquivos.SalvarApenasNFeProcessadas.

Tive o mesmo erro aqui, em tempo de design ao clicar na aba testes ocorre a exceção. Mesma versão do Lazarus do @jcdatrindade. Consegui isolar o erro no componente mResposta, removendo o trecho a seguir, ele não ocorre mais. Não sei a que se refere esta propriedade, espero que ajude.

Se você abriu esse pacote pelo Delphi e salvou ou compilou pode ser que ele tenha acrescentado as dependências sozinho. Faça um revert da pasta ACBr\Pacotes inteira e tente reinstalar.

Já baixou o Guia Prático do SPED? Se o seu problema é em relação ao layout creio que ele tem tudo que precisa. http://sped.rfb.gov.br/arquivo/show/2761

Em operação com não contribuinte são aceitos apenas os CST 00, 20, 40, 41 e 60. Nenhum deles permite destaque de ICMS-ST ou FCP-ST.

Isso deve funcionar desde que o XML esteja assinado.

Depois de atualizar os fontes você executou o ACBrInstall_Trunk2.exe para reinstalar os componentes, marcando a opção de apagar arquivos antigos?

Tem mais de uma versão do Fast instalada?