[Exceção acontece, mas código não é interrompido]

2 minutos atrás, BigWings disse:

Por causa do try..except no método Execute, como dito.

procedure TCustomRESTRequest.Execute;
[...]
begin
  [...]
      try
        [...]
      except
        // any kind of server/protocol error
        on E: EHTTPProtocolException do
        begin
          FExecutionPerformance.ExecutionDone;
          // we keep measuring only for protocal errors, i.e. where
          // the server actually answered, not for other exceptions.
          LContent := E.ErrorMessage; // Full error description

          // Fill RESTResponse with actual response data - error handler might want to access it
          ProcessResponse(LURL, LResponseStream, LContent);

          if (E.ErrorCode >= 500) and Client.RaiseExceptionOn500 then
            Exception.RaiseOuterException(ERESTException.Create(E.Message));
          HandleEvent(DoHTTPProtocolError);
        end;
        // Unknown error, might even be on the client side. raise it!
        on E: Exception do
        begin
          // If Execute raises an Exception, then the developer should have look into the actual BaseException
          Exception.RaiseOuterException(ERESTException.CreateFmt(sRESTRequestFailed, [E.Message]));
        end;
      end;

Sendo uma exceção do tipo EHTTPProtocolException ele faz os tratamentos, mas ignora a exceção em runtime exceto no caso da propriedade RaiseExceptionOn500 estiver ativada e o status de retorno for maior 500 ou maior.

Ele também chama o evento OnHttpProtocolError que você pode querer implementar (para logs por exemplo).

Explicação perfeita meu amigo...

Um forte abraço

[Exceção acontece, mas código não é interrompido]

2 minutos atrás, BigWings disse:

O try..except está no código do próprio RestClient.

Veja o comentário do método Execute:

    /// Execute does NOT raise HTTP protocol exceptions, instead TCustomRESTClient.Response.StatusCode should be checked
    /// for desired values. In many cases a 2xx StatusCode signals "succes" - other status codes don't need to be
    /// errors though. It depends on the actual REST API.
    /// </remarks>
    procedure Execute;

Ou seja você tem que verificar o código http de retorno e tratar na sua aplicação.

Olá meu amigo... 

Então ele trata igual o fetch do javascript que não considera retornos diferentes de 200 como exceção.

Irei tratar manualmente conforme a sugestão, mas continuo com parte da dúvida:

Porque o Delphi gera a exceção VISUALMENTE em Debug, porém continua o código normalmente como se nada tivesse acontecido?

Desde já agradeço a atenção

[Exceção acontece, mas código não é interrompido]

Olá a todos,

Estou consumindo uma API REST usando o RestClient e demais componentes sugeridos na configurações do REST Debugger, mas reparei uma coisa bem estranha.

Quando a validade do token de acesso acaba eu recebo (conforme esperado) uma exceção "raised exception class EHTTPProtocolException with message 'HTTP/1.1 401 Unauthorized'."

O problema é que apesar da exceção aparecer em modo debug, o Delphi continua a execução do código na linha seguinte, como se nada tivesse acontecido ao invés de interromper a execução do mesmo.

A documentação desses componentes do Delphi são meio escassas, porém existe uma propriedade no RestClient chamada RaiseExceptionOn500.

https://docwiki.embarcadero.com/Libraries/Athens/en/REST.Client.TCustomRESTClient.RaiseExceptionOn500

De acordo com a documentação achei que desativando a mesma resolveria, mas nada.

Porém mesmo que resolvesse a minha dúvida continua:

Como o Delphi pode disparar uma exceção em Debug, porém não interromper o código como seria de se esperar?

Desde já agradeço a atenção de todos

[Bitmap image is not valid - Fortes]

22 horas atrás, César Augusto Forato Prado disse:

Bom dia amigo, conseguiu resolver?

Estou exatamente com o mesmo erro em apenas um cliente, por conta disso não consigo debugar.

Segue o link que mencionei:

 

Se funcionar contigo avisa aqui... Abraços 

[Bitmap image is not valid - Fortes]

5 minutos atrás, César Augusto Forato Prado disse:

Bom dia Juliomar, fiz um projeto do zero, só com RLReport do Fortes e deu o mesmo erro. O problema está entre a máquina do cliente e o Fortes. Percebi que a máquina dele é com o windows 11 em inglês não sei se tem alguma relação.

Olá... Lembro que comigo deu em um Windows em inglês também.

