Jump to content

click.png

click.png

click.png

click.png click.png click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

Jucemar Duarte

Membros
  • Posts

    37
  • Joined

  • Last visited

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Jucemar Duarte's Achievements

Contributor

Contributor (5/14)

  • Reacting Well Rare
  • First Post
  • Collaborator Rare
  • Week One Done
  • One Month Later

Recent Badges

13

Reputation

1

Community Answers

  1. Olá Marcelo! Seu trabalho no fonte do S5013 ficou muito bom. Tenho apenas duas considerações a fazer: 1) IndApuracao não está presente no layout 2.5. No meu fonte, eu incluí um teste a mais em TEvtFGTS.LerXML. Ficou assim: if leitor.rExtrai(2, 'ideEvento') <> '' then begin if VersaoDF >= veS01_00_00 then IdeEvento.indApuracao := leitor.rCampo(tcInt, 'indApuracao'); IdeEvento.perApur := leitor.rCampo(tcStr, 'perApur'); end; 2) No create do seu TInfoBaseFGTS, você fez: constructor TInfoBaseFGTS.Create; begin inherited Create; FBasePerApur := TBasePerApurCollection.Create; FInfoBasePerAntE := nil; end; Sabendo-se que FBasePerApur e FInfoBasePerAntE têm o mesmo comportamento, não entendi porque você deu um Create em um e Nil no outro.
  2. Obrigado, Marcelo. Estou finalizando a minha própria versão da unit. Vou comparar com a sua. Depois posto os comentários.
  3. Olá! Ao atualizar o componente, o evento de retorno S-5013, definido em pcesS5013, não traz a programação ajustada para o e-social Simplificado. Alguém pode confirmar isso?
  4. Patrick, você estava certo. A distribuição da remuneração por Operador é feita pelo campo codLotacao; o CNPJ deve ser o do próprio OGMO, declarado no S-1005. Muitíssimo obrigado por ter disponibilizado alguns minutos do seu tempo para me ajudar. Fico te devendo!
  5. Sim, sim, Patrick. Faz todo sentido. Vou testar esta noite. Depois te falo. Caro Paulo, dê uma olhada na sugestão do amigo Patrick, mais acima. Acho que ele matou a charada.
  6. Sim. Todos foram enviados no último release da versão 2.5. Todavia, sua ideia não vai funcionar. Em um mês, um trabalhador avulso presta serviço para vários Operadores Portuários diferentes, o que, por si só, já inviabiliza a tentativa de declará-los como cedidos.
  7. Caro Paulo, o trabalho avulso portuário não se enquadra nessa modalidade de trabalho por sessão. De qualquer forma, agradeço por mais essa importante sugestão.
  8. Olá Patrick! A tua sugestão é interessante. No grupo <ideEstabLot> temos os campos 'nrInsc' e 'codLotacao'... Pelo que entendi, na sua visão, em 'nrInsc' deveria ser o CNPJ do próprio estabelecimento do OGMO e o rateio por Operador seria feito em 'codLotacao'? Na minha análise, o rateio com a discriminação das verbas pagas por cada operador seria definida pelo CNPJ presente em nrInsc. Imaginei que, ao fornecer o CNPJ do OGMO iria misturar a folha dos trabalhadores avulsos com a folha dos funcionários do próprio OGMO. É algo que pode ser testado. Obrigado.
  9. Olá, Paulo Aguiar! Já chequei isso. Todos os operadores foram devidamente declarados no evento S1020, com tipo 08 e FPAS 680; assim como também, os trabalhadores informados no S2300, na categoria 201.
  10. Olá, amigos! Estou há 20 dias duelando com os "especialistas" do suporte do e-social. Estou obtendo um erro que parece fugir do previsto nos manuais. Abro este tópico na esperança que algum dos amigos tenha passado por situação similar e possa me ajudar. Vamos lá, então! Ao enviar qualquer evento de remuneração S1200, é retornado o erro 272: "A inscrição informada deve ser o CPF do empregador, caso de empregador doméstico, ou ser um estabelecimento do empregador devidamente cadastrado no sistema no período". Localizacao: eSocial/evtRemun/dmDev/infoPerApur/ideEstabLot. Pois bem, meu cliente é um Órgão Gestor de Mão de Obra (OGMO), associado ao setor de trabalho avulso portuário. Os trabalhadores avulsos portuários não possuem vínculo com o OGMO, por isso, são informados por meio do evento S2300. Nos eventos de remuneração, eles são lotados ao tomador do serviço, neste caso, um Operador Portuário. Desta forma, no demonstrativo de remuneração do evento S1200, é informado o CNPJ do Tomador/Operador Portuário. Todos os Operadores Portuários foram devidamente declarados nos eventos S1080 (Operador Portuário) e S1020 (Lotações) e estão ativos no período. Portanto, aparentemente, não há motivo para o erro apresentado. Antes que alguém pergunte, o e-social não permite que os Operadores Portuários sejam lançados como Estabelecimentos no evento S1005 - cheguei a testar essa possibilidade. Se alguém tiver qualquer explicação, por mais boba que seja, será bem-vinda. Já esgotei toda a minha imaginação! Quanto à equipe de suporte do e-social... lamentável!
  11. EMBarbosa, você tem razão. Eu cheguei à mesma conclusão ao estudar melhor o assunto. Obrigado.
  12. "No meu caso faço a tratativa antes, mando para o componente apenas os 50 registros, no segundo envio mando os outros 50." - Alisson, Pois é, amigo Alisson, atualmente estou jogando na conta do usuário escolher quais registros ele quer enviar (com limite de 50). Mas isso não é nada elegante. Vou estudar o assunto. Acredito que dê para fazer sim. Acompanhe comigo: minha aplicação gerou um XML gigante com (por exemplo) 100 eventos. Quando carrego para o componente, o mesmo particiona em 100 XMLs já assinados. Vou tentar fazer com que, na montagem do lote, o componente gere, em vez de um, quantos lotes forem necessários para satisfazer a requisição.
  13. 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?
  14. Olá, amigo Marcelo Pontes Melim, primeiramente, parabéns pelo trabalho. Estou analisando suas adequações para o e-social simplificado. Apareceu uma questão em "pcesConversaoeSocial". Na function "StrToVersaoeSocial", a correta atribuição da nova versão, segundo o formato do esquema, não seria obrigatoriamente,, '_S_01_00_00' ? Veja a ilustração:
  15. Patrick, sua explicação está perfeita! Tal como eu mesmo havia interpretado. Funcionaria sem problema se não fosse por um detalhe: a folha em questão tem mais de um evento de pensão. Explicação: A folha que estou integrando pertence a uma categoria de trabalhadores avulsos que não possuem férias e 13º. Todavia, por meio de acordos, em sua folha mensal são pagas verbas compensatórias de férias e 13º. Isso acaba gerando, obrigatoriamente, a cada mês, as rubricas de desconto de Pensão Mensal, Pensão Férias e Pensão 13º. Meu amigo, isso é só o começo! O evento S1210 se relaciona com os demonstrativos do evento S1200, os quais estão rateados por Tomador. Imagine que em um mês o trabalhador preste serviço para dez tomadores diferentes, o layout iria gerar 30 registros iguais no grupo <penAlim>. Sem contar a possibilidade do cara ter mais de um dependente. Isso é muito estranho!
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.