Ir para conteúdo
  • Cadastre-se

Alisson Souza Pereira

Membros
  • Total de ítens

    193
  • Registro em

  • Última visita

Posts postados por Alisson Souza Pereira

  1. Olá o eSocial / DCTFWeb está calculando o GILRAT errado para os CNOs

    o eSocial estava calculando tudo certo até 2024-12 RAT: 3 / FAP: 0,5 / GILRAT: 1,5 , utilizava a versão 1.2

    A partir de 2025-01, já estou utilizando a versão 1.3 do eSocial, no cadastro está conforme a linha de cima GILRAT: 1,5, mesmo assim ele está calculando o GILRAT com aliquota de 2,6094 ou seja, ignorando o próprio GILRAT e utilizando o do meu estabelecimento MTZ

    Isso ocorre apenas para os CNOs, e até 2024-12 não tinha esse problema de ignorar o próprio GILRAT e usar o da MTZ. 

  2. @Renato Rubinho

    Atualizei os fontes do ACBr revisão 35641
    Para exemplificar, abri os dois fontes na imagem abaixo, o do aCBR e o da correção e a correção possui um método Destroy que foi o que eu implementei

    Não sei o motivo de não ter aparecido no Change de alterações do arquivo ACBreSocialLoteEventos.pas momento da sua revisão

    se possível abra os dois arquivos e verifique manualmente que no arquivo que envie tem o Destroy e no original não existe.  


    image.thumb.png.75f4cc9af1c166244f96dbb53af436a0.png

  3. dentro de pcesGerador.pas só existe uma situação para não gerar a tag, se dtTerm = 0, ou seja, não foi informada 

    vc pode rodar em debug e verificar essa parte como está chegando. 

    Manda esse código que vc mandou acima, só que mais completo, o S2206 inteiro e não só a parte do tipo de contrato

    image.png.0afc89b23249194dcc095acf28fe671c.png

  4. A PORTARIA/MTP Nº 671, DE 8 DE NOVEMBRO DE 2021 Anexo V trouxe atualizações no leiaute do arquivo AFD versão 003 por isso faz-se necessário a sua atualização, principalmente porque os novos relógios estão gerando o AFD já no novo formato. 

    Não removi os fontes da versão anterior do AFD, devido ainda estar sendo utilizada principalmente por relógios antigos, por isso apenas adicionei um novo modelo de AFD. 
    Segundo a portaria os arquivos ACJE e AFDT Foram descontinuados e substituídos pelo AEJ, já havia subido esse novo arquivo AEJ em um outro post, porém não removi a geração desses arquivos antigos (ACJEF e AFDT).  


    Fonte: https://in.gov.br/en/web/dou/-/portaria-359094139


    ACBR\Fontes\ACBrTXT\ACBrPonto
    Fontes.rar

    ACBR\Exemplos\ACBrTXT\ACBrPonto\Delphi

    Exemplo.rar

  5. Olá, desenvolvi a geração do arquivo AEJ, baseado nas informações contidas em: https://www.gov.br/trabalho-e-previdencia/pt-br/composicao/orgaos-especificos/secretaria-de-trabalho/inspecao/fiscalizacao-do-trabalho/leiaute-do-arquivo-eletronico-de-jornada-aej.pdf

    A parte da assinatura digital .p7s, consegui desenvolver também, porém utilizando uma dll não gratuita por isso não incluí no projeto a parte da assinatura digital, mesmo assim creio que já será de grande ajuda todo o resto. 

    ACBR\Fontes\ACBrTXT\ACBrPonto
    ACBrPonto.rar

    ACBR\Exemplos\ACBrTXT\ACBrPonto\Delphi
    Exemplo.rar

    • Curtir 2
    • Obrigado 1
  6. Estou realizando um levantamento para montar a geração do arquivo e uma das exigência é a assinatura digital do arquivo AEJ.txt onde é gerado um arquivo p7s destacado com a assinatura.

    Já uso o ACBr a algum tempo, juntamente com os recursos de assinatura de XML, porém não encontrei no ACBr  a assinatura digital no padrão CAdES para gerar esse arquivo .p7s destacado.

    Sabe me dizer se temos essa assinatura digital e onde encontro?


     

    • Curtir 1
  7. Atualmente temos a geração dos arquivos AFD/ AFDT/ ACJEF pelo ACBRPonto, porém o art. 83 da portaria 671  informa que deve ser gerado o arquivo AEJ com assinatura digital. 

    https://in.gov.br/en/web/dou/-/portaria-359094139

    Segundo a portaria 3.7.17 o arquivo AEJ passa a ser obrigatório a partir de 11/01/2023

    https://www.in.gov.br/en/web/dou/-/portaria-mtp-n-3.717-de-9-de-novembro-de-2022-443015406

    Já está sendo desenvolvido a geração desse arquivo com assinatura digital? 

  8. pcesS2240.pas

    @EMBarbosa

    Como a tag EpcEpi sempre era gerada, ocorria o erro aseguir: 
    "Grupo 'Informações relativas a Equipamentos de Proteção Coletiva - EPC e Equipamentos de Proteção Individual - EPI' não deve ser preenchido. Verifique as condições de preenchimento no leiaute."

    Segue a correção em anexo padronizada com outras situações similares dentro do projeto. 

    • Curtir 2
  9. O componente só irá preencher a tag <infoApr> se houver processo judicial para contratação de aprendiz,

    porém no Leiaute informa que deve ser informado caso haja processo para contratação de aprendiz ou haja contratação por intermédio de entidades educativas. 


    image.thumb.png.83bf2d22d27bad271aa3606a9deef8a7.png

     

    Exemplo de como o XML deve ser preenchido, mesmo que não exista processo judicial

    image.png.0908b389c1f5a3d5ff814ba85ef6891e.png

     

    Segue as alterações no fonte

    pcesS1005.pas

     

    • Curtir 1
  10. Se tiver o certificado digital ou a procução, não há problema algum. 
    Existem outras abordagens onde a empresa de SST entrega o XML a sua empresa e a mesma faz o envio destes XMLs

  11. 1 hora atrás, Jucemar Duarte disse:

    O e-social impõe a limitação de 50 eventos por lote a ser enviado.  Não consegui identificar, dentro do método Enviar do componente ACBreSocial, em que momento esse limite é tratado.  Alguém pode me ajudar?

    Esclarecimento:  Não carrego os registros nos INIs.  Minha aplicação possui uma rotina que gera um XML no formato do esquema (podendo ter mais de 50 registros/eventos).  A partir daí, uso o Eventos.LoadFromFile para transportar para o componente ACBreSocial e assiná-lo.   Em seguida, faço o envio com o método Enviar.  Funciona bem, até encontrar lotes com mais de 50 eventos.  Alguma ideia de como podemos tratar esta questão?

    Pelo que entendi vc não quer que dê erro se passar de 50 e sim que ele consiga enviar fragmentado.

    Se for isso, não vejo como essa regra poderia ser implementada dentro do ACBr, pois se você iniciou o envio ele seria responsável por separar e enviar cada 50 em um lote, teria que saber qual deu certo e qual deu erro, lembre-se que a comunicação é assincrona, pode ser que um lote consiga ser enviado e o outro não...
    ao meu ver seria algo muito elaborado.

    No meu caso faço a tratativa antes, mando para o componente apenas os 50 registros, no segundo envio mando os outros 50.

    Entendo que essa regra deva ficar na aplicação cliente.

    • Curtir 1
  12. 20 horas atrás, Digibyte disse:

    Ninguém iniciou as alterações?

    Qual seria a melhor forma de fazer isso, tratar dentro das classes se gera ou não determinada tag?

    Ou criar classes separadas visto que o layout antigo irá morrer?

    Pelo que estou vendo, ninguém está fazendo ainda e infelizmente na minha previsão só conseguirei mecher com o ACBr a partir de abril. 

  13. Ainda estou atualizando a parte gerencial do meu sistema.
    Diante disso estou me antecipando e verificando se alguém já está tomando a frente nessa parte no ACBr. 

    Sim já atualizei o SVN e não há nenhuma alteração relacionada a versão vS-1.0

    Muito obrigado!

    • Curtir 1
×
×
  • 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.