jcmferreira

Luiz, os testes que tentei fazer foram: Finalizar o meu sistema e abrir novamente (premissa de que o problema é meu) Tentei olhar as configurações do app da SafeId pra ver se achava algo que mencionasse a chave privada, sem sucesso Reiniciar o Windows Não deu tempo de hibernar e não foi bloqueado pois tudo ocorreu em acesso remoto, antes e após o reinício. Com isso, 2 deram certo e 2 continuaram com o problema. Em pesquisa na internet, alguns estão associando à atualizações do Windows que "quebraram" o app da SafeId ou o velho problema de arquivo corrompido, exigindo uma reinstalação completa do SafeId. Ainda estou aguardando retorno do suporte deles, mas se demorar mais ou se não resolver, estou para optar pela desinstalação completa do app deles, limpeza de cache e outros trâmites "padrão Windows" para reinstalar e ver se resolve.

Pois é Luiz! Tivemos 4 casos, curiosamente da mesma empresa/aplicativo, a SafeId, e com eles, apenas 2 voltaram após reiniciar o Windows. Outros 2 ainda estão "parados". Estão tentando contato com o suporte especializado disponibilizado por eles, mas ainda não tivemos sucesso.

Olá pessoal, boa tarde! Tudo joia? Alguns clientes que usam certificado A3 da SafeID estão com um problema para enviar o eSocial com o ACBr. O erro em questão é o "Falha em obter Provedor de Criptografia do Certificado pela ausência da chave privada. Erro: 80090014". Estes mesmos clientes enviavam normalmente e desde o dia 8 (segunda), começou esse problema. Já tinha visto coisa parecida com o A1, importado, mas nunca com um A3. Muito com certeza não deve ser um problema do ACBr em si, mas como vocês possuem bastante experiência, já podem ter passado por algo semelhante. Se alguém tiver qualquer dica ou sugestão, já agradeço antecipadamente.

Bom dia @Ozael Silva! Ainda não. Em todos os testes que eu fiz com mais de um nível de detalhe (detalhe do detalhe), o cancel em qualquer formato ou método sempre cancela todo o cache. Posso estar errado mas acho até que o FireDAC não consegue fazer isso.

Juliomar, Valeu pela resposta. Eu devo estar perdendo alguma coisa, pois na minha versão do instalador no Trunk2 exibe essa mensagem selecionada. A minha necessidade não é nem o ACBr e sim, o próprio Delphi, pois eu preciso utilizar o PostgreSQL 15.

Boa tarde pessoal! Pesquisei no fórum, mas não achei nada sobre isso. Então, decidi fazer uma pergunta: já existe possibilidade de se compilar o ACBr visando eSocial na versão 64bits? Obrigado antecipadamente.

Bom dia! Sim, é obrigatório avaliar todas as condições para a definição do grupo. Só fiz um comentário específico sobre essa situação do tipo de contrato, por achar que talvez não fosse necessário existir esse quarto tipo. O mesmo ocorre para o "Tipo de Plano de Segregação da Massa", em que foi criado um tipo com valor -1 para definir que a tag não será informada, quando, na minha humilde visão, não seria necessário. Estou ajustando os fontes para conseguir validar o ambiente do cliente e assim que estiver positivo, subo as modificações aqui.

Boa tarde pessoal! Hoje, fiz update no projeto ACBr para tentar ver se algo na definição do grupo <duracao> do evento S-2200 tivesse sido modificado. O problema: ao gerar um S-2200 de um servidor com regime trabalhista tipo 2 - Estatutário, mesmo não informando absolutamente nada para o grupo <duracao> no ACBr, mesmo assim, é gerada a tag tpContr com o valor '1', indevidamente. Atualmente, existem 3 tipos de contratos (indeterminado, em dias, fato) mas o ACBr definiou um quarto tipo chamado de PrazoNaoAplicaval. A regra para o grupo <duracao> é que o mesmo só deve ser informado para o regime trabalhista do tipo celetista (tpRegTrab = 1). Pelo código abaixo, o ACBr só não gera esse grupo se o prazo estiver definido para esse tipo PrazoNaoAplicaval. if pInfoContrato.Duracao.tpContr <> PrazoNaoAplicavel then GerarDuracao(pInfoContrato.Duracao, pTipo); Minha dúvida é: não seria mais correto essa definição ser feita com base na própria informação tpRegTrab, no lugar de precisarmos definir esse tipo inexistente de contrato PrazoNaoAplicaval? Obrigado pelo apoio de todos!