1 minuto atrás, bnobre disse:

Olá... Lembro que comigo deu em um Windows em inglês também.

Perdão... Esqueci de mencionar o mais importante... Um amigo postou uma possível solução que nunca pude testar pois o tal cliente que tive o problema acabou formatando o computador... Vou tentar achar aqui no fórum, acho que foi em outro tópico meu.

[ACBrETQ em Knup]

Olá meu amigo...

Desculpe a demora.

O problema é que se trata daqueles equipamentos XingLing... Não existe um fabricante com uma documentação disponível de maneira fácil e o importador nada sabe informar.

Será que alguém aqui do fórum obteve êxito configurando a mesma com o ACBrETQ?!

Conforme for pode colocar no fórum aberto, pois de repente surge alguém lá que teve êxito com esse equipamento.

Desde já agradeço a atenção meu amigo 

[ACBrETQ em Knup]

Olá a todos,

Estamos tentando configurar o ACBrETQ na Knup KP-IM604 Tipo Zebra.

Pelo Windows, ela puxa o papel normalmente, mas pelo ACBrETQ a impressora não dá sinal de vida.

Testamos com os modelos etqPpla, etqPplb, etqZLII, etqEpl2 e etqEscLabel. E nosso componente encontra-se atualizado.

Alguém já conseguiu colocar essa impressora pra funcionar?!

Desde já agradeço a atenção de todos.

[Erro com pgto em PIX - Em homologação]

8 minutos atrás, Cleber Ferreira disse:

nosso amigo @Diego A. Folieni fez uma postagem a respeito.

Vamos acompanhar por lá os desdobramentos. Aparentemente alguns estados estão validando e outros não.

Olá @Cleber Ferreira

Tudo bom?!

Independente da resposta dos órgãos, eu creio que é mais vantagem seguir logo essa regra.

Pois se a UF não obrigar, também não irá impedir que seja seguida... E lá no futuro já estaremos atendendo, caso a mesma volte atrás quanto a sua obrigatoriedade.

[Erro com pgto em PIX - Em homologação]

3 horas atrás, Tiago Mendes disse:

Atualizei os fontes e agora informando a tpintegra como 2 passa em homologação e produção. Foi acionado uma novo meio de pagamento instantâneo também. Mais usando o 17 funciona perfeitamente agora

Oi meu amigo...

Como você adicionou o tpIntegra = 2, o componente cria o grupo card e joga o mesmo lá dentro.

Dessa forma você passa pela validação YA04-10.

[Erro com pgto em PIX - Em homologação]

51 minutos atrás, Tiago Mendes disse:

Bom dia me parece que o pix 17 agora migrou pro grupo de cartoes e assim estao conseguindo , sabe me dizer se preciso atualizar os fontes do acbr, porque aqui nao consigo

Bom dia...

Tudo bom?!

Não entendi o que quis dizer ao falar migrou para o grupo de cartões.

Sobre atualização dos componentes, para atender essa regra de validação YA04-10 você irá precisar adicionar o grupo de cartões (card) quando o tPag = 17, veja se seu componente como está já faz isso.

Provavelmente SIM, pois essa obrigatoriedade já existe para as formas de pagamento de cartões de crédito e débito há tempos.

Abraços 

 

 

[Dúvida sobre novo meio de pgto]

1 hora atrás, Juliomar Marchetti disse:

Não bate o que tu está a pensar pois ele fica aguardando o pagamento e para isso tem que ser o dinamico com informações.

o estático ele só vai exibir e pronto . não vai ficar e nem tem como validar no POS se recebeu ou não a não ser que acesse a conta para verificar

Olá @Juliomar Marchetti

Tudo bom com você?!

Verdade... PEQUENO grande detalhe!!!

Obrigado pela observação.

Abraços 

[Erro com pgto em PIX - Em homologação]

Diferenças sobre o fpPagamentoInstantaneo e fpPagamentoInstantaneoEstatico:

 

[Erro com pgto em PIX - Em homologação]

26 minutos atrás, LIDERNetwork disse:

Colocando como Pagamento fpPagamentoInstantaneoEstatico esta passando nos estados da Bahia e Pernambuco, não testei em outros estados. Também não conclui a leitura da Nota Tecnica e como fica a questão fiscal em relação a diferença do modo anterior, mas resolve o problema.

Olá amigo, tudo bom?

Vai passar sempre, pois a rejeição não faz menção ao tPag = 20.

