Data Lider

Teoricamente se o processo está sendo executado corretamente pela ACBr, e o congelamento que você diz é devido ao tempo de execução, então cabe a você tratar isso na sua aplicação, no mínimo usar Thread para processos mais demorados.

No caso você usa o ACBrMonitor? se não, porque não pega o retorno diretamente da ACBr em vez de carregar o arquivo?

Contextualizando Prezados, devido nossa aplicação ser em 3 camadas, a parte de assinatura do XML fica em uma aplicação externa em outra linguagem de programação, e no que diz respeito a parte de ENVIO basta mencionar o excelente trabalho que o projeto fez com a WinCrypt. obs: se você não sabe o porque de fazermos assim, segue o tópico EXCELENTE do Daniel O Problema Essa semana obtivemos um certificado A3 da Perto (SmartCard) e ele está pedindo PIN no servidor, e no DEBUG descobri que não era na nossa rotina de assinatura mas sim no momento do envio pela ACBr. A Causa Na unit "ACBrNFeNotasFiscais.pas", na linha 252, onde temos: TACBrNFe(TNotasFiscais(Collection).ACBrNFe).SSL.ValidarCNPJCertificado( NFe.Emit.CNPJCPF ); 1º Ele acaba inicializando todo contexto e enviando o PIN para o SmartCard (ou Token) previamente, antes da assinatura e antes do envio. 2º Quando o evento "OnAntesDeAssinar" é disparado nosso código externo realiza a assinatura do XML nessa biblioteca externa. 3º (Não tenho certeza) É provável que ao adquirir o contexto do certificado A3 nessa aplicação nossa, e enviar o PIN tem removido o contexto da ACBR ou algo semelhante, isso já vai um pouco além do que conheço do assunto. 4º Quando o código volta para a ACBR realizar o Envio, a janela de PIN aparece. 5º Quando debugando eu faço um Jump para a próxima linha pulando a linha 252 conforme destacada acima, tudo funciona normalmente, porque não houve um contexto anteriormente adquirido acima, então no momento do envio o código para obter a chave privada funciona como se fosse executado a primeira vez. Obs: CertFreeCertificateContext também é chamado em nossa aplicação depois da assinatura do XML ser concluída, e o Store dos certificados é fechada. Possíveis Soluções Aqui que venho pedir ajuda ao pessoal responsável pelo projeto para não fazer alterações desnecessária ou que não serão aceitas. De imediato pensei em para as pessoas que assinam os XMLs em aplicações externas fica a responsabilidade da validação do CNPJ e o certificado, assim adicionando uma verificação se o evento OnAntesDeAssinar está "Assigned" antes linha 252 e resolvendo esse problema. Ou então a rotina que verifica se o CNPJ é o mesmo do certificado não realizar o envio do PIN quando o tipo for A3 por exemplo // Talvez adicionar um parametro padrão como TDFeWinCrypt.CarregarCertificado; Para TDFeWinCrypt.CarregarCertificado(const EnviarPinSeExistir: Boolean = True); E aqui seguindo a lógica de enviar o parâmetro falso para o CNPJ, até chegar na unit que verifica se os dois CNPJ são os mesmos. function TDFeSSLCryptClass.GetCertCNPJ: String; begin CarregarCertificadoSeVazio(False); Result := FpDadosCertificado.CNPJ; end; Desculpe se ficou muito extenso.

Seria melhor excluir esse aqui, não tinha me tocado nesse tópico. Obrigado.

Prezados, gostaria de registrar aqui, que passamos na homologação do TEF da NTK usando o componente da ACBr + Firemonkey. Lembrando que se for fazer os testes do TEF em FMX existe um item para ser levantado ainda que está esperando análise, você pode baixar o arquivo no post abaixo em quanto isso.

Ola Daniel, hoje estamos finalizando os testes do TEF, e a única coisa que ficou pendente era o foco da aplicação, que não estava funcionando corretamente, as vezes funcionava as vezes não, então testamos vários códigos, com api ou sem api, e o melhor resultado para o firemonkey + windows segue em anexo. ACBrTEFD.pas

