BigWings

Usando o arquivo .fr3 que anexei mais acima.

Anexe o XML.

Teste com este arquivo: DANFeNFCe.fr3 Não compreendi se você fez alteração...

Anexe o arquivo modificado para análise.

No caso do DANFE NFCe em Fast realmente a máscara está fixa no .fr3. Já no DANFE em ESCPOS está de acordo com a configuração das casas decimais (para quantidade inteira os decimais não são mostrados).

Para o DANFENFCEFR e layout depende do arquivo .fr3 usado e não exatamente do componente. O .fr3 mais atualizado de acordo com o manual é o DANFeNFCe4_20.fr3.

Não, o layout do DANFE NFCe é padronizado: http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=/xyXbAFZ71k=

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:

Veja:

O terceiro parâmetro no método enviar indica que você está usando o modo síncrono. No modo síncrono não é executado o método de consulta de recibo. Para capturar o cStat de retorno tente usar: cStatus := ACBrNFe1.WebServices.Enviar.cStat;

Para CRT = 1 você só pode destacar ICMS normal na nota quando usar o CSOSN 900. Para os outros CSOSN mesmo se você preencher vBC, pICMS e vICMS para o item da nota, o código do componente vai ignorar já que as tags não existem no layout da NFe. Por isso quando você preenche o valor nos totais da NFe e usa CSOSN diferente de 900 ocorre a diferença.

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.

O ACBrBoleto não faz os cálculos de juros e multa, nem mostra os mesmos na impressão do boleto como o banco geralmente faz na emissão da segunda via. Então a resposta é não. Hoje com a nova plataforma de cobrança em pleno vigor a emissão da segunda via não é mais necessária, o pagador pode fazer o pagamento do boleto em qualquer banco com o código de barras original.

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.