Cuidado com a sua interpretação de resolve o problema, pois pode gerar outro no futuro.

Pois com isso seu cliente está afirmando que o QRCode dessa venda é do tipo Estático. Eu abri um tópico a respeito do tema, mas está na parte do ACBr Pro... Pedi para eles migrarem, se possível, para o fórum aberto. Depois da migração eu cito o mesmo pra você.

Abraços

[Dúvida sobre novo meio de pgto]

Olá... Poderiam jogar esse tópico na parte do Fórum Aberto?!?!

Desde já agradeço a atenção

[Erro com pgto em PIX - Em homologação]

17 minutos atrás, valterpatrick disse:

Pois é, aconteceu comigo aqui.
Como estão fazendo?
Só atualizar os schemas?

Eu geralmente uso a opção fpOutro, mas não está dando certo.

Bom dia meu amigo

Onde seria o aqui contigo?!?!

Em relação a regra de validação YA04-10, agora é necessário informar o grupo de cartões para o pagamento 17.

Observar também que agora temos 2 Pagamentos Instantâneos:

• Pagamento Instantâneo Dinâmico  - 17 - Antes só Pagamento Instantâneo, agora renomeado
• Pagamento Instantâneo Estático - 20 - Esse é novo

Sugiro ler a Nota Técnica 2023.004 versão 1.11 para maiores detalhes. 

Abraços

[Erro com pgto em PIX - Em homologação]

Bom dia a todos,

Aqui no RJ a rejeição YA04-10 foi ativada em ambiente de Produção.

[Erro com pgto em PIX - Em homologação]

44 minutos atrás, Daniel InfoCotidiano disse:

A principio sim, p vc ter uma idéia, tem estado q nem as novas formas de pagamento estão funcionando em homologação.
A principio deve entrar 01/07 junto com a produção.
 

Olá amigo...

Sério isso?!?! Jesus...

Bem... Vou me preparar aqui adicionando o grupo de cartões, pois mal não irá fazer.

No dia 01/07/2024 dou um feedback se ativou em produção aqui no RJ.

Abraços

[Dúvida sobre novo meio de pgto]

11 minutos atrás, Daniel Simoes disse:

suspeito que QRCode Dinâmico... observe que ele nunca é igual... e está associado a venda...

Também achei que fosse dinâmico, mas na verdade foi vendo o vídeo que você me recomendou que fiquei mais ainda com essa dúvida.

Durante o vídeo vocês informam que é possível gerar um QRCode Estático com valores diferentes... Então fiquei pensando: Será que é isso que a maquininha POS faz isso?!?! Pois se posso informar o valor, então tecnicamente é possível a maquininha fazer isso.

E como ela não está integrada ao meu sistema, ela não está associada a venda DO meu sistema.

Como agora em 01/07/2024 teremos duas categorias de PIX em produção, não tenho pra onde correr, tenho que me decidir. A princípio vou escolher a 17 - Dinâmica, pois creio que a maquininha deve usar nesse formato para facilitar os relatórios internos da mesma.

 

[Erro com pgto em PIX - Em homologação]

Então pessoal,

Após pesquisas, descobri que esse erro é devido a regra YA04-10 que está para entrar em vigor nos ambientes de Produção, de maneira FACULTATIVA, em 01/07/2024. Para mais detalhes ver NT 2023.004.v1.11.

Realmente meu programa não está gerando o grupo cartões para PIX. Só tem um porém:

Se repararem nesse tópico, caso eu não tenha entendido errado, o amigo @Fabrício G. Araújo sugere que algumas UFs que ativaram essa regra em homologação não devem manter a mesma em produção.

E aí... Entendi corretamente??? O que acham?!?!

Desde já agradeço a atenção de todos 

[Dúvida sobre novo meio de pgto]

36 minutos atrás, Daniel Simoes disse:

@bnobre,

Basicamente QRCode estático, só tem a representação da Chave PIX do estabelecimento, sem valor, ou qualquer vínculo com as vendas

o QRCode Dinâmico é gerado a cada venda, e só vale para ela, permitindo que você detecte se aquela venda foi paga ou não de forma automatizada...

Recomendo ver esse vídeo, que possui os conceitos de PIX

 

Olá @Daniel Simoes

Tudo bom com você?!?

Excelente vídeo, mas na verdade ainda estou com uma dúvida...  O PIX das maquininhas TEF e POS geram o QR-Code dinâmico ou o estático?!?!

