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.

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!

Boa tarde pessoal! Estou com o seguinte problema descrito abaixo e gostaria de saber como vocês estão resolvendo essa questão. Inicialmente, até que esse "dilema" se resolva, eu adicionei no meu sistema, uma opção para que o usuário possa escolher se quer ou não enviar as informações da alíquota RAT ao eSocial. Esse tópico está totalmente focado na opção de NÃO ENVIAR RAT ao eSocial. Com isso, eu não estou definido a propriedade "DadosEstab.aliqGilrat.AliqRat", que está vindo com o default "arat0". Como não existe tal alíquota, acredito que deveria ser uma forma do ACBr entender que não deve gerar a tag. Porém, o eSocial me retorna a ocorrência de erro código abaixo: 1504 - A alíquota informada deverá ser diferente da alíquota definida na legislação vigente para o código CNAE preponderante informado (neste caso, deverá haver informações de processo em procAdmJudRat). No meu caso, a alíquota RAT é 1 e é o mesmo valor definido pelo CNAE do estabelecimento. Só consegui validar o envio do S-1005 quando realizei duas modificações no fonte "pcesGerador.pas": procedure TeSocialEvento.GerarAliqGilRat(pEmp: TIdeEmpregador; pTpInscEstab: tpTpInsc; pAliqRat: TAliqGilRat; const GroupName: string); var bProcJudRat: Boolean; bProcJudFap: Boolean; begin bProcJudRat := False; bProcJudFap := False; if pAliqRat.procAdmJudRatInst() then if pAliqRat.ProcAdmJudRat.nrProc <> EmptyStr then bProcJudRat := True; if pAliqRat.procAdmJudFapInst() then if pAliqRat.ProcAdmJudFap.nrProc <> EmptyStr then bProcJudFap := True; if not(VersaoDF <= veS01_00_00) and not(bProcJudRat) and not(bProcJudFap) and not(pTpInscEstab = tiCNO) then Exit; Gerador.wGrupo(GroupName); if ( (VersaoDF <= veS01_00_00) or bProcJudRat ) and ( pAliqRat.AliqRat <> arat0 ) then <-- VersaoDF <= veS01_00_00 e ( pAliqRat.AliqRat <> arat0 ) Gerador.wCampo(tcStr, '', 'aliqRat', 1, 1, 1, eSAliqRatToStr(pAliqRat.AliqRat)); if (pEmp.TpInsc = tiCNPJ) then begin if (VersaoDF <= veS01_00_00) or bProcJudFap or (pTpInscEstab = tiCNO) then Gerador.wCampo(tcDe4, '', 'fap', 1, 5, 0, pAliqRat.Fap); if (VersaoDF <= ve02_05_00) then Gerador.wCampo(tcDe4, '', 'aliqRatAjust', 1, 5, 0, pAliqRat.AliqRatAjust); end; if pAliqRat.procAdmJudRatInst() then GerarProcessoAdmJudRat(pAliqRat.ProcAdmJudRat); if pAliqRat.procAdmJudFapInst() then GerarProcessoAdmJudFap(pAliqRat.ProcAdmJudFap); Gerador.wGrupo('/' + GroupName); end; No trecho em que a alíquota RAT é validada, precisei trocar a versão para a veS01_00_00 e adicionar a validação para só tentar gerar a tag quando a alíquota for <> de arat0: if ( (VersaoDF <= veS01_00_00) or bProcJudRat ) and ( pAliqRat.AliqRat <> arat0 ) then Gerador.wCampo(tcStr, '', 'aliqRat', 1, 1, 1, eSAliqRatToStr(pAliqRat.AliqRat)); Alguém com alguma dica mais elegante para resolver essa questão? Obrigado!

Pessoal, ignorem esse post! Problema devidamente resolvido aqui.