Jump to content

brsamn

Membros
  • Content Count

    153
  • Joined

  • Last visited

Community Reputation

17 Good

About brsamn

  • Rank
    Membro
  • Birthday December 19

Profile Information

  • Localização
    SP

Recent Profile Visitors

988 profile views
  1. Boa tarde. Não tinha me atentado a isso. Agora deu certo. Muito obrigado, @Daniel Simoes!
  2. Boa tarde Baixei e recompilei o pacote, mas continua da mesma forma. Os procedimentos SetEchoMode e SetPasswordChar (que foram alterados) são chamados apenas na criação. No momento em que a variável é alterada no evento OnRecebeDados, nada é feito pra mudar o PasswordChar, que sempre fica #0.
  3. No demo ocorre o mesmo, quando altero a variável EchoMode o que digito não é mostrado no Microterminal procedure TForm1.ACBrMTer1RecebeDados(const IP, Recebido: String; var EchoMode: TACBrMTerEchoMode); begin EchoMode:= mdePassword; mOutput.Lines.Add('IP: ' + IP + ' - Recebido: ' + TranslateUnprintable( Recebido ) ); if (PageControl2.ActivePageIndex = 1) then AvaliarRespostaTerminal(IP, Recebido); end;
  4. Analisando aqui percebi que, mesmo alterando o EchoMode do evento, em TACBrMTer.DoRecebeDados na unit ACBrMTer, na parte destacada no comentário (na antepenúltima linha) ele chega com a propriedade PasswordChar como #0, que é o char do mdeNormal. procedure TACBrMTer.DoRecebeDados(const aIP: String; const DadosRecebidos: AnsiString); var wEchoMode: TACBrMTerEchoMode; wConexao: TACBrMTerConexao; DadosEcho: String; begin if (Length(DadosRecebidos) < 1) then Exit; wConexao := fConexoes.Conexao[aIP]; if not Assigned(wConexao) then Exit; GravaLog( 'Terminal: ' + aIP + ' - RecebeResposta: ' +IntToStr(Length(DadosRecebidos)) + ' bytes -> '+ DadosRecebidos, True); wEchoMode := EchoMode; if Assigned(fOnRecebeDados) then begin GravaLog( ' OnRecebeDados'); OnRecebeDados(aIP, DadosRecebidos, wEchoMode); GravaLog( ' EchoMode: '+GetEnumName(TypeInfo(TACBrMTerEchoMode), Integer(wEchoMode))); end; DadosEcho := fMTer.LimparConteudoParaEnviarEcho(DadosRecebidos); case wEchoMode of mdeNormal : fMTer.ComandoEco(wConexao.Comandos, DadosEcho); mdePassword: fMTer.ComandoEco(wConexao.Comandos, StringOfChar(PasswordChar, Length(DadosEcho))); // <----- Aqui end; end; Acredito que talvez seja necessário chamar o SetEchoMode nesse momento, passando como parâmetro o wEchoMode. O que acha? Obrigado.
  5. Bom dia. Eu havia visto essa sugestão em outro post mais antigo e tentei implementar, mas por algum motivo após alterar o EchoMode no evento, quando digito no Microterminal nada é exibido, embora a informação seja passada corretamente. Estou analisando aqui pra ver se encontro o motivo. Obrigado.
  6. Boa tarde. Tenho múltiplos microterminais em uso e quero colocar o * para os campos de senha. Quando passo o EchoMode de password pro Microterminal que está na etapa de senha, isso é refletido em todos os outros microterminais, não importando em que etapa do lançamento eles estão. Alguém tem alguma sugestão de tratamento pra isso? Obrigado.
  7. Boa tarde. Analisei aqui mas não localizei nada no log referente a versão dos dados, nem dizendo que é 0.07 ou 0.08.
  8. Boa tarde. Tenho um cliente com um SAT da Tanca, atualizado para a versão 0.08. O meu sistema está compilado com a versão mais recente do ACBr e informado o 0.08 em Config.infCFe_versaoDadosEnt. Quando tento fazer a emissão do CFe me é retornado o erro Versão do leiaute do arquivo de entrada do SAT não é válida de acordo com a Tabela de Vigência de Leiaute. Li alguns outros tópicos aqui no fórum relatando este mesmo problema e que a solução seria usar um comando CFeConsultaGestao para baixar os dados do leiaute, mas que mesmo com esse comando ainda poderia ocorrer o erro, que, em outro caso que li, foi necessário trocar o SAT. Sobre esse CFeConsultaGestao não compreendi se eu tenho que faze-lo (não achei nada no ACBr a respeito disso) ou se isso é um comando que é rodado no momento da atualização. Alguém já passou por esse mesmo erro e pode me ajudar? Obrigado.
  9. Boa tarde Estou com o mesmo problema em um SAT da Tanca. Esse CFeConsultaGestao é executado no momento da atualização do software do SAT, porque no meu log eu não encontrei. Obrigado.
  10. Bom dia. Alterei os fontes pra adicionar o novo Provedor SigCorp. Criei um arquivo para ele, baseado em outro que usa a versão 2. Tive alguns erros que fui solucionando, mas acabei parando nesse: Server was unable to process request. ---> Object reference not set to an instance of an object. Sigo tentando aqui, mas gostaria de saber se já viram esse erro. Obrigado.
  11. Boa Tarde A cidade de Avaré/SP utilizava o Provedor Fiorilli para emissão de NFSe, porém no próximo mês será alterada para a Empresa SIGCORP. Procurei nas pastas de exemplos se existia, aparentemente não. Eles enviaram os links de homologação e produção e fiz ajustes no atual arquivo da Fiorilli para testar, porém sem sucesso.Estou anexando o manual com os Links que eles enviaram juntamente como arquivo que editei para testar, se possível gostaria de um auxílio neste teste. Obrigado. Manual Webservice ABRASF Avaré.pdf Fiorilli.INI
  12. Bom dia. Diretamente eu acredito que não exista como. O que fiz quando solicitado (logo no início da obrigação) foi uma espécie de servidor pra receber as solicitações dos terminais e fazer a emissão do CFe, mas não recomendo isso mais aos nossos clientes, sempre digo para terem um SAT por terminal. O projeto que fiz está quase abandonado, apenas um cliente segue usando. Obrigado.
  13. Bom dia. Fizemos a desinstalação e reinstalação do driver do SAT (Elgin), atualizamos o software do SAT (embora acredito que não tinha o que atualizar) e verificamos a DLL (que já era a última versão disponível). Após fazer isso o problema parou. Sinceramente não sei se o que fizemos teve a ver com a resolução do problema (ou se resolveu ele se resolveu sozinho), mas fica a dica pra se alguém passar por isso tentar fazer o mesmo que fizemos. Obrigado.
  14. Boa tarde. A partir de hoje (12/11/2018) em um dos meus clientes começou a ocorrer um problema na emissão dos SAT. Sempre que ele manda emitir um cupom, o cupom impresso é o anterior. Analisando o ACBrSAT.Log percebi algo bem estranho. A partir de hoje começou a dar um erro de "ERRO: Sessao retornada pelo SAT [nnnnnn], diferente da enviada [nnnnnn]." O número da sessão retornada é sempre o número da enviada no cupom anterior, e assim sucessivamente. Li algumas dicas para habilitar a opção "ValidarNumeroSessaoResposta" do componente do SAT, após fazer isso e tentar fazer a emissão obtive a seguinte mensagem de erro: "SAT em processamento. Tente novamente.". Verifiquei o log e ele apresentou o mesmo erro de "ERRO: Sessao retornada pelo SAT [nnnnnn], diferente da enviada [nnnnnn].", mas mesmo assim gerou o cupom. Ainda sobre o log, os dados sempre são enviados corretamente, são enviados os da venda que realmente quero emitir. Alguém já passou por isso? Obrigado.
×
×
  • Create New...