Ir para conteúdo
  • Cadastre-se

jcmferreira

Membros
  • Total de ítens

    48
  • Registro em

  • Última visita

Posts postados por jcmferreira

  1. 1 minuto atrás, Juliomar Marchetti disse:

    está falando dos componentes?

    sim ao instalar ele na IDE é setado os paths para win64. então só mudar sua aplicação para win64.

    lembrando que só tem mesmo mudanças se tu fizer calculos matemáticos o win64 pois senão não haverá mudanças no processamento de qualquer coisa

    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. 

    image.png

  2. 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.

  3. 14 horas atrás, Renato Rubinho disse:

    Boa tarde,

    Também tem que considerar se o grupo desligamento não foi preenchido, para ser obrigatório o preenchimento, senão, é facultativo.

    • Não deve gerar quando tpRegTrab = 2.
    • Deve gerar quando tpRegTrab = 1 e grupo desligamento não foi preenchido.
    • Outras condições ainda devem seguir como é hoje para poder ser facultativo.

    Se quiser colaborar, anexe o fonte com a melhoria validada para os consultores analisarem.

    Screenshot_20220705-174346_Google PDF Viewer.jpg

    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. 

    • Curtir 3
  4. 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!

  5. 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.

  6. 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?

  7. @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.

  8. 12 minutos atrás, Juliomar Marchetti disse:

    o tls 1.2 só se tu usa o capicom via surtir efeito sua alteração no internet explorer. senão no wincrypt e no openssl é no componente que tu seta ssltype pra tls 1.2

    sobre as mudanças que falei , seria sobre o que pode identificar da revisão que tu estava para a atualização que tu fez e indicar no fonte do acbr oque foi feito de mudança pra isso ocorrer?

    outra situação importante é as dlls do openssl que devem usar 1.0 ou superior

    @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.

  9. 3 minutos atrás, Juliomar Marchetti disse:

    Fazia muito tempo que não atualizava?

    conseguiu identificar no log o que foi mudado?

    lembrando que isso é relativo ao TLS 1.2 e também ao openssl de 1.0 superior que deve usar

    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.

  10. 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.

     

  11. 4 minutos atrás, Juliomar Marchetti disse:

    Não tem mas tu pode contribuir aqui mesmo com o fonte

    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

    • Curtir 1
  12. 9 horas atrás, Renato Rubinho disse:

    Boa noite,

    Olhando o leiaute, aparentemente deve adicionar os campos que faltam, tratando para serem gerados/lidos a partir da versão disponibilizada.

    https://sourceforge.net/p/acbr/code/HEAD/tree/trunk2/Fontes/ACBrDFe/ACBreSocial/PCNeSocial/pcesS2300.pas#l444 

    Screenshot_20220518-220430_Chrome.jpg

    Screenshot_20220518-214749_Chrome.jpg

    Screenshot_20220518-220707_Chrome.jpg

    Leiaute verificado.

    http://svn.code.sf.net/p/acbr/code/tools/DFe/eSOCIAL/Leiautes do eSocial v. S-1.0 (cons. até NT 04.2021).pdf

    Caso implemente as novas propriedades, reinstale o ACBr para validar e, estando ok, anexe os arquivos alterados para os consultores analisarem.

    Opa amigo!

    Obrigado pela resposta. A pergunta continua...

  13. 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.

  14. 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.

  15. 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?

  16. 55 minutos atrás, Juliomar Marchetti disse:

    refaça a instalação e tire a opção de ter o path dos fontes que talvez vai parar o erro pois parece ter fontes alterado localmente faça revert

    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/

  17. 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!

    image.png

  18. 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!

    erroCertificado.png.38947424102fa8497dcc332c28f5e245.png

  19. 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!

  20. 28 minutos atrás, jcmferreira disse:

    Boa tarde!

    Realizei  o update do Trunk2 nesse momento. Percebi um detalhe: a propriedade "pAliqRat.AliqRat" do pcesGerador, mesmo quando vc não define um valor para ela, vem com o default arat1 (tpAliqRat). Com isso, a tag está sendo sempre gerada. Não sei se é uma falha minha na utilização mas, acredito que ainda existe problema no S-1005.

    Pessoal, ignorem esse post! Problema devidamente resolvido aqui.

×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.