Daniel Simoes

Realmente será necessário o manual do Fabricante, para saber esse tipo de informação com segurança... Mas você pode usar o Demo do ACBr, para rapidamente testar várias configurações de verificar se funciona...

o contribuinte precisará consultar (ligar para) a SEFAZ... provavelmente há alguma restrição com o CNPJ dele...

Não temos nada nesse sentido...

Sim.. todo o ACBr é compatível com D7

Será que não ficaria mais versátil se ExpectedResultCode, fosse um array de Integer ? Assim poderiamos atribuir vários valores como válidos, exemplo: [200, 201]

Obrigado pela contribuição... em analise...

Olá @ODEON TECNOLOGIA... Você tem algum link com a documentação técnica de integração, segundo padrão da API PIX do BACEN ?

Sim isso mesmo... o intuito da lei, é evitar que o Lojista entregue apenas o comprovante do Cartão, e não na NFCe... a NFCe deverá ser impressa em todas as vendas... mas nem todas as formas de pagamento, geram comprovantes para impressão

Acho que é um equívoco de interpretação do JSon... O primeiro parâmetro informa que ele irá "paginar" a resposta em até 10 itens por retorno... Em JSon não precisamos de um campo para dizer o tamanho do Array... Ahhh.. agora que notei o que você destacou... quantidadeTotalDeItens Esse valor realmente parece estar errado e em desacordo com o Array... Será necessário entrar em contato com o suporte do PSP

Insira outro índice que permita Vinculado

Se você não está imprimindo em ECF... o índice da Forma de Pagamento é indiferente... Por favor modifique seus fontes, passando sempre o mesmo índice (exemplo "01"), e teste os resultados

Por favor aumente o nível do Log... e tente novamente... Assim termos toda a comunicação HTTP

Exato.. no ACBrTEFAPI, não é mais necessário esse parâmetro... atualmente, como não há a impressão em ECF, ele é totalmente desnecessário... Mas se for diferente, por forma de pagamento, ele acabará tentando abrir "Cupons Vinculados" diferentes, e com isso causa o problema...

Quando você abre o CRT, verifique se está passando sempre o mesmo índice de Forma de Pagamento (segundo parâmetro) Observe que o Demo está usando '01' em todas as opções if (Indice = '02') then // 02-CHEQUE begin Ok := ACBrTEFD1.CHQ(AValor, '01'); TemTEF := True; end else if (Indice = '03') then // 03-CREDITO begin InformarParametrosCartaoCredito; Ok := ACBrTEFD1.CRT(AValor, '01'); TemTEF := True; end else if (Indice = '04') then // 04-DEBITO begin InformarParametrosCartaoDebito; Ok := ACBrTEFD1.CRT(AValor, '01'); TemTEF := True; end

Veja esse vídeo:

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Essa propriedade, terá o nome do PDF, após ele ser gerado em Disco ACBrNFe1.DANFE.ArquivoPDF;

Eu acho que seria melhor fazer tudo por Stream, sem salvar o PDF em Disco... procedure SalvarPDF(ADANFe: TACBrNFeDANFeRL; ANFe: TNFe; AStream: TStream); overload;

Me parece ser um erro na lógica de programação... Por favor anexe o Log do componente de TEF

@Arturo, se você reconstruir o Lazarus, ele já irá adicionar todos os componentes que estavam instalado anteriormente... Sua IDE está em Portugues ? o caminho que o Juliomar deu, é com a IDE em inglês

Você consegue reproduzir o problema no Demo do ACBr ? Verifique se em sua rotina de impressão, você não está com um Loop, e enviando para impressão, todas as Resposta de TEF no ObjectList

Esses caracteres no Inicio, podem indicar o retorno em UTF8... Esses caracteres tratam-se do BOM https://www.unicode.org/faq/utf_bom.html Verifique se você configurou o INI, para o retorno em ANSI

Parabéns pelo seu trabalho @billbarsch, e por compartilhar conosco...

A convenção de chamadas, você define do seu lado, quando faz o "bind" da DLL na sua linguagem... Uma vez definido, você deve sempre usar a mesma convenção de chamadas, pois usar a DLL com a convenção de chamadas errada, pode causar A.V. ou outros problemas...

Ajuste as libs do Android, com a versão da sua IDE... veja esse link: https://github.com/TecToy-Automacao/Delphi/tree/main/ACBr/V2Pro/EtiquetaEventos#como-abrir-o-projeto-no-delphi