sgeinformatica

Estamos com o mesmo problema, mas é somente em homologação. Em produção está gerando NFCe com cpf e com as tag do IBS/CBS

Não sei dizer... Mas de qualquer forma, obrigado pela atenção.

Certo, Porém existe uma rota na api do inter ("/pdf") que ja retorna o PDF gerado. Em um usuário do ACBr boleto fez essa implementação e eu achei que tivesse sido colocado nos fontes oficiais.

Entendi, eu reparei que tem que ativar o indicador pix para que o "nosso numero correspondente" seja gerado no momento do registro. Ai sim, com esse NossoNumeroCorrespondente eu consigo fazer a consulta detalhada. Aproveitando a oportunidade, mais uma pergunta: Visto que o banco inter ja gera o pdf do boleto, o ACBr boleto ja está preparado para receber o stream desse boleto em base64?

Não estou conseguindo realizar consultas detalhadas na api boleto do banco Inter. Sempre me retorna: Titulo não encontrado. Ao alimentar a lista de títulos, no caso do banco inter eu informo o campo "Seu Numero", pois o "Nosso Numero" é gerado automaticamente pelo banco. Se eu tentar informar o "Nosso Numero" que foi gerado automaticamente pelo banco, o componente recusa pois tem mais de 10 dígitos. Alguma dica para resolver? Obrigado

Boa tarde "Por enquanto" parece que conseguimos resolver o problema dessa merda dos servidores da farmacia popular o problema era falha na comunicação com o webservice deles, e mudamos o codigo para fazer varias tentativas No nosso caso não precisamos alterar nenhuma configuração no windows Segue um fragmento do código que resolveu o problema ConfirmacaoAutorizacao := nil; A := 0; try repeat Inc(A); try ConfirmacaoAutorizacao := WS.confirmarAutorizacao(Confirmacao, Usuario); except end; Sleep(3000); if A = 30 then Break; until ConfirmacaoAutorizacao <> nil; finally if ConfirmacaoAutorizacao <> nil then CodigoRetorno := ConfirmacaoAutorizacao.inAutorizacaoSolicitacao else CodigoRetorno := ''; end;

Se vc mandar em contigencia, depois de um ou 2 dias o SAT não fica mais com essa luz acessa de CFe pendente

Fiz testes com NF 3658 e 3659, e não aconteceu o erro mais. E aquele produto que estava saindo no rodapé tambem não saiu mais Mas tem mais dois pequenos acertos a serem feito, mas lembrando que não atrapalha em nada, como diz meu socio é só perfumaria Na NF 3658, ficou uma linha maior no final Na NF 3659 que são 2 paginas, no final da primeira pagina ficou com 2 linhas

Lembrando que esse erro somente acontece no DANFeRetratoNovo.fr3 que o nosso amigo Hleorj enviou para testes. Do SVN nem existe essa procedure

Pessoal o erro "could not convert null" está na procedure abaixo, naquele ponto onde grafei em negrito e italico : StrToInt(get('LinhasImpressas')) Tentei mudar para StrToIntDef mas não aceitou Pelo jeito o comando get('LinhasImpressas') está retornando nulo. procedure DadosProdutosOnAfterCalcHeight(Sender: TfrxComponent); var wTamRodapeMinimo : Double; begin wTamRodapeMinimo := get('TamRodapeMinimo') + DadosProdutos.Height + ChildCorpoBottom.Height; if ( Engine.FreeSpace < wTamRodapeMinimo ) then Engine.ShowBand( DadosProdutosFooter ) else if (StrToInt(VarToStr(<Parametros."LinhasPorPagina">)) > 0) then begin if (StrToInt(get('LinhasImpressas')) = StrToInt(VarToStr(<Parametros."LinhasPorPagina">))) then Engine.ShowBand(DadosProdutosFooter); end; end;

amanha vou procurar esse erro "could not convert null" e assim que tiver uma solução eu posto aqui

fiz alteração no que está no SVN Versão 5.6

Eu nao tenho acesso para gravar no SVN, mandei o FR3 alterado em anexo ai acima

Conseguimos arrumar no Memo137 e Memo66 mudamos a propriedade align para babotton (são as caixas de dados adicionais) O erro (Could not convert variant of type (null) into type (olestr) acima tinha dado em runtime Obrigado pela ajuda DANFeRetratoNovo.fr3

Deu esse erro abaixo :