Painel de líderes

Boas Novas: Consegui assinar usando a MScrypto sem MSXML e LibXMLSec. Amanhã vou refatorar e testar se não causa nenhum problema no certificado.

Observe que se você fazer a consulta assim: LIKE '%AFASTADOR%MEDIO%' você obterá resultado. Ou seja, substituindo o caractere espaço por porcentagem, sua pesquisa ficará mais flexível. Tente algo assim: qry.Close; qry.SQL.Add('SELECT * FROM TB_PRODUTO WHERE DESCRICAO LIKE :pesquisa'); qry.Params[0].Value := '%'+ StringReplace(edtPesquisa.Text, ' ', '%', [rfReplaceAll]) +'%'; qry.Open; Eu uso desta forma e nunca tive problemas.

Muito bom... poderíamos criar uma nova classe de TDFeSSLXmlSignClass, que dispensaria o uso de XMLSec ou MSXML... tudo em código Pascal...

Boa tarde. Segue dois pequenos ajustes que fiz no exemplo do componente ACBrTEFD: Substituição da diretiva {$END} por {$ENDIF} (utilizo Delphi 2010, e não estava compilando; verificar se as duas são equivalentes em versões anteriores do Delphi, onde possivelmente tenha sido criado o exemplo); Controle da visibilidade do painel de pagamentos, mostrando o mesmo apenas na aba referente à venda (a primeira aba é apenas para configurações). Abraço, Gabriel. Unit1.dfm Unit1.pas

Sá pra dar um feedback pros amigos aqui, atualizei pra ultima versão e funcionou direitinho

Olá amigos, depois de mais um cliente ter perdido o certificado resolvi que ia tentar descobrir oque estava causando isso, e depois de muita peleja(são 4:00 da manhã ), acho que consegui chegar ao causador do problema, pelo menos tive sucesso em excluir um certificado por diversas vezes assinando um XML. E como muito se falava, não é diretamente o ACBR que está excluindo o certificado, pelo que constatei é a MSXML que está "reiniciando" o certificado e somando isso a mais algum problema está causando a exclusão. Se você assinar um XML e deixar o administrador do token aberto, verá que no momento da assinatura, no trecho "xmldsig.sign(dsigKey, CERTIFICATES);" o token muda de: Operacional >> Ausente >> Presente >> Operacional, como se o cartão fosse removido e inserido novamente. Pensei aí tem coisa! Tentei remover o cartão durante a assinatura mas não consegui simular a exclusão do certificado, imaginei que não estava sendo rápido o suficiente. Então coloquei um loop no trecho do ACBR que pega a chave privada do certificado, antes de executar a assinatura, percebi que até aí o PIN do certificado não era solicitado, somente mais a frente quando ocorre a assinatura com "xmldsig.sign(dsigKey, CERTIFICATES);". Porém quando removi o certificado da leitora e inseri novamente dentro do loop(o mesmo que a MSXML faz durante a assinatura) foi me solicitado o PIN e logo depois veio a mensagem: "O conjunto de chaves não está definido", olhando no administrador do token que estava aberto pude ver o certificado sendo excluído: O PIN que ele me solicitou foi para excluir o certificado! O que imagino que esteja acontecendo é que se você chamar o método Assinar repetidamente, antes de dar tempo do cartão ficar operacional novamente, o certificado pode ser excluído. Isso explicaria o porque da exclusão ser esporádica e também não acontecer com todos os sistemas, pois dependeria da lógica usada por cada um para assinar, como assinaturas em sequência ou mesmo mais de uma thread acessando o certificado. Fiz um vídeo mostrando o momento da exclusão, note que não consegui excluir na primeira tentativa, porque demorei muito pra inserir o cartão, estava com uma mão ocupada filmando, ia editar isso mas tô com muito sono. MODERAÇÃO: vídeo removido a pedido do usuário Vou dormir um pouco e amanha ver se me aprofundo no problema.

Enviei ao SVN. Mas considero o componente em beta. Confesso que não entendi todas as propriedades (Exemplo: TrocaDiaTipo), mas aqui vão algumas considerações: Notei que o arquivo .json não é válido. Você mesmo pode testar em sites como: https://jsonformatter.org/ ou https://jsonformatter.curiousconcept.com/ Removendo uma vírgula na linha 84 e alterando a linha 2 para incluir uma string (exemplo "definicao": { ), corrige o arquivo. Na busca por feriados de 2017, o programa de exemplo está exibindo "a páscoa" com data de "30/12/1899"... Outra coisa, as classes estão todas dentro do arquivo ACBrFeriado.pas. Seria melhor estarem em arquivos separados. Principalmente as classes abstratas ou básicas (TACBrFeriadoWSClass) e suas implementações (TACBrWSCalendario, TACBrWSJSON). Nota: Ao pesquisar sobre o assunto, acabei encontrando o seguinte projeto: https://github.com/dadosbr/feriados. Pode ser interessante unir forças já que eles mesmos disponibilizaram uma mini-api.

Boa tarde, @Daniel Simoes @Juliomar Marchetti Preciso disponibilizar para os meus clientes o Reinf com a assinatura utilizando o A3. Procurei / testei alternativas de bibliotecas e componentes, mas não encontrei nada (open) que eu conseguisse fazer funcionar no Delphi para poder incorporar no ACBr. Desenvolvi uma biblioteca em C# e gostaria de saber se podemos incorporá-la no ACBr (com os fontes) como alternativa para a assinatura. Segue minha sugestão com os respectivos fontes: Fontes separados: ACBrDFe.rar ...: Fontes da implementação da nova biblioteca no ACBr ACBrReinf.rar .: Fontes "Beta" do Reinf assinando com a nova biblioteca + Certificado A3 _TELAS.pdf ....: Detalhes da implementação

Aparentemente ainda não foram liberados Schemas que contemplam a NT 2017.001. Pelos atuais só são aceitos caracteres numéricos de tamanho 8, 12, 13 ou 14, ou vazio.

Olá, estive fora esses dias, mas fazendo os testes aqui, sim eu tive vazamento de memória, porem foi erro meu, estava sem a dll InterfaceEpson na pasta do executavel. E sobre o #0 o meu Driver da EPSON USB estava incorreto, pois formatei meu computador e reinstalando a impressora não aconteceu mais o problema. Desculpe o incomodo e abraços

Obrigado já está no svn.

Juliomar/Ricardo, Obrigado pela atenção. Parabéns pelo trabalho. Wanderson

@CleitonMaciel, Já assistiu ? https://www.eventials.com/djsystem/nfc-e-e-sat-como-tratar-a-contingencia/

Boa tarde! Na pág. 31 da Nota Técnica 2016.002 - v1.00 apresenta as opções para tpag. ID YA02 - Forma de pagamento. Já na pág. 37 que trata da validação do campo YA02-30 para o modelo 55 Ou seja. Este campo somente será aceito se a forma de pagamento for igual a 14. Diferente disto não será aceito.

Ola Ricardo. estou encontrando dificuldades para pegar esse código de retorno que suas funções tratam, qual a propriedade do acbrsat que retorna esse código? desde já obrigado.