EMBarbosa

Bom dia Ala. O log contem todas as interações com o SiTef. Então se você juntar ele, o código e a documentação é possível você mesmo verificar o que está faltando ser implementado. Mas é muito importante que você entenda como o Sitef funciona. Em especial, como ele recebe e requisita as informações. Por isso, se você não leu toda a documentação ainda, seria primordial que fizesse buscando entender esse fluxo de informações. Só depois de fazer isso você vai conseguir compreender o que vou te passar agora. Se você já entendeu isso, vamos pro que talvez esteja faltando... Note no seu log que sempre tem esse par de linhas: -- 29/01 15:25:12:102 - ContinuaFuncaoSiTefInterativo, Chamando: Continua = 1 Buffer = -- 29/01 15:25:12:278 - ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 14 TipoCampo = -1 Buffer = Tam.Min = 0 Tam.Max = 0 A primeira linha indica quais parâmetros foram passados para a função "ContinuaFuncaoSiTefInterativo". Essa função é da DLL do Sitef. A segunda linha indica quais parâmetros a função "ContinuaFuncaoSiTefInterativo" retornou. Ou seja, o que o Sitef retornou. Esse é a parte do meio da interação com o Sitef, onde a mágica acontece. O código no ACBr que cuida dessa parte está na unit "ACBrTEFDCliSiTef.pas" no método "TACBrTEFDCliSiTef.ContinuarRequisicao". Esse é o código que você deve colocar um breakpoint e acompanhar durante o debug, para entender o que está acontecendo. Agora veja essa parte do seu log relacionado a uma transação com ITI: -- 30/01 16:44:44:179 - ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = -- 30/01 16:44:44:257 - ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 21 TipoCampo = -1 Buffer = 1:ITI (ITAU);2:VEE;3:MERCADO PAGO;4:IzPay; Tam.Min = 1 Tam.Max = 2 -- 30/01 16:44:44:267 - BloquearMouseTeclado: NAO -- 30/01 16:44:46:302 - BloquearMouseTeclado: SIM -- 30/01 16:44:46:317 - ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = 1 -- 30/01 16:44:46:420 - ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 14 TipoCampo = -1 Buffer = Tam.Min = 0 Tam.Max = 0 -- 30/01 16:44:46:429 - ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = -- 30/01 16:44:46:511 - ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 22 TipoCampo = -1 Buffer = Pinpad nao suporta exibicao de QR Code Tam.Min = 0 Tam.Max = 0 -- 30/01 16:44:46:520 - CliSiTef DoExibeMsg: Oper: opmOK Mensagem: Pinpad nao suporta exibicao de QR Code Observe que logo depois de passar para o Sitef que a opção era "1:ITI", os próximos retornos foram limpar a mensagem ( ProximoComando = 14) e exibir mensagem que o Pinpad não suporta QR Code. Então, pelo visto, esse módulo do ITI, está esperando que o QR Code seja mostrado pelo Pinpad, e não sua aplicação como já foi comentado. Você pode colocar breakpoints e verificar que é assim que está acontecendo mesmo. Não li a documentação sobre carteiras digitais. Não sei se existe alguma configuração para alterar esse comportamento. É provável que o pessoal da SkyTef possa ajudar a encontrar como informar ao Sitef que a aplicação será responsável por gerar o QR Code e não o Pinpad. Agora vamos a outro exemplo no seu log. Está por volta da linha 551, mas relacionado a carteira VEE: -- 30/01 16:20:23:422 - ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 21 TipoCampo = -1 Buffer = 1:ITI (ITAU);2:VEE;3:MERCADO PAGO;4:IzPay; Tam.Min = 1 Tam.Max = 2 -- 30/01 16:20:23:431 - BloquearMouseTeclado: NAO -- 30/01 16:20:28:474 - BloquearMouseTeclado: SIM -- 30/01 16:20:28:488 - ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = 2 Essa carteira inicia várias outras interações... como pedir o CPF chegando finalmente nessa situação: -- 30/01 16:20:43:385 - ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = -- 30/01 16:21:15:663 - ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 0 TipoCampo = 800 Buffer = E583E9640705D253C568614AAB5ECA370B5A007D Tam.Min = 0 Tam.Max = 0 Pelo que vi no código atual, esse retorno com "TipoCampo = 800" não parece ser tratado de modo especial pelo ACBrTEFD. Posso estar enganado, mas me parece que essa informação que está no Buffer seja relacionada a geração do QR Code. Pode ser por exemplo uma chave de identificação da loja. Por isso você precisa verificar se ao receber o retorno com "TipoCampo = 800" a aplicação deve gerar alguma tela ou fazer algum tratamento especial. Acredito que com essas informações você já tem bastante dever de casa.

