valterpatrick

Pessoal, depois de fazer vários testes e pegar um exemplo de um cliente meu, vi que o problema está na forma como é colocado o número do terminal. O padrão é: SE000001 e eu estava colocando 1, 001, 0001 e etc.
Depois que alterei isto, resolveu.
 
# No arquivo clisitef.ini eu coloque assim:
;Quando não há PinPad conectado à máquina
[PinPadCompartilhado] 
Porta=AUTO_USB
;Quando não há PinPad conectado à máquina e precisa digitar os dados do cartão
[Geral]
TransacoesAdicionaisHabilitadas=7;8
PermiteTrnCartaoGift=0
;TransacoesAdicionaisHabilitadas=7;8;42;29;3047;3048;3674;3379;3515;3374;3377;3378;3985
 
# GP:
CliSiTef
 
# Dados:
Código Loja
00000001
Número Terminal
SE000001
Restrições
{DevolveStringQRCode=0}

Infelizmente também estou por fora, mas qualquer outra atualização sobre o assunto lançarão notas técnicas e será discutida aqui no ACBr, é só acompanhar o fórum.

Então, talvez seja mais fácil consultar a lista de rejeição por que pela lógica você não pode devolver algo que você não comprou.
Quando vai devolver, você emite uma nfe se identificando e referenciando uma ou mais nfce sem identificação ou com sua identificação, agora referenciar nfce emitida para outros usuários nunca vi.

Parece que deve ter dois ou mais itens com o mesmo indice (campo "Prod.nItem").
Este é o campo para ordenar a sequencia dos itens. Ele não pode repetir.
Eu faço assim:
//Começo com o valor zero a variável ItemNro
ItemNro := 0;
//Para cada produto eu vou incrementar o indice antes de setar os dados, desta forma começa com 1 e vai incrementando de 1 em 1
Inc(ItemNro);
// No campo det.Prod.nItem eu informo o indice do produto
Prod.nItem := ItemNro;

MG ainda está em contingência pelo menos até 14hs do dia 05/07 e neste período está acontecendo algumas instabilidades, inclusive neste momento está vermelho no monitor de disponibilidade.

Já aconteceu com um cliente meu.
A contabilidade entrou em contato com a Sefaz e solicitou os XML.
A Sefaz enviou os arquivos XML das NFe e se eu não me engano TXT das NFCe.
Isto teve um custo, mas conseguiu e de forma oficial.

Você atualizou os schemas que ficam na pasta do ACBr?
\ACBr\Exemplos\ACBrDFe\Schemas
Teste estes e se não der certo, vai no site da receita, tem lá também.

Mas nota fiscal de devolução não tem pagamento, não seria o caso de você apenas não preencher estes campos?

Os valores estão iguais ou menores que a nota emitida para você?
Outra coisa a rejeição é 545 mesmo?
Por que Rejeição 545 para NFe/NFCe é Rejeição: Falha no schema XML – versão informada na versaoDados do SOAPHeader diverge da versão da mensagem.
https://www.oobj.com.br/bc/article/erros-e-rejeições-na-emissão-de-nfe-e-nfce-mapeados-no-oobj-dfe-453.html
https://atendimento.tecnospeed.com.br/hc/pt-br/articles/360016444013-Rejeição-545-Falha-no-schema-XML-versão-informada-na-versaoDados-do-SOAPHeader-diverge-da-versão-da-mensagem

Pessoal, tenho o código do Unificador do Sped Contribuições funcional.
Eu não consigo anexar mais do que 993B, então caso alguém precise, manda msg no privado.

Cara, eu vejo que não há problemas em devolver parcialmente os itens, tipo você devolve metade hoje e semana que vem metade. Cada nota referenciará a mesma chave de acesso, mas serão produtos e/ou quantidades diferentes.
O que não pode acontecer é referenciar uma nota e os produtos não serem os que estavam na nota ou serem quantidades maiores.

\\ACBr\Exemplos\ACBrDFe\ACBrDI

Tem este exemplo.

Pessoal, uma das notas o pessoal da receita retornou informando que foi dado o aceite na nota, por isto não conseguimos cancelar.

infRespTec.CNPJ := '00000000000';
          infRespTec.xContato := 'Nome Dono Empesa';
          infRespTec.Email := 'Email Empresa';
          infRespTec.fone := 'Telefone Empresa';


Preencha desta forma

Eu achei a solução neste link:
 
Na situação onde o ANP está na lista abaixo:
 
'210203001', '320101001', '320101002', '320102002', '320102001', '320102003', '820101032', '820101027', '820101004', '820101005', '820101022', '820101031', '820101030', '820101018', '820101020',
                      '820101021', '420105001', '420101005', '420101004', '420102005', '820101003', '820101012', '420106002', '830101001', '420301004', '420202001', '420301001', '510101002', '510102002', '510201001', '510201003', '510301003', '510103001',
                      '510301001', '820101026', '320102005', '320201001', '320103001', '220102001', '320301001', '320103002', '820101019', '820101014', '820101006', '820101016', '820101015', '820101025', '820101017', '820101013', '420102004', '420104001',
                      '820101033', '820101034', '420106001', '820101011', '510102001', '420301002', '410103001', '410101001', '410102001', '430101004', '510101001'
 
Deve ser informado CST := cstRep60 e não CST := cst60.
 
Muito obrigado.

Juliomar, não vai precisar mais.
Encontramos o problema.
O cliente estava emitindo em outro sistema simultaneamente. No mês 08/2020 emitiu a 200 em um sistema e a 240 em outro.
Obrigado pela ajuda.

Daniel, realmente não pode ter o sinal de negativo, tem que ser um valor positivo ao enviar para a impressora.
Foi um erro meu, eu fiz algumas modificações por conta da NFCe e não testei o código de novo para o ECF.
O problema está resolvido, obrigado pela ajuda.

Beleza, eu vou programar o comprovante não fiscal SANGRIA e SUPRIMENTO. Aí na hora de usar o comando RelatorioGerencial(texto, 1) eu devo usar algum outro antes?

Deu certo, eu alterei a propriedade PosPrinter.ConfigLogo.IgnorarLogo do componente TACBrPosPrinter para falso e resolveu o problema.
Obrigado.

Aconteceu o mesmo problema comigo hoje, mas a solução do meu foi diferente:
 
Quando eu abri um projeto tinha um DFM onde o ACBRNFe tinha a propriedade Configuracoes.Geral.IncluirQRCodeXMLNFCe, mas com a nova versão não tem mais esta propriedade. O que eu fiz foi clicar para ignorar e salvar o DFM, com isto foi retirada a propriedade e não está dando erro mais.

@amaro.omplantacao, eu desenvolvi esta unit para gerar a remessa e ler o retorno do débito automático.
Confere ai.
 
 
ACBrDebitoAutomatico.pas