Próton Sistemas

Boa tarde, Exceto por um erro de BadWindow que ocorre sempre que abro o JFileChoose (vou investigar), o exemplo em java está funcionando. Instalei o Opensuse 15.5 Leap que já vem com openssl 1.1. Aproveitando, quando o ACBrLib vai receber a atualização do openssl 3? Obrigado pelas respostas! Saudações, Rafael

Boa noite. A versão ainda era a 3, removi e tentei instalar a 1.1.1 sem sucesso (deu problema em algumas dependências). De qualquer forma, o ACBr anunciou suporte a versão 3 da openssl no link abaixo: O ACBrLib ainda não recebeu essa atualização? Vou instalar o opensuse que é a distro usada nos treinamentos de vocês e ver se seguindo o mesmo passo a passo funciona corretamente. Saudações, Rafael

Olá, Segui as instruções do video, mas sigo com o mesmo problema. Abaixo segue a lista de links criados e o erro que recebo. Não falta alguma dependência? Não tem um log de erro da biblioteca que eu possa checar? No log só tem a mesma coisa da mensagem acima.. 04/12/23 19:35:22:843 - NFE_StatusServico 04/12/23 19:35:22:843 - Travar 04/12/23 19:35:22:848 - Destravar 04/12/23 19:35:22:848 - SetRetorno(-10, WebService Consulta Status serviço: - Inativo ou Inoperante tente novamente. Erro ao ler informações do Certificado. Provavelmente a senha está errada) 04/12/23 19:35:22:848 - LIB_UltimoRetorno 04/12/23 19:35:22:848 - MoverStringParaPChar. StrLen:155, BufLen:256 04/12/23 19:35:22:848 - Codigo:-10, Mensagem:WebService Consulta Status servi[195][167]o:[CR][LF]- Inativo ou Inoperante tente novamente.[LF]Erro ao ler informa[195][167][195][181]es do Certificado.[LF]Provavelmente a senha est[195][161] errada @Daniel InfoCotidiano poderia me enviar a sua lista de links simbolicos para eu conferir com a minha lista? pode ser que ainda tenha alguma dependência faltando ou errada... Agradeço qualquer ajuda neste sentido, Saudações, Rafael

Prezados, Estou recebendo erro sempre que tento acessar o certificado pelo exemplo em Java (LTS 17). O ambiente é o que segue: No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.3 LTS Release: 22.04 Codename: jammy O erro é o abaixo: A senha eu já conferi que está correta. Imagino que na verdade está ocorrendo algum erro interno no carregamento das depedências. Abaixo segue a lista de link simbólicos criados.. falta algo? Eu não localizei a libexslt para instalação no Ubuntu. Isso pode ser o problema? Saudações, Rafael

Então assumindo que o bug é na DLL que não retornou o valor esperado, posso substituir a DLL pela do fabricante? Não achei nada confirmando essa possibilidade. rg

Boa tarde! Eu assisti o vídeo e a minha aplicação está configurada exatamente igual ao conteúdo: usando a DLL da pasta de instalação do Driver MFE. Inclusive, tive o mesmo cuidado de antes de atualizar o Driver, remover o anterior. No vídeo não fala nada sobre usar a DLL do fabricante. E numa pesquisa rápida também não achei como ativar o log da mfe.dll. Minha melhor hipótese é estar ocorrendo algum problema na DLL que não é capturado pelo ACBrSAT. Saudações, rg

Eu suprimi somente o XML por conter dados sensíveis sobre o ambiente de produção do cliente, porém tomei o cuidado de manter todas as operações referentes a emissão do CF-e. E acontece exatamente o que você constatou, não tem o log do retorno. Tem alguma outra forma de analisar esse problema? Sobre o log do fabricante, creio que aqui não se aplica, pois usamos a DLL fornecida pelo Driver MFe fornecida pelo fisco. No caso é para usar outra DLL? Saudações, rg

Creio que me expressei mal, na verdade o que eu chamei de log da DLL é o "ArqLog" do componente ACBrSAT. E só mais um detalhe: o aparelho em questão é um MFe.

