BigWings

Verifique a versão do firmware da impressora, pode ser preciso atualizar.

O DANFE em Fast usa o ClientDataset internamente. Esse problema parece ter relação com a falta da MIDAS.DLL nesse terminal, que o ClientDataset necessita, ou uma versão incorreta dessa DLL. Você pode tentar copiar a DLL para a pasta do executável, ou tentar inserir MidasLib no uses do .dpr do seu projeto.

A princípio deve manter estas características: https://www.projetoacbr.com.br/perguntas-frequentes/#sobre-os-fontes-do-acbr Só faltou dizer a que se refere esse novo "projeto", você quer dizer um novo componente?

Para o CTe-OS você deve usar ACBrCTe.WebServices.EnviaOS. Ou ACBrCTe.Enviar que já executa os métodos de assinatura, validação, envio de acordo com o modelo e impressão do DACTE.

- Atualize os fontes. - Use o componente ACBrNFeDANFCEFR.

Acredito ter identificado o problema. Enviei correção para o repositório, rev. 16470, favor atualizar os fontes e testar novamente.

Se a SEFAZ identificou a emissão como sendo de janeiro (por falta da hora de emissão e do fuso horário) a chave de acesso deveria iniciar em 291901... (Pode ser um erro do webservice, seria interessante reportar isso para a SEFAZ) Veja a chave retornada pelo webservice para a NFe: <chNFe>29190123108592000165550010000000801000000800</chNFe>

Falta informar a hora da emissão: <dhEmi>2019-02-01T00:00:00-02:00</dhEmi> Sendo a hora 00:00 e dependendo do fuso horário o webservice pode entender que a nota é referente ao mês de janeiro por isso a rejeição: <cStat>502</cStat><xMotivo>Rejeicao: Erro na Chave de Acesso - Campo Id nao corresponde a concatenacao dos campos correspondentes</xMotivo>

A mensagem de erro não mostra o motivo da rejeição. Configure o componente para gravar os arquivos de envio e retorno e anexe eles aqui para análise.

Você está fazendo a consulta do recibo explicitamente? O CTe-OS é emitido em modo síncrono, até onde sei não existe consulta de recibo pra ele.

Está usando o ACBrInstall_Trunk2.exe para compilar ou compilando manualmente?

O teu XML está validando normalmente aqui com os Schemas do ACBr...

Aparentemente sim, porque a consulta aqui funcionou normalmente.

Primeiro você precisa verificar se o CFOP informado na nota está de acordo com esse tipo de operação. Me parece que isso caracteriza venda interna, CFOP iniciando em 5, assim basta informar a tag idDest = doInterna para permitir informar esse CFOP para destinatário com endereço em outra UF. Em alguns casos basta informar, apenas o CNPJ do próprio emitente como transportador, como indica a observação da regra de validação:

Está informando a UF da placa do veículo? Houve alteração apenas na consulta da NFe e CTe pelos portais nacionais e das SEFAZ estaduais. Não houve alteração nesse sentido para a consulta via webservices.

Comente essa linha, você precisa dela pra usar LibXML2.

A validação indica que não espera o grupo infFretamento no XML. Sua pasta de Schemas está atualizada?

Está faltando informar o percentual de partilha, sem essa informação o componente ignora todo o grupo.

Já viu o demo do ACBrPosPrinter? Lá tem exemplo das tags com os tamanhos de fontes aceitos.

Em modo debug o Delphi vai mostrar a exceção, em runtime não, já que o try/except inibe isso, caso tivesse mostrado você teria a mensagem "Erro ao obter a resposta do webservice" na sua aplicação. O fato de entrar nessa rotina indica que o tratamento anterior funcionou, e essa ou outra rotina está gerando a mensagem na tela.

No caso de emitente CPF deve gerar tag CPF e não CNPJ. Veja se está passando o CPF com 11 dígitos e não 14.

De que campos está falando? Abrindo o arquivo *_2019.fr3, a banda com os dados de entrega continua lá.

Foi alterada no refactoring para ACBrNFeDANFEFR.MostraSetup.

Qual .fr3 está usando?