Rodrigo Fruhwirth

Entendi perfeitamente. E isso somente para o Sitef ou tem alguma possibilidade de ser refletido nas demais?

Deixa eu ver se entendi, No roteiro que eu passei a confirmação é feita somente após o termino da emissão do cupom fiscal, ou seja, fechou o cupom e abriu o relatório gerencial ou CDC para emissão dos comprovantes. Acredito não haver modificações com relação as operações de cartão antes do fechamento do cupom. Você tem teria o roteiro de homologação para compartilhar conosco?

Boa tarde. Exatamente, acho bem melhor essa solução, não tenha dúvida.

Bom dia colegas. Adicionei nova propriedade em TEFDial para saber se ao inicializar deve confirmar ou cancelar as transações pendentes, deixando como padrão cancelar que é o padrão. ACBr_TEFD-change-log.txt ACBrTEFDDial.pas

Bom dia colegas, gostei da atualização sugerida só que na Epson ainda não estava funcionando. Envio correção. Quero pedir também que tomem um pouco de cuidado ao comitar os códigos pois as units ACBrTEFD e ACBrTEFDClass ainda estavam com a property CodigoAutorizacaoTransacao como Integer ao contrário do que diz a alteração publicada em www.projetoacbr.com.br/forum/index.php?showtopic=33615 ACBrSerial-change-log.txt ACBrECFEscECF.pas

Pessoal, alguém esta conseguindo gerar o CAT 52 da Epson através do ACBr? O que ocorre é que no método CriarECFClassPorMarca da unit ACBrECFEscECF quando é Epson temos o seguinte trecho de código: end else if IsEpson then begin Result := TACBrECFEpson.create(fpOwner); Result.Device.Desativar; fsDeviceParams := fpDevice.Porta+':'+fpDevice.ParamsString; Result.Device.Porta := 'USB'; // Força DLL em USB Result.Device.Baud := 115200; end; até aqui tudo certo, o que ocorre é que na método TACBrECFClass.PafMF_GerarCAT52 temos a leitura do número de série da ECF para uma variável. NumSer := NumSerie; E aqui ocorre o erro: Communication Error 6: Identificador Inválido. Alguém teria alguma ideia ou teríamos que mudar a assinatura do método e passar o número de série ainda pelo método TACBrECF.PafMF_GerarCAT52(const DataInicial, DataFinal: TDateTime; const DirArquivos: String); ???

Sim, sim, concordo, outra coisa que eu estava pensando em fazer, seria talvez, no lugar de criar uma nova classe para isso, ter a possibilidade de escolher no TEF_DIAL se é para cancelar as transações ou confirmar, o que vocês acham? Claro que deixando como padrão o que é hoje. Cancelamento de forma compulsória.

Bom dia Daniel. Pensando pelo lado de controle sim, mas pensando pelo lado de compatibilização com outras ferramentas de TEF não, pois várias delas utilizam o padrão SITEF com gerenciador para fazer suas transações. Quanto ao fato de ser da Software Express ou da SkyTEF, eu acredito ser da SkyTEF o qual é homologado pela Software Express. Mas minha dúvida seria se eu posso criar esse novo módulo.

Boa tarde amigos colaboradores. Tenho uma questão aqui e gostaria da sugestão do grupo. Nós temos a homologação do SkyTEF com o ClientModular deles, esse client se comporta quase igual ao TEFDial, a única diferença entre eles é que no SkyTEF Modular quando falta energia no retorno o roteiro pede que as transações sejam confirmadas e não canceladas. O que nós estamos pensando em fazer: Criar uma Classe ACBrTEFDSkyTEFModular que no inicializar faça as operações de confirmação / cancelamento de acordo com o estado da ECF parecido com o ACBrTEFDCliSiTef. Só antes de fazer isso gostaria da opinião da grupo e ver se alguém tem uma outra ideia. Segue manual de homologação da SkyTEF Modular. Os passo que me refiro são as sequencias 20, 21 e 22. Roteiro de Pré Homologação Client Modular_V12.docx

OK, Obrigado.

Daniel, você quer que eu deixe o código da forma como me mencionou e efetue os testes?

Claro, pode ser.

Por exemplo, no arquivo de resposta do TEF retorna assim 010-000: MASTERCARD 010-005: 549329 esse 549329 estava indo no nome da rede. Se quiser pode testar a operação com o número de cartão. 5493 2905 2036 2146

Não estava preenchendo corretamento o nome da rede nos casos em que no arquivo de resposta retornasse registros tipo 010-xxx 010-005 que não fosse o 010-000. ACBr_TEFD-change-log.txt ACBrTEFDClass.pas

Boa tarde, implementei o download da MF e MFD da X5 que é a única que eu tenho na bancada. Quero ver se consigo fazer da ZPM/1-FIT LOGGER e da Dataregis, mas ainda não estou com as ECFs, assim que tiver elas em mãos implemento. ACBrSerial-change-log.txt ACBrECFFiscNET.pas

Como prometido, segue manual. Seq. 6, 7, 8 e 9. Quanto a implementar na DLL ai não sei, porque não utilizamos comunicação com DLL ainda, nesse caso eu não teria homologação prevista para implementar. Roteiro de Pré Homologação Client Modular_V12.docx

Sim, tenho sim. Essa operação independe de gerenciador ou bandeira, todas elas tem, mas eu testei no gerenciador da SkyTEF e da CAPTA. Essa operação de PRE-AUTORIZAÇÃO é o ramo de atividade da empresa que solicita quando faz o contrato com a bandeira, muito utilizado nos ramos de materiais de construção, hotelaria e aluguel de veículos e não necessariamente só por esses. Lembrando que a PRÉ-AUTORIZAÇÃO é opcional de homologação, assim como venda de recarga de celular e outros. Estou solicitando um roteiro novo da software express porque o último que eu tenho não está mais disponível para download. Assim que eu tiver o roteiro em mãos envio.