Nossa solução utilizando o evento "AntesFinalizarRequisicao(Req: TACBrTEFDReq);" if MatchText(Req.Header, ['CRT', 'ADM', 'CNC']) then begin { Soma dos seguintes valores, identificando as funcionalidades suportadas pela Automação Comercial: 1: funcionalidade de troco (ver campo 708-000) 2: funcionalidade de desconto (ver campo 709-000) 4: valor fixo, sempre incluir 8: vias diferenciadas do comprovante para Cliente/Estabelecimento (campos 712-000 a 715-000) 16: cupom reduzido (campos 710-000 e 711-000) Caso este campo não seja informado pela Automação Comercial (versões anteriores), considera-se que nenhuma das funcionalidades é suportada. Importante: na certificação da CIELO, é exigido que a Automação Comercial implemente a funcionalidade de desconto. } if Tipo = gpTefDial then Req.GravaInformacao(706, 0, '15'); end; A via reduzida de impressão dentro do cupom pode ser informada como não suportada pela sua aplicação! Como os colegas aqui da ACBR falaram, em alguns estados é tanta coisa para imprimir nas observações, que é impossível adotar a via no cupom fiscal. E cuidado confundir via reduzida no cupom, com via completa "curta", são duas coisas diferentes.

Obrigado por subir, faltou apenas o "ACBrTEFDVeSPague.pas" , falta minha não ter compactado desculpa.

Prezados, a um tempo fiz as alterações, estou encaminhando aqui para subir. As alterações necessárias foram poucas, ou quase nada, se trata mais de algumas constantes que no firemonkey se encontram em outros arquivos, e a questão de puxar a janela para a frente que muda um pouco. ACBrTEFDClass.pas ACBrTEFDCliDTEF.pas ACBrTEFDCliSiTef.pas ACBrTEFDTicketCar.pas ACBrTEFDVeSPague.pas ACBrTEFD.pas ACBrTEFDBanese.pas

A pouco desisti da homologação com eles, no primeiro contato, foi me dito que era totalmente gratuito, que a homologação não tinha custos (isso no telefone), e eles mandavam o pin pad. Então pedi o manual, eles disseram que os documentos e as outras informações apenas quando o PIN PAD chegar na empresa. Pois bem , o PIN-PAD chegou, avisei por e-mail, um rapaz entrou em contato dizendo que era obrigatório o acesso remoto na máquina para instalação dos programas, e que a senha não poderia ser passada, pois bem, avisei que não era permitido acesso remoto em máquina de desenvolvimento e crie uma máquina virtual para ele fazer as instalações. No outro dia, quando ele foi acessar, ele disse que se eu não finaliza-se toda as alterações em 30 dias, seria cobrada uma taxa de mais de 500 reais, e então ele teria que rê-instalar tudo novamente, e reiniciar o prazo, que eventualmente geraria outra cobrança se não respeitado. E caso eu instala-se e desistisse com 2 dias, porque não mostram nada do software deles, eles só dão informação quando instala, eu teria que pagar a taxa do mesmo jeito no caso da desistência. E no final da conversa, para fechar com chave de ouro, ele disse que o software precisa estar online para funcionar, então se eu for homologar em algum local, e esse não constar conexão com internet, ou ela apresentar algum problema, eu vou ficar sem fazer os testes do PAF referente ao TEF!!!!. E se até o dia da homologação do PAF eu querer trocar de máquina o TEF, eles teria que acessar novamente e fazer uma outra instalação e remover a anterior. Resumo, essas informações só foram passadas para mim quando o PIN PAD chegou, me recusaram passar qualquer informação até o momento.

Consegui uma resposta de uma homologadora da Pay&GO, referente a BANDEIRA do cartão utilizado, eles mandaram uma planilha com todos os possíveis retornos do campo 040 (Como o coleta Celso havia dito!!!), e informaram que este campo deve ser utilizado, a fim de atender apenas a NFC-e eu realizei o seguinte código: procedure XXXXXXX.NFCeIdentificaBandeira(const ItemResposta: TACBrTEFDResp); const VISA: array [0 .. 4] of string = ('VISA Crédito' , 'VISA Electron' , 'VISA Crediário' , 'VISA Electron' , 'VISA Parcelado Loja'); MASTERCARD: array [0 .. 1] of string = ('MASTERCARD', 'MAESTRO'); AMERICAN = 'AMEX'; SOROCRED = 'SOROCRED'; begin if MatchText(ItemResposta.NomeAdministradora, VISA) then ItemResposta.NFCeSAT.Bandeira := '01' else if MatchText(ItemResposta.NomeAdministradora, MASTERCARD) then ItemResposta.NFCeSAT.Bandeira := '02' else if ItemResposta.NomeAdministradora = AMERICAN then ItemResposta.NFCeSAT.Bandeira := '03' else if ItemResposta.NomeAdministradora = SOROCRED then ItemResposta.NFCeSAT.Bandeira := '04' else ItemResposta.NFCeSAT.Bandeira := '99'; end; Essa foi minha solução, para o Pay&GO, claro que se você usa outro produto pode mudar, espero ter ajudado quem está passando pelo mesmo problema.