Prezados, Em algumas vendas o retorno do método "EnviarDadosVenda" retorna vazio gerando assim uma inconformidade na nossa aplicação. Conforme log da nossa aplicação há uma tentativa de consulta do status e logo em seguida uma tentativa de envio da venda corrente ao aparelho: 2023-09-13 11:53:36:767 [TID 4504][DEBUG ] autorizar -> ConsultarSAT -> 850768|08000|SAT em operacao|| [emissor] 2023-09-13 11:53:46:809 [TID 4504][DEBUG ] autorizar -> EnviarDadosVenda -> [emissor] *a última linha do log acima é gerada pelo seguinte código: retorno := FDM.ACBrSAT1.EnviarDadosVenda; Logger.Debug('autorizar -> EnviarDadosVenda -> ' + retorno, ACBR_EMISSOR_LOGGER); Comparando com o log da DLL, vemos que na verdade a venda foi autorizada, segue: 13/09/23 11:53:36:083 - NumeroSessao: 850768 - Comando: ConsultarSAT 13/09/23 11:53:36:767 - NumeroSessao: 850768 - Resposta:850768|08000|SAT em operacao|| 13/09/23 11:53:36:772 - NumeroSessao: 997417 - Comando: EnviarDadosVenda( <?xml version="1.0" encoding="UTF-8"?><CFe> <infCFe versaoDadosEnt="0.07"> <ide> ...continua 13/09/23 11:53:36:773 - Gravando XML Venda enviado: \events\event\2023\09\13\AD20230913115336-997417-env.xml 13/09/23 11:53:36:773 - Inicio do Envio 13/09/23 11:53:46:808 - Tempo de Processamento: 10,035 segundos 13/09/23 11:53:46:808 - NumeroSessao: 997417 Dessa forma, quando esse incidente acontece, no nosso sistema o cupom é considerado cancelado, porém para o aparelho o mesmo foi processado. Gostaria de saber qual tipo de tratamento deve ser feito neste tipo de situação? Lembrando que isso ocorre esporadicamente em ambiente de produção. Saudações, Rafael Glauber

Bom dia, Esse ticket é para acompanhar o ticket interno #TK-3485. Se possível, gostaria de receber retorno sobre a tarefa. Saudações, Rafael Glauber

Bom dia. Pode encerrar o ticket. Assisti os vídeos e ajustei o sistema com base nas sugestões. Saudações, Rafael Glauber

Aline, eu te mandei msg no Whatsapp. A Valcy me passou seu contato para nós resolvermos esse acesso. Att Rafael Glauber

Como eu faço login na plataforma? O mesmo e-mail aqui da conta do fórum não acessa. Dá e-mail inexistente.

Sim. Atualizei os fontes em 30/11/2022. Mas a questão aqui não é essa para mim.. quero saber qual a recomendação para este caso. Entrar em contingência? Ou parar de emitir notas? Att, Rafael

Olá, O sistema recebeu erro 404, como não tratei esse tipo de erro o sistema não entrou em contingência. O que é recomendado neste caso? Pois claramente foi alguma instabilidade no serviço, já que depois tudo normalizou sem nenhuma intervenção. Hoje o sistema entra em contingência quando ocorre algum erro 50X, mas os erros 40X não são tratados. Devo adicionar no tratamento de erros? EACBrDFeException: Erro Interno: 0 Erro HTTP: 404 URL: https://nfce.svrs.rs.gov.br/ws/NfeAutorizacao/NFeAutorizacao4.asmx <html> <head> <meta http-equiv="Content-Type" content="text/html";> <script Language="Javascript" type="text/Javascript"> location.href = "/login.asp"; </script> </head> <body> </body> </html> OBS. O sistema está em produção faz mais de 1 ano sem nunca ter sido reportado erro 40X em um emissor já funcional. Att Rafael

Caro Panda, O problema foi resolvido. Obrigado! Rafael Glauber

O extrato sat não está carregando o logo para a opção do Fast Report. No método procedure TACBrNFeFRClass.CarregaParametros; o componente faz a seguinte operação: TBlobField(cdsParametros.FieldByName('LogoCarregado')).LoadFromStream(vStream); Porém, no procedure TACBrSATExtratoFR.CarregaParametros; não é feito o carregamento do mesmo parâmetro. Pelo que vi aqui é por isso que no Extrato para FastReport não imprime a logo, pois se eu adicionar a linha de carregamento do campo "LogoCarregado" abaixo o logo é impresso. procedure TACBrSATExtratoFR.CarregaParametros; begin with cdsParametros do begin Close; CreateDataSet; Append; FieldByName('QtdeItens').AsInteger := FCFe.Det.Count; FieldByName('Imagem').AsString := Ifthen(Self.Logo <> '', Self.Logo,''); FieldByName('Sistema').AsString := Ifthen(Self.Sistema <> '',Self.Sistema,'Projeto ACBr - https://www.projetoacbr.com.br/%27); FieldByName('Usuario').AsString := Ifthen(Self.Usuario <> '', Self.Usuario,''); FieldByName('MsgAppQRCode').AsString := Ifthen(Self.MsgAppQRCode <> '', Self.MsgAppQRCode,'Consulte o QR Code pelo aplicativo "De olho na nota", disponível na AppStore (Apple) e PlayStore (Android)'); if Self.Logo <> '' then TBlobField(FieldByName('LogoCarregado')).LoadFromFile(Self.Logo); Post; end; end; Saudações, Rafael Glauber

Exatamente, estou fazendo carregamento tardio. Provavelmente, vou deixar dessa forma pois só verifiquei esse problema de concorrência entre as threads. No mais, tudo funcionando depois dessa sincronizada na primeira operação. Rafael.

Não me parece que o problema é o acesso ao certificado digital. Na primeira tentativa de uso do openSSL o sistema ainda vai carregar as DLLs. Depois de carregadas o sistema testa a variável abaixo: md := EVP_get_digestbyname( NameDgst ); if md = Nil then raise EACBrDFeException.Create('Erro ao carregar Digest: '+NameDgst); Neste caso eu só fiz garantir que na PRIMEIRA vez uma só thread execute até o final para finalizar o carregamento do openSSL (das DLLs). Depois disso, elas podem concorrer a vontade que não verifiquei problemas. Rafael.

Pelo que analisei rapidamente o problema é que minha aplicação usa o ACBr na thread principal e em outra thread. Se os dois chamarem esse método simultaneamente ocorre o problema a primeira vez. Acredito que a biblioteca openSSL ainda não tenha carregado. Coloquei um delay na thread para só começar depois que a principal inicializar. Depois disso, parou de ocorrer o problema. Rafael.

A aplicação costuma subir essa exceção no método abaixo: { Método clonado de ACBrEAD } function TDFeOpenSSL.CalcHash(const AStream: TStream; const Digest: TSSLDgst; const Assina: Boolean): AnsiString; Ainda não consegui determinar um padrão, mas me parece que é sempre na primeira tentativa de emitir alguma NFCe (ou consulta) e não são todas as vezes que inicializa a aplicação. Isso acontece tanto em ambiente de produção, quanto de qualidade/testes (eu logo todos os erros). A aplicação se recupera normalmente do problema, mas me incomoda não saber a causa além da qualidade de sujeira que isso gera no log da aplicação. As dlls ficam na pasta da aplicação (openSSL e cia) e tudo funciona normalmente depois. O tópico é só para saber se alguém passa por isso e se conseguiu resolver. Imagino que na prática isso pode tá levando a minha aplicação a fazer emissões em contingência sem necessidade ou mesmo gerando outros problemas indiretamente. saudações, Rafael

Os schemas e o certificado ficam numa mesma pasta e os dois processos compartilhavam mesmo antes. Ainda acho curioso antes não ocorrer o problema e o mesmo ficar tão crítico depois de uma atualização de versão no cliente (na qual atualizei ACBr e versão do produto). Uma atualização: peguei duas máquinas com Win7, mudei para WinCrypt e deixai UAC desligado (nível mínimo) e o problema parou de ocorrer pelo menos nos testes iniciais. Vou acompanhar mais. Att. Rafael

Acredito que não, pois todas as chamadas feita pela thread usam Co(Un)Initialize num try/finally e a thread principal não precisa, pois o CoInitialize é chamado automaticamente. De qualquer forma, se eu removo o CoInitialize não ocorre a execução dos métodos do ACBr com o erro justamente informado que precisa usar CoInitialize. Acabei de testar uma configuração da aplicação de funcionar somente OFFLINE que significa que a thread não roda em paralelo com a principal e a thread principal emite em contingência. Dessa forma o erro parou. Ao que parece tem algo conflitando mesmo entre os processos. Saudações, Rafael

No caso são instâncias diferentes do componente ACBrNFe, cada processo usa a sua, mas de fato eu não controlo o acesso ao certificado entre os dois processos. Uma coisa importante é que isso parece ter alguma relação com uma atualização dos componentes do ACBr que foi realizada um tempo atrás. O cliente passou a reclamar do problema depois que recebeu essa versão. No caso eu preciso controlar o acesso ao certificado pelas threads? Teria que pensar em uma forma eficiente de checar o bloqueio do recurso caso isso seja o problema, pois é o componente do ACBr que faz uso do certificado. Att Rafael

Depois que atualizou o Windows a aplicação capturou o log abaixo: Access violation at address 770D1D3A in module 'ntdll.dll'. Write of address 00000014 Messagem: Error on call to Winsock2 library function shutdown: O aplicativo não chamou WSAStartup ou WSAStartup falhou Sendo que antes isso não era capturado pela aplicação. Era um erro que aparentemente não caia na pilha de exceção da aplicação. Att. Rafael