Cleber Ferreira

@Jemison Vidal coloquei 20 tentativas e um intervalo entre as mesmas de 10000.

Bom dia, Eu estava tendo esse problema com o provedor WebISS. O xml era enviado, mas como o time do componente estava baixo não dava tempo do webservice retornar a autorização. Tinha que disparar a consulta depois. Aí fui nas propriedades do ACBrNFSe e aumentei o numero de tentativas e o intervalo entre cada consulta. Depois disso, passou a funcionar perfeitamente.

É isso mesmo Ítalo. Desconsidere minha observação. Grato.

09/09 sao as MFB, correto? no MS também já está lacrando somente elas. Ex: MP 4200 TH FI

Aparece no nome do arquivo pdf. Exemplo: 2016000000000101-nfse.pdf Uso o FortesReport

Perfeito Italo! Testei as rotinas de emissão, cancelamento e consulta. Só uma observacao com relação a impressão da DANFS-e. No PDF gerado ta sendo acrescentado o numero "1" ao final. Não seria interessante retira-lo?

Hoje fui atualizar minha rotina de emissão de nfs-e e reparei nessa questão também. A sugestão do Dercide é muito boa. Entretanto vamos aguardar uma posição do Ítalo. Até porque os dados da nfs-e já vem assim dos webservices e, alterar esses dados, mesmo que seja pra corrigir acentuação, pode invalidar a assinatura ao meu ver.

Essa taxa de serviço deve ser considerada como acréscimo no cupom?

Poxa Daniel, agora fui muito inocente nessa...kkkk. Nem me passou pela cabeça que o problema era com a ECF, ainda mais com uma função tão básica do equipamento. Pensei que fosse algum evento do ACBrECF ou ACBrTEFD que eu esqueci de programar, ou algum outro tratamento nos meus fontes. E faz certo sentido mesmo. Reparei que quando acaba o papel e eu troco ele, a ECF fica com o led de erro piscando. Só resolve se eu desligar e religa-la. Valeu pela observação.

bom dia, Estou realizando alguns testes de fim de papel para homologar o SiTef, porém não ocorre retorno da ECF. Vejam uma parte do log que é retornado: -- 14/04 10:11:10:357 LinhaCupomVinculado( [CR][LF].....S...I...M...U...L...A...D...O....[CR][LF] [CR][LF] ) -- 14/04 10:11:10:358 TX -> [STX][142][14][ESC][STX][FS][NUL][NUL][FS] [ETX]0116 -- 14/04 10:11:10:363 RX <- ACK = 6 -- 14/04 10:11:10:475 RI- -- 14/04 10:11:10:808 RI- -- 14/04 10:11:11:142 RI- -- 14/04 10:11:11:463 RI- -- 14/04 10:11:11:797 RI- -- 14/04 10:11:12:131 RI- -- 14/04 10:11:12:454 RI- -- 14/04 10:11:12:788 RI- -- 14/04 10:11:13:122 RI- -- 14/04 10:11:13:444 RI- -- 14/04 10:11:13:778 RI- O que seria esse retorno? Reparei que entra em um looping. Só fica retornando esse "RI".

1 - Basta entrar em contato com as homologadoras: Software Express, Cappta, NTK. Todas elas vão te fornecer a documentação necessária; 2 - Das 3 empresas homologadoras, o SiTef é o único que permite isso que vi até agora. Me corrijam se eu estiver errado. O menu de opções das outras são apresentados pelo próprio gerenciador delas. Mas não vejo isso como ponto negativo. 3 - Cada empresa homologadora das citadas acima tem seu próprio gerenciador a ser instalado. Esse gerenciador para nós é um simulador que abrange todas as situações encontradas em um ambiente de produção.

Deixa eu entender. Até então você comercializa seu PAF no Estado do PR pelo que entendi? Em que exatamente você precisa de ajuda?

Daniel, Esse controle pra mim serviu perfeitamente. Vi que tinha ele no Demo, mas só depois fui associar o código com a aplicabilidade dele. Grato. Como sempre prestativo.

Ele pede pra confirmar e depois acionar o ADM para imprimir novamente o comprovante

Bom dia, estou realizando os testes para homologar o SiTef e na sequencia 27 é pedido para que faça uma transação e no meio da impressao do comprovante resetar o computador e desligar a ecf. Quando o computador reinicializar é pedido para abrir o paf-ecf ainda com a ecf desligada. O objetivo do teste é confirmar a transação tef pendente. Aí entra o comportamento do ACBrTEFD. Ao ser inicializado ele dispara o evento OnInfoECF para retornar o status atual da mesma. Como a ecf ainda está desligada o retorno é "Outros" representado pela letra "O". Olhando a unit ACBrTEFDCliSiTef no método inicializar quando é retornado o status "Outros", o comportamento atual é cancelar as transações pendentes. // Cupom Ficou aberto ?? Se SIM, Cancele tudo... // if (Est in ['V','P','N','O']) then CancelarTransacoesPendentesClass else // NAO, Cupom Fechado, Pode confirmar e Mandar aviso para re-imprimir // ConfirmarESolicitarImpressaoTransacoesPendentes ; Nesse caso, para atender ao teste, poderia ser retirado o status "Outros" da condicional para cancelar? Isso traria alguma anomalia futura em outro comportamento do componente? Ficaria dessa forma: // Cupom Ficou aberto ?? Se SIM, Cancele tudo... // if (Est in ['V','P','N']) then CancelarTransacoesPendentesClass else // NAO, Cupom Fechado, Pode confirmar e Mandar aviso para re-imprimir // ConfirmarESolicitarImpressaoTransacoesPendentes ; Ou talvez há alguma outra forma de contornar a situação? Grato.