Ótimo, eu não quis fazer dessa forma para não criar impacto em operações as quais eu não testei mas por mim ficou ótimo assim.

De qualquer forma porque se mandarmos uma string muito grande para a ECF no fechamento do cupom e a expressão do PAF for adicionada a observação, a mesma deve ser remontada para caber dentro das 8 linhas. Que no exemplo acima a string de fechamento fica com 10 linhas apresentando erro que excedeu o número de linhas.

Boa tarde, estou enviando uma correção para a FiscNET com a seguinte situação. Quando no método fechaCupom enviamos a string: 'MINAS LEGAL: 03600477000104 03112016 14000'#$A'Trib aprox R$:18,83 Federal e 16,80 Estadual'#$A'Fonte:IBPT Ar5Fr7'#$A'SDLFK JSADLKJF HSLDKJF HSKJLD FSADLKJ FSKLDJ '#$A'FSKLJD FHSKLJDAF HSLKDAJF SAKLDJF SKALDJF '#$A'SKALDJF SADKL'#$A'0000002280 '#$A'38440-171-ARAGUARI-MG-'#$A E os dados do PAF não estão dentro da observação de fechamento e somente em fsPAF temos a seguinte situação: if (fsPAF <> '') and (pos(fsPAF,Obs) = 0) then begin if Obs = '' then Obs := fsPAF else Obs := fsPAF + #10 + Obs //Aqui poderá excede o número de linhas da ECF pois em nenhum momento após isso estamos nos preocupando novamente com o número de linhas resultantes dessa operação. end ; Para tal mudei o código para: if (fsPAF <> '') and (pos(fsPAF,Obs) = 0) then begin if Obs = '' then Obs := fsPAF else begin Obs := fsPAF + #10 + Obs ; Obs := AjustaLinhas(Obs, Colunas, NumMaxLinhasRodape); end; end ; ACBrSerial-change-log.txt ACBrECFFiscNET.pas

Todas, todas as soluções tem a operação de PRÉ-AUTORIZAÇÃO, basta que seja habilitado junto a operadora de cartão, por exemplo: Uma locadora de veículos, um hotel ou até mesmo no nosso caso vendas em consignação, emprestimos, etc. Em conversa com a Software express isso depende do ramo de atividade da empresa e do PIN do cartão para que seja possível permitir essa operação.

Boa tarde, implementei a chamada da pré-autorização sem a necessidade de entrar no módulo ADM. ACBr_TEFD-change-log.txt ACBrTEFD.pas ACBrTEFDClass.pas

Quando na Daruma MFD (FS700) ou superior temos na lista das alíquotas cadastradas da seguinte forma. T01 = 7% T03 = 12% T04 = 17% Pulando o T02 ao mandarmos o comando vendeItem com a aliquota 17,00T o componente esta vendendo a 12% porque. Porque no carrega alíquota esta assim. Aliquota.Indice := IntToStrZero(fpAliquotas.Count+1, 2); e deveria ser Aliquota.Indice := IntToStrZero(Cont, 2); Porque mesmo não tendo a alíquota cadastrada na ECF mesma assim o índice pula. ACBrECFDaruma.pas ACBrSerial-change-log.txt

Blz, show de bola, até ai esta tudo 100%, o problema é quando a ECF da erro nos totalizadores/alíquota, nos casos onde a memória da ECF esta com lixo por problemas de queda de energia que no percentual retorne caracteres estranhos, só por isso, ai se der algum erro na alíquota 1 por exemplo as demais alíquotas não são carregadas. Tirando isso a regra vai funcionar.

Desculpa Daniel, mas acho que você não entendeu o caso, vou te mandar o log da ECF. 15/09/2016 10:52:06.265 -> {103;LeAliquota;CodAliquotaProgramavel=1;40} 15/09/2016 10:52:06.296 <- {103;0;AliquotaICMS=Y CodAliquotaProgramavel=1 DescricaoAliquota="7,00%" PercentualAliquota=7,00;96} 15/09/2016 10:52:09.965 -> {104;LeAliquota;CodAliquotaProgramavel=2;40} 15/09/2016 10:52:09.996 <- {104;0;AliquotaICMS=Y CodAliquotaProgramavel=2 DescricaoAliquota="" PercentualAliquota=17,00;92} 15/09/2016 10:52:12.890 -> {105;LeAliquota;CodAliquotaProgramavel=3;40} 15/09/2016 10:52:12.921 <- {105;0;AliquotaICMS=Y CodAliquotaProgramavel=3 DescricaoAliquota="" PercentualAliquota=25,00;92} 15/09/2016 10:52:15.616 -> {106;LeAliquota;CodAliquotaProgramavel=4;40} 15/09/2016 10:52:15.644 <- {106;8005;NomeErro="ErroCMDAliquotaNaoCarregada" Circunstancia="Aliquota nao carregada";87} 15/09/2016 10:52:18.451 -> {107;LeAliquota;CodAliquotaProgramavel=5;40} 15/09/2016 10:52:18.483 <- {107;8005;NomeErro="ErroCMDAliquotaNaoCarregada" Circunstancia="Aliquota nao carregada";87} Como é um for de 0..15 sempre, sempre, sempre irá dar esse erro exceto se a ECF estiver com 100% das alíquotas cadastradas. Vou anexar até o print do demolog2 para comprovar.