bnobre

Explicação perfeita meu amigo... Um forte abraç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

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

Segue o link que mencionei: Se funcionar contigo avisa aqui... Abraços

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.

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

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.

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.

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.

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

Olá @Juliomar Marchetti Tudo bom com você?! Verdade... PEQUENO grande detalhe!!! Obrigado pela observação. Abraços

Diferenças sobre o fpPagamentoInstantaneo e fpPagamentoInstantaneoEstatico:

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

Olá... Poderiam jogar esse tópico na parte do Fórum Aberto?!?! Desde já agradeço a atenção

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

Bom dia a todos, Aqui no RJ a rejeição YA04-10 foi ativada em ambiente de 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

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.

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

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

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

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

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: 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

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

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.