adriano.quintino

Pelo que entendi, se o componente estiver parametrizado pra confirmar a transação ao concluir, conforme for inserindo os cartões e digitando a senha, então o usuário quiser cancelar algum pagamento, deverá ser feito o cancelamento de tudo. Porém, é possível configurar o componente pra deixar a transação pendente e então seria possível cancelar pagamento por pagamento individualmente. O problema que estou tendo, é porque configurei o componente pra confirmar as transações ao serem concluídas, porém, o usuário pressiona ESC pra retornar a tela anterior, é exibido a tela pra digitar a senha gerencial 9999, mas muitos usuários não sabem dessa senha e pressionam ESC várias vezes e então o componente está apagando tudo que está em memória e o arquivo, a transação não é cancelada e fica impossível cancelar ela posteriormente. Minha pergunta é: seria possível cancelar todas as transações ou cada uma individualmente, mesmo que estivesse configurado pra confirmar as transações, mas que não solicitasse a senha gerencial nem perguntasse se o cartão é débito ou crédito ? Isso facilitaria bastante a vida do usuário e a nossa também, rsrs.

Eu até poderia retornar pro ACBrTEFD, porém, ele também não está atendendo o teste 19 do roteiro de pré-homologação porque ele não chama a função IniciaFuncaoSiTefInterativo modalidade 130 nem a função ObtemQuantidadeTransaçõesPendente. Este foi o motivo pelo qual mudei pro componente ACBrTEDAPI, que ao meu ver, está muito próximo de ficar perfeito 100%.

Oi Juliomar, conforme está descrito na unit, pra inserirmos um break point, eu o fiz, porém, a procedure onde está a parada só é chamada quando se retira o cartão do pinpad, ou seja, se o consumidor demorar a remover o cartão e neste intervalo de tempo em que a transação foi aprovada e a retirada do cartão, o computador vier a desligar, teremos problemas porque a aplicação não vai conseguir recuperar a transação que estava pendente pois o arquivo .tef ainda não tinha sido criado pelo componente. No componente ACBrTEFD, este procedimento ocorre perfeitamente criando o arquivo .tef no mesmo instante em que se obtém o retorno AUTORIZADO mesmo que o cartão ainda não tenha sido removido do pinpad.

Oi Juliomar! Eu olhei no código e não encontrei estes pontos de parada a qual você se refere.

Encontrei o problema, mas não encontrei a solução. O problema é porque o ACBrTEFAPI só cria o arquivo de retorno na pasta tef ao retirar o cartão do Pinpad, mas ele deveria criar o arquivo ao obter o retorno "APROVADO", antes mesmo de remover o cartão. Da forma que está atualmente, o teste 19 exige que finalizemos a transação após o "APROVADO", com isso, ao fechar e abrir novamente o sistema, o componente não encontra o arquivo na pasta tef e não detecta que há transações que ficaram pendentes.

Eu fiz um teste utilizando o próprio TefAPIDemo.exe e ao solicitar pra retirar o cartão, eu finalizo a aplicação, porém, de qualquer forma que já tentei, ao iniciar o sistema, ele não autoriza a transação SiTEF

Me perdoa, errei o nome do componente na digitação. É ACBrTEFAPI.

Olá! Conforme o teste sequência 19 do roteiro de homologação SiTEF versão 20, o componente ACBrTEFPIX não está confirmando a operação, mesmo estando configurado pra confirmar. Segue abaixo o comando da instrução: - Realizar uma transação com cartão de Crédito chip. - Selecionar a opção à vista - Quando receber o retorno de aprovação, de forma rápida precisa encerrar a aplicação, para poder simular a transação pendente de forma correta. - Na sequência, iniciar novamente a aplicação e tratar a transação pendente pelas funções IniciaFuncaoSiTefInterativo modalidade 130 ou pela função ObtemQuantidadeTransaçõesPendentes - Após obter os resultadosdas funções acima, enviar função“Finaliza” confirmando ou desfazendo a transação, dependendo da sua regra de negócio. Foi detectado no arquivo .dump que o sistema até chama a função: IniciaFuncaoSiTefInterativo modalidade 130, porém não está chamando a função "Finaliza" para confirmar a operação.

Caso necessite, tenho o Demo e os manuais do TLS pra SiTEF. Segue em anexo. CliSiTef - Projeto TLS - 1.05.pdf SitDemo.zip

Fiz o teste e não deu certo porque tenho que passar este parâmetro antes da inicialização pra que seja informado no evento abaixo em ParamAdic. Sts := fTEFCliSiTefAPI.ConfiguraIntSiTefInterativo( PAnsiChar(EnderecoIP), PAnsiChar(CodLoja), PAnsiChar(NumeroTerminal), 0, PAnsiChar(ParamAdic) ); Outra solução será configurar no arquivo .ini, só gostaria de embutir dentro do executável.

Muito obrigado Juliomar Marchetti

Olá, pessoal! Utilizando o componente ACBrTEFD é possível adicionar os parâmetros adicionais conforme abaixo: TEFCliSiTef.ParametrosAdicionais.Add('{TipoComunicacaoExterna=TLSGWP;TokenRegistro=1111-2222-3333-4444}'); Contudo, preciso adicionar os mesmos parâmetros no ACBrTEFAPI para homologação do PIX no SiTEF. Como posso estar inserindo estes parâmetros no ACBrTEFAPI ? Grato pela atenção!

