BigWings

Você pode usar o visualizador que a Caixa disponibiliza. http://www.caixa.gov.br/empresa/pagamentos-recebimentos/recebimentos/nova-cobranca-bancaria/Paginas/default.aspx Pelo que vi esse campo não é mesmo disponibilizado no retorno. Se você quer saber a data do pagamento do boleto o correto é usar DataOcorrencia conforme o Felipe sugeriu.

Improvável, o meu é o mesmo do repositório. Faça o mesmo teste com o demo. Verifique também como está configurando a propriedade "ExibeInforAdicProduto" do componente, ela foi alterada no refactoring.

30/12/1899 é data em branco, valor 0 no tipo TDateTime. Significa que a data da baixa não está sendo retornada ou capturada. Veja no arquivo de retorno se a informação existe.

Fiz teste com o demo "Delphi DANFE FR" e exibiu normalmente a informação adicional do segundo item. Está com os fontes atualizados?

Pode anexar o XML?

Subi as alterações para o repositório. Favor atualizar os fontes e efetuar os testes.

Você vai mostrar essas tags em campos próprios no DANFE? A instrução atual é informar eles nas informações complementares.

A diferença nas imagens está na modalidade da conta (01 / 00) e no número da parcela (001 / 002). Veja se está passando esses dados corretamente.

Tem um erro no código do exemplo do ACBrNFe:

Já respondido aqui:

Essa não é uma chave de acesso válida para NFCe. O tipo de emissão deve ser 1 (Normal) ou 9 (Contingência off-line). SP também aceita o tipo 4 (Contingência EPEC).

Observe as datas de entrada em vigor da NT. Provavelmente o webservice ainda não está preparado para as alterações por isso está rejeitando.

O erro indicado nesse arquivo é por falta do preenchimento do DV da agência/conta (específico para esse banco): ACBrBoleto1.Cedente.DigitoVerificadorAgenciaConta := '0'; Algumas cooperativas pedem que se informe 0, outras que se informe em branco.

6.3 - Mostre respeito pelo modo de escrever. Escreva de modo claro, gramaticalmente e semanticamente correto. Não escreva TUDO EM MAIÚSCULAS. Isso é lido como se estivesse gritando e é considerado rude. Favor leia as regras do fórum. --- Não impede se você fizer a alteração que indiquei. Como MG não tinha NFCe na versão 3.10 ele não encontra o endereço, que não existe.

CSOSN só existe para o CRT = 1, então você pode validar por essa tag.

É um problema no código do exemplo do ACBrNFe que está forçando a geração da NFCe na versão 3.10. Altere no trecho a seguir: ACBrNFe1.NotasFiscais.Clear; ACBrNFe1.Configuracoes.Geral.ModeloDF := moNFCe; ACBrNFe1.Configuracoes.Geral.VersaoDF := ve310; GerarNFCe(vAux); Na linha referente a versão informe: ACBrNFe1.Configuracoes.Geral.VersaoDF := TpcnVersaoDF(cbVersaoDF.ItemIndex); Isso vai usar a configuração da versão conforme informado na aba "Geral". E desfaça a alteração do ACBrNFeServicos.ini que fez anteriormente.

O que você precisou alterar no ACBrNFeServicos.ini? Pelo que consultei aqui os endereços estão corretos na última versão do repositório. Anexe por favor o arquivo ACBrNFeServicos.ini alterado. Isso quer dizer que o webservice não reconheceu o XML enviado. É preciso saber se o endereço do webservice e XML de envio estão corretos. Anexe também o arquivo de envio *-env-lot.xml gerado.

Está com os fontes atualizados? Há arquivo ACBrNFeServicos.ini desatualizado no diretório do executável?

Verifique a configuração da versão, se está como 4.00.

O XML retornado pela SEFAZ-MG para NFCe não está de acordo com as Notas Técnicas, houve inclusão de um prefixo na tag nfeResultMsg, ficando ns0:nfeResultMsg causando erro de leitura pelo ACBr. Em outro tópico sobre o componente vários usuários entraram em contato com a SEFAZ mas mesmo eles admitindo a falha no retorno e informando que houve a correção, o prefixo continua. Enviei agora para o repositório, rev. 16501, um ajuste para contornar esse problema. Se você não compila o ACBrMonitorPLUS, acredito que o @José M. S. Junior deve disponibilizar o ajuste na próxima atualização.

Para NFCe o ideal é usar o modo síncrono (terceiro parâmetro do método Enviar) onde a resposta do processamento vem na mesma chamada, sem a necessidade de se fazer a consulta da situação do lote como ocorre no modo assíncrono. Estude o demo do ACBrNFe para saber como capturar os retornos nos dois modos.

2.2 - Permaneça no assunto - Quando tiver uma dúvida diferente do assunto no tópico, poste em novo tópico. Não use algo equivalente a "aproveitando o gancho... [dúvida não relacionada com o tópico aqui]". Favor leia as regras do fórum. 6.3 - Mostre respeito pelo modo de escrever. Escreva de modo claro, gramaticalmente e semanticamente correto. Não escreva TUDO EM MAIÚSCULAS. Isso é lido como se estivesse gritando e é considerado rude. Favor leia as regras do fórum.

6.3 - Mostre respeito pelo modo de escrever. Escreva de modo claro, gramaticalmente e semanticamente correto. Não escreva TUDO EM MAIÚSCULAS. Isso é lido como se estivesse gritando e é considerado rude. Favor leia as regras do fórum. O segundo parâmetro do método ACBrNFe.Enviar indica se deve imprimir o DANFE ou não. Então basta usar ACBrNFe1.Enviar(nLote, False);

Por o processo ser síncrono e não haver a consulta do retorno nada é preenchido em ACBrCTe.WebServices.Retorno. Você pode usar: cdsCadMasterCSTAT.AsInteger := CTE.WebServices.Enviar.CTeRetornoOS.cStat; cdsCadMasterSTATUS.AsString := CTE.WebServices.Enviar.CTeRetornoOS.xMotivo; cdsCadMasterPROTOCOLO.AsString := CTE.WebServices.Enviar.CTeRetornoOS.protCTe.nProt;

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