Jucemar Duarte

Bom dia, senhores! Os campos do evento S2501 ficarão mesmo como "Atributo" no XML? Pensei que eles iriam corrigir a gafe na nova versão.

Olá, colega! Os eventos de SST são do tipo "2 - Não Periódicos".

Caro Marcelo, tua explicação esclarece a dúvida. Analisei o teu código fora do contexto. Foi desatenção minha. A tua implementação está corretíssima!

Senhores, não entendi! A rotina desenvolvida pelo amigo Marcelo não deveria estar dentro de LoadFromFile? O XML que está sendo carregado pode conter informações de qualquer evento, inclusive os de SST. Então, penso que o tratamento deve ser feito dentro do método LoadFromFile. Estou viajando?

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.

Obrigado, Marcelo. Estou finalizando a minha própria versão da unit. Vou comparar com a sua. Depois posto os comentários.

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?

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!

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.

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.

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.

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.

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.

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!

EMBarbosa, você tem razão. Eu cheguei à mesma conclusão ao estudar melhor o assunto. Obrigado.

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

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?

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:

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!

Olá colegas, Me tirem uma dúvida: no layout do evento S1210, o grupo <penAlim>, que trata do detalhamento de pensões alimentícias, está em um nível hierárquico abaixo do grupo <retPgtoTot>. Isso sugere que cada rubrica de pensão deverá gerar (pelo menos) um registro com os dados do pensionista. Os registros do pensionista poderão se repetir de acordo com a quantidade de rubricas dentro do período. Isso é muito estranho! Se for do jeito que estou pensando, teremos inúmeras replicações desnecessária de dados. Tenho receio que esses dados replicados possam em algum lugar interferir em totalizadores internos. Como vocês interpretaram essa questão?

Caro EMBarbosa, já está tudo esclarecido. Segundo as últimas documentações do e-social, a empresa que represento passou a ser do grupo 3, portanto as datas de obrigatoriedade foram alteradas. Obrigado.

Luana, você foi ótima! Tudo esclarecido!

Luana, você está completamente certa! Ogmo entra no grupo de entidades sem fins lucrativos. Estava trabalhando como se fosse do grupo 2. Isso gera outra dúvida: os eventos iniciais de tabelas, enviados com data de início em 07/2018, deverão ser retransmitidos com a data 01/2019?

Luana, muito obrigado por sua interferência... - A alteração da data de início no ambiente de homologação é uma informação muito importante. - Quanto ao motivo por não funcionar no ambiente produção ainda é misterioso. Minha tributação é tipo "09", portanto dentro do prazo para envio. Além disso, não vejo relação com o evento S1005, pois os trabalhadores avulsos (S2300) não dependem dele.

Caros colegas, permitam-me ressuscitar o assunto, pois estou enfrentando um problema similar. Pois bem... 1) Minha empresa se enquadra no grupo 2 na questão de obrigatoriedade. 2) Todos os eventos iniciais foram recebidos com sucesso, usando, como <iniValid>, "2018-07", tanto no ambiente de teste, quanto na produção. 3) Inciamos, então, o envio dos eventos não periódicos com o S-2300 - Cadastro de Trabalhadores Sem Vínculo. O lote foi montado, validado, assinado e enviado. 4) No ambiente de teste (produção restrita), o processamento indica que "não existe o registro do empregador" e, em seguida vários erros em cascata, tal como relatado acima pelo amigo Aristarco Ribeiro. 5) No ambiente produção, me retorna apenas o erro "174 - O evento somente será aceito após a data de início da obrigatoriedade do empregador ao eSocial". Então, para fechar o assunto, qual seria a data inicial correta no meu caso?