Data Lider

Olá Daniel, obrigado pela atenção, e realmente, com duas notas seguidas o problema acaba acontecendo, você tem alguma sugestão? Talvez adicionar uma propriedade TDFeSSL e em TDFeSSLCryptClass para definir se mantem o certificado carregado, ou não, então sempre que pedir o carregamento e após fazer o uso liberar. Ou então tentar manter o mesmo contexto em duas aplicações diferentes usando o mesmo handle (não sei se é possível).

Segue sugestão de alteração, dessa forma mesmo usando assinatura de XML por biblioteca externa funciona sem problemas. Revisão: 13736 ACBrNFeNotasFiscais.pas

Olha, conforme dentro deste procedimento que você mencionou, o parâmetro é definido como False, porque os certificados do tipo CNG - "Cryptography API: Next Generation". retornam erro com essa requisição.

De mais detalhes sobre o problema O certificado não encontrado está no repositório de certificados do Windows? Se estiver lá, comparou o Serial dele com o serial que a sua aplicação está enviando para a ACBr? Sua aplicação roda como serviço? O certificado está instalado no repositório "Pessoal"? Pelo ACBrNFeDemo o processo de envio está funcionando?

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.