Desde já agradeço a atenção

[Dúvida sobre novo meio de pgto]

Olá a todos,

No Informe Técnico 2024.002 - v.1.01 - Publicado em 07/06/2024 foi incluído o item 20: “Pagamento Instantâneo (PIX) – Estático” e alterado o item 17 para acrescentar a palavra “Dinâmico”.

De acordo com o texto, o objetivo é separar o os pagamentos de PIX com o “QR-Code Dinâmico” do tipo “QR-Code Estático”.

Isso me gerou três  dúvidas:

1º - Em quais casos é usado um ou outro?!?!

2º - Qual é o usado nas máquinas POS?

3º - Qual é o usado nas máquinas TEF?

Desde já agradeço a atenção de todos

[Erro com pgto em PIX - Em homologação]

PS: Essa rejeição ocorre somente no NFC-e... Em NF-e está passando.

[Erro com pgto em PIX - Em homologação]

Olá a todos,

Aqui no RJ, em ambiente de homologação, ao tentar finalizar o pagamento com o código tpag = 17, recebo a seguinte rejeição:

Rejeicao: Nao informados os dados do cartao de credito/debito nas Formas de Pagamento da Nota Fiscal

Ao usar o tpag = 20 funciona.

Na Tabela de Meios de Pagamento - Vigente a partir de 01/07/2024 - Publicada em 07/06/2024 no Portal da NFe, consta o seguinte:

Citar 17 - PIX realizado com a geração do Qr-Code de forma dinâmica ou URL dinâmica. As UF podem exigir que o código de transação do pagamento desse tipo de PIX seja informado na NF-e/NFC-e.

1ª dúvida - Será devido a essa exigência que estamos estamos recebendo essa rejeição?!?!

2ª dúvida - Se sim, então dia 01/07/2024 começará a criticar em produção também?!?! 

3º dúvida - Nos clientes com PIX em máquinas POS, devo usar o 20?!?!

Desde já agradeço a atenção de todos

[Erro ao Imprimir DANFe - Fortes Report]

Em 14/06/2024 at 14:25, ronifunis disse:

Ola a todos!

Tive o mesmo problema que o post acima essa semana com o Windows server 2019. 

A solução para mim foi entrar em painel de controle - regiao -  Aba Administrativo - Alterar localidade do sistema - desmarcar a opcao Usar Unicode UTF-8 para suporte de linguagem mundial, aplicar e reiniciar.

Abraços.

Olá meu amigo... 

Obrigado pela lembrança em postar sua resolução aqui no fórum de um problema que aconteceu em 2022 com a gente, isso é de extrema importância. Vou encerrar o tópico finalmente como resolvido!

Ao longo desse tempo todo e desde que trabalho com os componentes do ACBr, só tive esse caso com esse cliente, mas acontecendo novamente tentarei sua dica.

Abraços

[ICMS Efetivo e ICMS Retido no RJ - Retorno da Novela]

Olá a todos,

Quem está acompanhando o tópico sabe que o assunto ficou em aberto desde Janeiro/2024.

Fazendo um breve resumo, a SEFAZ-RJ havia determinado a aplicação da Resolução Sefaz Nº 578 nos DF-e a partir de 01/01/2024. A data chegou e nenhuma crítica forçando o preenchimento das tags relacionadas a Resolução foi ativada, tanto em ambiente de homologação quanto em ambiente de produção. Então em teoria o preenchimento ficou obrigatório(dado a a existência da Resolução), mas tecnicamente opcional (pela falta de críticas do servidor).

Fiquei acompanhando o cenário, para ver se algum cliente iria aparecer recebendo algum tipo de sansão por parte da SEFAZ-RJ pela falta de preenchimento dessas tags, até que em 27/03/2024 o nosso amigo abre o seguinte tópico:

Eu não estava sabendo dessa prorrogação que ocorreu em 15/02/2024 pela Resolução Sefaz Nº 617 até ler o tópico acima, obrigado pelo aviso @Diego Foliene.

Mas, adivinha... Dia 01/04/2024 e novamente nenhuma crítica foi ativada obrigando o preenchimento dessas tags, tanto em ambiente de homologação quanto em ambiente de produção. 

Então voltamos a estaca zero: em teoria o preenchimento ficou obrigatório(dado a a existência da resolução), mas tecnicamente opcional (pela falta de críticas do servidor).

Se alguém tiver alguma novidade sobre o assunto, favor postar.