jcmferreira

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!

Bom dia! Em conversa no discord, sobre um erro de retorno do WebService eSocial sobre a assinatura, foi solicitado que um tópico fosse aberto para registro No discord, dois arquivos XML foram enviados para análise: um antes de assinar com o ACBr e outro imediatamente após a assinatura pelo ACBr. A conta no discord está em nome de Marcio Cezar#4078, somos da mesma empresa. Obrigado.

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.