Bom dia pessoal, eu consegui reproduzir mas não consegui resolver. Caso você faça um debug e quando chegar na Linha NFCe.Enviar('1',False,True) e rapidamente desconecta-se da internet, provavelmente conseguirá reproduzir. No meu caso, semana passada todas as vezes estava dando certo, já essa semana estou desativando a internet e as vezes dá certo e outras vezes o xml ainda nem chegou lá, deixando assim, a numeração disponível pra emissão. Minha sugestão pro ACBr, é: Gerar exceptions diferentes nos casos em que o XML não tenha chegado ao servidor da SEFA e outro quando o número do protocolo não consiga retornar, ambos por falta de internet. O primeiro, deixaria o número pendente pra ser usado num próximo cupom, já o segundo, poderíamos tratar ele como um cupom já utilizado, restando apenas fazer uma consulta do mesmo e carregar as informações no banco de dados.

Olá! Estou encontrando problemas ao obter o peso (clicando no botão Ler Peso) mesmo no Demo do ACBr utilizando o "Virtual Serial Port Driver" para fazer testes. Ocorre um erro de "Communication error 9997..." Contudo, ao selecionar a caixa Monitorar a Balança, a leitura é feita sem problemas.

Estive observando e na verdade não é arquivo XML é apenas um arquivo TXT.

Olá! Bom dia! Alguém tem previsão de inclusão do provedor da Prefeitura Moderna pra NFSe no ACBr ? Como vários outros, o ACBr só precisará criar o arquivo XML pra posteriormente ser transmitido pelo aplicativo próprio da Prefeitura Moderna, com isso, ajudaria a muitos desenvolvedores pois vários municípios utilizam este sistema. Att.: Adriano Quintino

A única solução encontrada até o momento, foi fazer os testes em produção, e em seguida, caso o cupom seja aprovado, eu o cancelo. A SEFA paraense é ultrapassada, o suporte técnico é péssimo, não há ninguém que lhe dê uma informação concreta. Nem eles sabem o que deve ser passado em um QR-Code. Eles são apenas sanguessugas da máquina pública.

Bom dia! Também estou tendo este problema na SEFAZ paraense pra ambientes de homologação da NFCe 4.0 Alguém teria alguma sugestão ? Conversei com o CallCenter da SEFA PA e eles me informaram que utilizam o webservice do Rio Grande do Sul, o que faço pra configurar e emitir neste webservice ? Att.: Adriano Quintino

Boa tarde Pessoal! Estou tendo problemas ao emitir Cupom Fiscal Eletrônico em ambiente de homologação 4.0 no estado do Pará. Me surge o seguinte erro: 'https://appnfc.sefa.pa.gov.br/portal-homologacao/view.consutlas/nfce/consultanfce.seam' violates maxLength constranit of '85' The element '{http://www.oprtalfiscal.inf.br/nfe}urlChave' with value 'https://appnfc.sefa.pa.gov.br/portal-homologacao/view/consultas/nfce/consultanfce.seam' failed to parse. Tem previsão de correção deste link ? Essa url está muito grande, ultrapassando o limite máximo de 85 caracteres. Entrei no site da SEFA paraense mas os links estão todos quebrados. Nada funciona.

Muito obrigado Italo, agora estarei dependendo da SEFA do Pará! Eita, parazão véi!

Bom dia! Gostaria de saber se os webservices de homologação para o estado do PARÁ já está disponível, pois tentei enviar uma NFCe na versão 4.0 em ambiente de homologação mas me retornou um erro, informado que o campo excede o máximo ('85') permitido na URL.

Muito obrigado pela atenção LIDERNetwork!

Sim, é verdade, mas como eu mesmo já havia informado, esta resposta não atende a minha pergunta, pois eu não havia perguntado se o troco ou qualquer tag foi acrescentado ou não. O meu único problema é que depois que eu atualizei o ACBr, o layout do DANFE, não do xml, do DANFE ficou diferente, todas as linhas "bonitinhas" que separava os grupos de dados não aparecem mais. Mas acho que é difícil entender e se não conseguem responder, independente se eu colocar aqui ou em qualquer outro lugar no fórum, dificilmente saberão interpretar a dúvida. Desculpas aí se eu coloquei aqui no tópico da 4.0 mas como o fonte é devido a atualização do ACBr eu achei que eu poderia, mas reconheço que eu errei em colocar aqui. Sinto muito. Mas agradeço a atenção!

Tudo bem André, vou acrescentar em um novo Tópico, mas eu achei que fosse algo nesta nova versão da NFCe 4.0 a alteração do Layout no DANFE. A minha dúvida era apenas se está normal pra esta nova versão ou não, simplesmente isso. Mas vou colocar em novo tópico. Agradeço a atenção.

Bom dia pessoal ! Poucos dias atrás eu fiz uma pergunta, no entanto a resposta que obtive não era o que eu esperava. Por isso, agora estou lhes mandando uma foto em anexo pra facilitar o entendimento da minha questão abaixo. O meu questionamento é o seguinte, eu atualizei o ACBr e devido a esta atualização o DANFE da NFCe foi modificada, isso tem alguma relação com a Norma técnica ? O DANFE agora ele está sendo impresso conforme o anexo, ou seja, removeu todas as linhas divisórias e aparentemente está "junto" todas as informações. Este é o novo DANFE ou é alguma configuração nesta nova versão da NFE ? Quero saber se é NORMAL ou é alguma alteração que eu mesmo deva alterar dentro do componente pra ter as linhas divisórias e os agrupamentos por tipos de informação. Desde já agradeço a atenção.