Acredito que esses exemplos que você passou sejam de transações verdadeiras correto? porque aqui no emulador só vem "DEMOCARD" independente do cartão passado. Minha meta é alimentar o campo "tBand" da NFC-e, ainda sim segundo o manual o campo 040 diz o seguinte: Parece que quem usa SITEF tem essa informação de forma mais facilitada, eu estive pensando em usar o "IIN", já que o campo 740-000" vem com os números iniciais do cartão, e com eles seria possível identificar a bandeira. Como o foco é a alimentação do tBand como eu disse acima, e ele exige a identificação correta de apenas 4 redes, e essas são fáceis de conseguir, salvo a Sorocred que não é internacional, então fica mais difícil. Alguém já resolveu isso de forma consistente com NFC-e & Pay&GO?

Pois é, no manual está "010-000 Rede Adquirente", então fiquei na dúvida. Acredito que não seja, eu preciso da bandeira do cartão que foi passado no pinpad.

Prezados, estou pesquisando no fórum sobre o assunto, e não achei nada para o Pay&GO sobre como obter a bandeira da transação, alguém pode dar uma luz, obrigado.

Amigo, da uma olhada no seu perfil, todos os seus tópicos contem títulos que não remetem ao problema que você está tendo dificuldades, isso dificulta a pesquisa de outros usuários que estão tendo o mesmo problema que você, além de não ficar claro para quem acompanha o fórum. Agora ao assunto, também não estou muito por dentro, mas salvo engano é necessário informar o IdToken/idCSC mais o Token para que o seu QRCode funcione corretamente. Caso você já tenha informado essa configuração, poderia tentar emitir no demo da ACBr para ter certeza que está tudo certo com sua aplicação. http://www.sped.fazenda.pr.gov.br/modules/conteudo/conteudo.php?conteudo=103

Isso eu sei, mas não ficou claro de início, gerou questionamento correto? poderia ter um label na outra aba informando que os eventos são os mesmos etc.. questão de informação apenas. A final não é nada de mais inserir um label por exemplo.

Estou anexando uma sugestão de alteração do DEMO para evitar a criação de tópicos futuros, o motivo da alteração é que durante a integração com a NFCe, não ficou claro no demo como seria a impressão da DANFE da NFCe, visto que na ABA somente tem o botão de Criar e Enviar, e para quem usa o Fast então... Então apenas para deixar mais sugestivo, adicionei um botão Imprimir que está anexado ao mesmo evento de imprimir da outra aba. Delphi_NFCe.7z

Meio atrasado, mas segue os arquivos com os eventos vinculados e aparentemente quase tudo funcionando, a parte do WebBrowser só com mais tempo. Correção do DPR da venda frenética. A maioria das alterações estão no FMX. Projeto ECFTeste.dpr (Firemonkey) ECFTeste.dpr ECFTeste1.fmx ECFTeste1.pas

Nesse caso do exemplo, para a redução Z não acho interessante, porque considera qualquer valor, se o destino é "000010" e a origem (Antes da Redução Z) é "00000" ele vai substituir mesmo assim, o mesmo vale para a situação de Data Nula na origem e no destino não nulo, no exemplo acima também trocaria. Mas de qualquer forma então o consenso é somente para a classe que realiza a operação inversa(Re-alimenta a classe com o ini gerado por elá própria) correto?

Não tem como editar mais a resposta anterior, então estou adicionando em outro post. Poderia remover o procedimento da Z, e a operação da classe carregar o arquivo INI que ela mesmo gera poderia permanecer na classe, O mesclar poderia permanecer também, se a pessoa achar que precisa de um ajuste, então o código está lá, mas a função de mesclar sobrepõe apenas valores maior que zero, isso vale para Data, Inteiro e Float, ou seja, até o COO se for zerado não é sobreposto.

OK.

O código vai ser analisado para verificar se pode ser subido? precisa dessa confirmação caso contrário temos que tirar do nosso componente da acbr e passar para o sistema, porque sempre usamos a versão do svn original do acbr, não mantemos alterações próprias nos fontes. Desculpa o incômodo, obrigado.