Boa tarde Atualmente eu utilizo controle de instâncias nas minhas aplicações ou seja, não deixa abrir o software caso o mesmo já esteja em execução.Funciona blz se for o mesmo usuário que estiver logado. No Windows server onde pode ter vários usuários logados ao mesmo tempo, o controle não funciona. Alguém tem alguma dica de como contornar isso?

Fazendo mais testes aqui, notei que acontece somente com cartões de bandeira visa (credito ou debito). Bandeira master funciona perfeitamente.

Comecou a acontecer isso comigo uma vez quando migrei para o trunk2, mas no meu caso descobri o que era. Como os componentes ACBr ficam em um DataModule separados, eu não cheguei a abrir esse mesmo depois que migrei, mas apenas as outras units do projeto onde precisei fazer alterações no código. Compilei, executei e em seguida fechava sozinho. Aí por curiosidade abri o DM onde estavam os componentes ACBr e de imediato o Delphi me acusou a falta de algumas propriedades de alguns componentes (NF-e, CT-e). Creio que por causa do enxugamento que o pessoal fez nos componentes. Depois de clicar em Ok nessas mensagens, compilei novamente o projeto e executei. Dessa vez funcionou sem problemas.

Boa tarde, Eu iniciando as adaptações e testes para homologar o SiTef daqui a alguns dias e me deparei com um comportamento um pouco estranho do ACBrTEFD . Ao fazer uma transação com cartão de debito, todo o fluxo ocorre normalmente. Esse fluxo é: 1 confirmada a transação 2 apresenta mensagem de transação ok 3 finaliza cupom 4 inicia impressão da primeira via 5 apresenta a mensagem pra destacar a primeira via 6 inicia impressão da segunda via 7 encerra todas as mensagens na tela A parte estranha ocorre quando faço uma transação com cartão de credito. A etapa 5 (destacar a segunda via) não ocorre. A mensagem pedindo pra destacar a via não é exibida. Somente fica sendo exibida a mensagem da etapa 2 (transação ok) e após a etapa 7, continua sendo exibida a mensagem da etapa 2. Outra coisa que reparei é que em todas as transações (independente se é credito ou debito), a mensagem ao operador e ao cliente ficam sendo exibidas ao mesmo tempo na tela. Todas essas questões ocorrem somente utilizando o modulo do SiTef. Nos demais módulos homologados que tenho aqui (Pay&Go e Cappta) tudo funciona perfeitamente. Há e lembrando que fiz testes na minha aplicação e fiz no Exemplo do ACBrTEFD também. Alguém já passou por isso? Att.

Boa tarde, Eu homologuei meu TEF com a Cappta a poucas semanas. O suporte deles para desenvolvedor achei muito prestativo. Se bem que não precisei muito por causa do ACBrTEFD. E como eu já sou homologado para o Pay&Go as mudanças que precisei fazer foram mínimas. Inclusive me enviaram um pin-pad na velocidade da luz para que eu pudesse fazer os testes. Gostei mesmo do atendimento deles. Com relação ao produto em si, no caso o CapptaGpPlus, eu achei ele um pouco problemático. As vezes trava a comunicação com os servidores deles, às vezes perdia comunicação com pind-pad. Nesses casos tinha que reiniciar o teste. Por falar em teste, alguns deles que constam no roteiro de homologação espera-se um comportamento. Mas quando o mesmo é realizado o resultado é outro. Há uma incoerência realmente nos testes. Agora com relação ao tratamento que dão aos revendedores, não posso opinar, pois meu interesse é apenas em homologar. Se você for levar adiante a homologação, basta você configurar o ACBrTEFD para TefDial. Espero ter ajudado de alguma forma.

Bom dia! Eu utilizo Zeos em todos os meus projetos em Delphi. Nunca tive problemas com o componente em si. É simples utilizar e possui compatibilidade com diversos DB's do mercado. O que você precisa fazer é analisar quais recursos vc utiliza no IBX e simular no Zeos. Eu particularmente acho o Zeos mais objetivo. O FireDAC é ótimo também, inquestionável (ainda mais pra trabalhar com Rest e JSON), mas tem que carregar outros componentes junto além de declarar certa quantidade de classes também.

De acordo com a versão 1.60 da NT, NÃO soma FCP ao DIFAL.

Boa tarde, Tenho um cliente que usa, se nao me engano a velocidade da porta é 4800. Ja tentou?

Boa tarde romyllldo, é isso aí mesmo que pode ser feito quando há essas particularidades. Quanto a impressão das vias Jefferson, precisei alterar nos fontes do acbrtefd para considerar apenas as vias que vem no 713 e 715. O estranho também é que ao emitir via especifica da loja, não imprimia nada. Aí eu localizei nos fontes o problema.fiz umas alterações, quem se interessar, vou deixar o arquivo aqui. ACBrTEFDClass.pas Só destaco que hoje terminei de fazer os testes para a Cappta. Agora vou aguardar as 48hrs pra saber o resultado.

Boa noite! Testei essas suas alterações aqui e funcionaram perfeitamente. Salvou o dia de trabalho...rsrsrs