Foi o que eu entendi. Mas mesmo que se encontre uma brecha pra não informar no grupo <encerrante>, ainda assim deve ser informado no grupo de observações do contribuinte. Esse é o meu ponto de vista também.

A legislação atual de MG (RICMS) deixa claro que, mesmo que se informe conforme o layout apresentado na NT 2015/002, deve ser informado no grupo de observações do contribuinte a partir da data especificada. O objetivo disso é que saia no DANFe (ou DANFCe). O artigo 36-M da Parte 1 do Anexo V do RICMS, citado no decreto trata-se, do "Documento Auxiliar da NFC-e - DANFE NFC-e". MG está exigindo que as informações sejam impressas no DANFe NFC-e. Teoricamente não seria necessário usar os outros campos, mas pode ser que o objetivo seja deixar bem claro que deve ser impresso no DANFe essas informações.

Essas linhas do log: -- 29/01 15:28:37:950 - ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 0 TipoCampo = 7 Buffer = Tam.Min = 0 Tam.Max = 0 -- 29/01 15:28:37:975 - ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = -- 29/01 15:28:39:179 - ContinuaFuncaoSiTefInterativo, Retornos: STS = -41 ProximoComando = 0 TipoCampo = 7 Buffer = Tam.Min = 0 Tam.Max = 0 -- 29/01 15:28:39:189 - *** ContinuaFuncaoSiTefInterativo, Finalizando: STS = -41 -- 29/01 15:28:39:198 - BloquearMouseTeclado: NAO O retorno -41 é Dados inválidos. Acredito que isso indica que o Sitef estava esperando um tratamento para o TipoCampo 7 que parece ser um menu de pagamento Carteira Digital. Tem que verificar a documentação que você anexou para efetuar os ajustes. Isso não é tão difícil quanto parece. Se você estiver disposto, sugiro que tente verificar.

Parece que sim, mas não tenho certeza. Minha sugestão é você testar no seu ambiente. Ahh sim. Pode ser que exista um novo tipo de tela a ser implementada. Mas a implementação mesmo normalmente é feita na sua aplicação, e não no ACBrTEFD. Essas telas geralmente são passadas no evento onObtemCampo. Talvez só o tipo TACBrTEFDCliSiTefOperacaoCampo precise ser ajustado.

Se ela for semelhante o suficiente a um dos comandos básicos (CRT, CHQ, ADM), basta alterar o código da operação da mesma forma que fazemos para utilizar outros módulos como recebimento de boletos e carga de celulares.

Pelo visto, são módulos do Sitef. Então a ideia é o funcionamento ser bem semelhante ao TEF. Acredito que o termo "Carteira" seja para passar a ideia de um serviço onde você envia dinheiro para ser utilizado depois. Esse dinheiro pode ser recebido também por meio de CashBack como oferecidos em serviços como o Itaú Iti, AME Digital, etc...

Por favor, caso exista, anexe o log do ACBrInstall.

Vai ter que achar alguém que ainda tem esse dinossauro guardado. Acho melhor vocês seguirem a ideia do Daniel e focar em substituir a funcionalidade desse componente.

Se ainda não tiver feito isso, procure a informação na página do SAT da SEFAZ de SP. Ao fazer isso, lembre-se que é diferente desenvolver uma aplicação para SAT e ter uma aplicação SAT na sua empresa. Veja esse link: https://portal.fazenda.sp.gov.br/servicos/sat/Paginas/Sobre.aspx

Olá, Adicionei aqui na nossa lista de afazeres. Vamos verificar e dar um retorno.

Olá, Já adicionamos em nossa lista de afazeres. Vamos verificar e dar um retorno.

Olá, Já adicionamos em nossa lista de afazeres. Vamos verificar e dar um retorno.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 18898. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Conforme atendimento via Chat do ACBr, o problema foi resolvido.

Nesse modelo houve alterações em Novembro. Veja o seguinte tópico:

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

300 dpi me parece ser o normal em impressão de qualidade. E se está normal em outros modelos, então não é o conflito com isso mesmo. O que eu notei, é que seu PDF está sendo gerado com fontes diferentes do padrão. Veja o seu arquivo xml impresso pelo comando GerarPDF do componente no Lazarus (Win32) numa máquina de testes (Win 64): 33190818149710000143550010000038711000028728-nfe.pdf

O ACBrSPED não gera registros automaticamente. Se você não criar os registros no seu código, ele não vai fazê-lo.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 18891. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 18890. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 18889. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 18889. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Por acaso não está trocando o modelo "Toledo 2090" pelo modelo "Toledo 2090N"?

Como assim?