Prezados, implementado o fechamento do dia, me deparei com informações importantes aqui do fórum e bem espalhadas sobre a redução Z. Alguns modelos pedem totalizadores depois da redução z (Alguns tópicos confirmam isso, conversei com o regys ele também afirmou). O ideal é utilizar tanto o DadosReducaoZ como UltimoDadosReducaoZ como em alguns tópicos. Na chamada da redução Z é interessante uma configuração de timeout para evitar problemas (blog do regys). Em algum tópico o Daniel posta um código para mesclar arquivos INI para permitir utilizar de forma mais simplificada as funções DadosReducaoZ e UltimoDadosReducaoZ. Diante dessas informações nós iniciamos uma solução para as questões acima, e tentamos inserir ela dentro da classe ACBrECFClass. Vou tentar explicar de forma simples. type TACBrECFDadosRZ = class public procedure CarregaINIReducaoZ(const DadosReducaoINI: TMemIniFile); procedure CarregaMesclandoINIReducoesZ(const Origem, Destino: string); end; TACBrECFClass public function ReducaoZ_Otimizada( DataHora : TDateTime = 0 ): TACBrECFDadosRZ; end; O procedimento CarregaINIReducaoZ foi implementada para fazer a leitura do arquivo INI gerado pela própria classe TACBrECFDadosRZ e se auto alimentar as informações, recuperando alíquotas e totalizadores, auto alimentando a classe, no meu ponto de vista a implementação ficou bem segura e respeitando os critérios do procedimento responsável pela geração MontaDadosReducaoZ. O procedimento CarregaMesclandoINIReducoesZ foi criado do zero mas usando a ideia da função já postada aqui no fórum, ela sempre tenta permanecer o valor do destino caso o valor da redução de origem seja nula, zero ou etc... A função ReducaoZ_Otimizada, realiza o procedimento de aumento de TimeOut postado pelo Regys além de armazenar o INI da função DadosReducaoZ, armazenar o INI da função DadosUltimaReducaoZ, mesclar os dois e carregar para o retorno da função a redução Z completo e acessível por pela classe TACBrECFDadosTZ, combinando as implementações anterior. Vantagens Utilizando a leitura pela classe e não pelo INI resultante do processo de mesclagem, as futuras alterações realizadas na classe são sentidas no momento da compilação (quando alterado no svn e atualizado), diferente da leitura pelo INI dentro do seus sistema, que somente depois que ser executado que uma alteração de tipo ou objeto seria identificada. Simplifica o processo da redução Z para quem não conhece os problemas de compatibilidade das impressoras. Evita o problema com TimeOut nas reduções Z. Função ReducaoZ Otimizada: function TACBrECFClass.ReducaoZ_Otimizada(DataHora: TDateTime): TACBrECFDadosRZ; var OldTimeOut: integer; ReducaoAntes, ReducaoDepois: string; begin ReducaoAntes := DadosReducaoZ; OldTimeOut := TimeOut; try TimeOut := 600; // 10 minutos ReducaoZ( DataHora ); finally TimeOut := OldTimeOut; end; ReducaoDepois := DadosUltimaReducaoZ; Result := TACBrECFDadosRZ.Create; Result.CarregaMesclandoINIReducoesZ(ReducaoAntes, ReducaoDepois); end; Como Utilizar: procedure TForm3.Button1Click(Sender: TObject); var Reducao: TACBrECFDadosRZ; begin Reducao := ACBrECF1.ECF.ReducaoZ_Otimizada(Now); try //Leitura das variáveis desejadas aqui. finally Reducao.Free; end; end; Estou anexando as units, e um demo que sem realizar a redução z, alimenta 3 memos e compara o arquivo ini Antes da Redução, Depois da Redução e o Arquivo Final Mesclado. (Demo em firemonkey²) ACBrSerial.zip DemoUtilizaçãoReducaoMesclagem.zip

Foi no Trunk 2? Aqui não chegou o update.

Isaque, durante uma inicialização hoje no desenvolvimento, o nosso aplicativo não identificou a ECF, porém no ACBr demo para o firemonkey estava identificando, investigando o componente, tinha mais uma linha com o MainForm sem a verificação de NIL, então adicionei, se puder subir novamente. Obrigado. Result := (ExibeMensagem or BloqueiaMouseTeclado) and (AguardaImpressao or ((TimeOut - TempoInicioMsg) > 1) ) and FormMsgControla and {$IFDEF FMX} Assigned(Application.MainForm) and Application.MainForm.Visible{$ELSE} Application.ShowMainForm{$ENDIF} ; Eu verifiquei o resto do arquivo e o ACBrECF.pas e não existe outra chamada do tipo, era para eu ter adicionado em todas as outras chamadas quando eu corrigi esse erro anteriormente, falha minha. ACBrECFClass.pas