Olá pessoal! Trabalhamos com uma versão extremamente defasada aqui (mas já era trunk2) e após atualizar, estamos nos deparando com o erro abaixo: "Assinatura do evento inválida. Ações Sugeridas: Verificar se houve alteração do evento após a assinatura. Verificar a validade da assinatura." O XML aparenta estar correto, inclusive com o posicionamento da tag de assinatura. Alguma sugestão?

Boa noite! Segue primeira versão do arquivo para apreciação. Atualização dos atributos para a tag <infoMandElet>. pcesS2300.pas

@Juliomar Marchetti, a sua dica foi perfeita mas eu passei batido e infelizmente, demorei pra fazer esse teste, até pq funciona sem isso antes. Configurei o SSLType da seguinte forma e agora, voltou à funcionar: Configuracoes.WebServices.SSLType := LT_TLSv1_2; Só não seiu explicar a razão de funcionar sem isso antes.

@Juliomar Marchetti, aqui não usamos o Capicom. Inclusive, na instalação do ACBr, marcamos para não usá-lo. Nas configurações do projeto, definimos da seguinte forma: Configuracoes.Geral.SSLLib := libWinCrypt; Configuracoes.Geral.SSLXmlSignLib := xsLibXml2; O engraçado é que sempre foi assim e funcionava. Não vi nada nos fontes do ACBr de antes que pudesse justificar isso. Acho que pode ser alguma coisa faltando no meu SO (o antigo HD tinha um Win10 atualizado do 7 e era extremamente mexido). Ainda não consegui identificar oq está faltando.

Respostas: Fazia muito tempo que não atualizava? Não muito. Porém, antes funcionava normalmente. Agora, acredito que não seja o ACBr (muito certeza disso) e sim, o fato de que fui para um SSD recentemente (1 mês) e alguma coisa nessa nova instalação (Windows 10) pode estar faltando. conseguiu identificar no log o que foi mudado? Com exceção de hj, com o pces2300 (mandato eletivo), não faço mudanças no código fonte original do ACBr pois sempre me atendeu em 100%. lembrando que isso é relativo ao TLS 1.2 e também ao openssl de 1.0 superior que deve usar Nas minhas opções de internet estão marcados TLS 1.0, 1.1 e 1.2. Também baixei as cadeias de certificados informadas no manual do desenvolvedor do eSocial, da RFB e Sepro, mas ainda nada.

Olá pessoal, boa tarde! Não fazendo associação mas, após atualizar o meu branch local com o Trunk2, meu sistema passou a dar o erro abaixo quando qualquer envio eSocial é feito. Por um momento, achei que fosse a chave exportável do certificado, então refiz a importação, mas sem sucesso. O certificado é um A1, arquivo pfx. EACBrWinReqResp, "Falha Enviando a Requisição. Erro: 12175 - Um ou mais erros foram encontrados no certificado Secure Sockets Layer (SSL) enviado pelo servidor" Alguma sugestão? Obrigado antecipadamente.

Opa! Já finalizei a alteração e estou testando, pois existem outras pendências para órgãos públicos. Finalizando, vou colocar aqui. Mas a minha pergunta era se existe um tópico/fórum específico para órgãos públicos, pois é o meu foco e poderia ajudar bastante nisso. Obrigado @Juliomar Marchetti

Opa amigo! Obrigado pela resposta. A pergunta continua...

Olá, pessoal! Existe algum fórum/tópico exclusivo para a parte de órgãos públicos? Estou precisando das informações para a tag do mandato eletivo (categoria 304) mas o ACBr ainda não disponibilizou. Gostaria, inclusive, de contribuir com essa parte de órgãos públicos. Obrigado.

Pessoal, boa tarde! Sobre as configurações do M/D com o FireDAC, acredito que tudo seja bastante simples e intuitivo. No meu caso, utilizo o PostgreSQL e tudo aparentemente roda com perfeição. Recentemente, tive a necessidade de fazer um M/D em três níveis: mestre->detalhe->detalhe->detalhe. O comportamento é bem estranho e parece que estou deixando alguma coisa passar, pois não estão funcionando os recursos de propagar nos detalhes e ao alterar um mestre (seja o principal ou um dos detalhes mestres), o seu detalhe imediato perde dados. Abaixo, o exemplo dos dois métodos usados para configurar o M/D dos datasets e mais abaixo, as consultas realizadas e configuradas (todas com as FKs devidamente definidas) Métodos para configuração: class procedure TUtil.Dados.prepararConsultaMestre(mestre: TFDRdbmsDataSet); begin mestre.CachedUpdates := true; mestre.SchemaAdapter := TFDSchemaAdapter.Create( mestre ); mestre.UpdateOptions.CheckRequired := false; end; class procedure TUtil.Dados.prepararConsultaDetalhes(detalhes: TFDRdbmsDataSet; dsMestre: TDataSource; campoMestre, camposIndice: string); begin detalhes.MasterSource := dsMestre; detalhes.MasterFields := campoMestre; detalhes.IndexFieldNames := camposIndice; detalhes.CachedUpdates := true; detalhes.SchemaAdapter := TFDSchemaAdapter( TFDRdbmsDataSet( dsMestre.DataSet ).SchemaAdapter ); detalhes.FetchOptions.DetailCascade := true; detalhes.UpdateOptions.CheckRequired := false; end; Consultas: /// Tabela salarial tabela := TFDQuery.Create( Self ); tabela.SQL.Add( 'select * from tabelas_salariais where id = :id' ); tabela.par( id ); <- o método par já faz a configuração para o parâmetro TUtil.Dados.prepararConsultaMestre( tabela ); tabela.Open; /// Classes de tabelas classe := TFDQuery.Create( Self ); classe.SQL.add( 'select * from tabelas_salariais_classes where idTabela = :id order by codigo' ); classe.par( id ); <- o método par já faz a configuração para o parâmetro TUtil.Dados.prepararConsultaDetalhes( classe, ds, 'id', 'idTabela' ); classe.Open; /// Níveis salariais nivel := TFDQuery.Create( Self ); nivel.SQL.Add( 'select * from tabelas_salariais_niveis where idClasse = :id order by codigo' ); nivel.ParamByName( 'id' ).DataType := ftInteger; TUtil.Dados.prepararConsultaDetalhes( nivel, dsClasse, 'id', 'idClasse' ); nivel.Open; /// Valores salariais valor := TFDQuery.Create( Self ); valor.SQL.Add( 'select * from tabelas_salariais_valores where idNivel = :id order by iniValidade desc' ); valor.ParamByName( 'id' ).DataType := ftInteger; TUtil.Dados.prepararConsultaDetalhes( valor, dsNivel, 'id', 'idNivel' ); valor.Open; Agradeço antecipadamente qualquer dica ou sugestão, bem como indicar algum possível erro na estrutura.

Pessoal, boa tarde! Estou com a versão mais recente do ACBr e um problema esporádico vem acontecendo. O ACBr, ao executar o método SSL.validar, levanta o erro abaixo, mesmo com o valor do atributo Id estando correto. Element '{http://www.esocial.gov.br/schema/lote/eventos/envio/v1_1_1}evento', attribute 'Id': 'ID1186090030000002022012015172300191' is not a valid value of the atomic type 'xs:ID'. O valor ID1186090030000002022012015172300191 é gerado pelo meu sistema e segue o padrão definido pelo eSocial. Esse em específico é rejeitado mas se eu gerar outro com uma hora diferente, por exemplo, o ACBr valida normalmente. Nesse exemplo acima, eu comentei a validação do XSD na linha do SSL.Validar e o eSocial de testes recibou o lote normalmente. Alguém já passou por esse poblema?

Pessoal, Com a dica o Juliomar, eu fui fuçar o projeto para ver oq poderia estar ocasionando esse problema e descobri que foram copiados dois arquivos para o diretório dele, que ganhou prioridade sobre o do ACBr. Problema resolvido! @Juliomar Marchetti, valeu!

Olá Juliomar! Obrigado pelo apoio. Minha primeira opção era com o "Libxx" marcada porém, o Delphi não consegue localizar nada do ACBr. Essa opção de "tirar o path dos fontes" seria isso? OBS.: Não existe nenhuma alteração local. O diretório está limpo, apenas com o checkout do trunk2 nesta url: https://svn.code.sf.net/p/acbr/code/trunk2/

Boa tarde pessoal! Perdi meu HD e precisei adquirir outro. Dessa vez, graças, foi um SSD! Porém, ao atualizar o ACBr do trunk2 e fazer a instalação normal dele, meu projeto fica com esse erro no método GerarIdeEvento3 ( também ocorre com a GerarIdeEvento2). A assinatura de ambos não possui todos os parâmetros informados. Isso é uma falha ainda não reportada do trunk2 ou eu fiz algo errado? Agradeço pelo apoio antecipadamente!

Bom dia pessoal! Não consegui encontrar nada aqui no fórum sobre isso. Isso não acontecia antes e após atualização do Trunk2 (nenhuma alteração local), o aplicativo passou a dar uma mensagem como na imagem anexada, mesmo com o certificado válido (acesso realizado ao Portal do eSocial). Agradeço antecipadamente!

Pessoal, Entendimento errado sobre a validação do RAT. Por favor, podem encerrar este tópico.

@Juliomar Marchetti, obrigado pela dica. Problema resolvido!