Paulo Aguiar Junior

Aqui faz a consulta normalmente, como qualquer outro evento:
RetConsultaLote := ACBreSocial.WebServices.ConsultaLote.RetConsultaLote;
Percorre os eventos retornados:
for IndiceEvento := 0 to RetConsultaLote.RetEventos.Count - 1 do
Faz a consulta normal, ai você percorre o RetConsultaLote.RetEventos.Items[IndiceEvento].tot
for IndiceTotalizador := 0 to RetConsultaLote.RetEventos.Items[IndiceEvento].tot.Count - 1 do
Ai você checka se é o evento S-5001: 
case RetConsultaLote.RetEventos.Items[IndiceEvento].tot[IndiceTotalizador].Evento.TipoEvento of
           teS5001:
           begin             
                EvtS5001 := TS5001(RetConsultaLote.RetEventos.Items[IndiceEvento].tot[IndiceTotalizador].Evento.GetEvento);
 
                //Aí você pega as informações que desejar  
           end;
end;

Olha o exemplo prático:
No S-1210 da competência 10/2018 desse funcionário, tem a folha do mês 09/2018 e o adiantamento de salário do mês 10/2018, ambos com pagamento em 10/2018.

Carlos, boa tarde!
A segunda fase para empresas de até 78 milhões teve o seu início prorrogado. ( http://portal.esocial.gov.br/noticias/esocial-prorroga-inicio-da-segunda-fase-para-empresas )
Quanto ao erro no S-2200 em homologação, segue a instrução do layout:

Só pode ser preenchido se a Categoria for 104.
N (não pode ser preenchido), nos demais casos.

Anderson, boa tarde!
Acredito que você esteja enganado, o nrRecibo dos eventos S-2205 e S-2206 devem sem preenchidos com o número do recibo do S-2205/S-2206 a ser retificado, e não do S-2200.
Esses eventos são alterações cadastrais/contratuais posteriores ao S-2200, como um esquema de vigências por exemplo, sabe? Não se trata de uma retificação...
Exemplo:
S-2200 - 01/01/2018
Nome: Eliana Ferreira
Em 01/08/2018, ela se casou e alterou o seu nome:
S-2205 - 01/08/2018
Nome: Eliana Ferreira dos Santos
Repare que o S-2205 não retifica o S-2200, fica o histórico no e-Social que até 31/07/2018 ela se chamava Eliana Ferreira, e que em 01/08/2018 seu nome foi alterado.
Vamos supor que você enviou Eliana Ferreira dos Santox (o X no lugar do S), nesse caso você deveria enviar uma retificação do próprio S-2205, ou seja, preencheria o nrRecibo com o recibo do S-2205 original.
Foi só um exemplo, acho que o eSocial nem aceitaria esse caso, pois há uma validação entre CPF/PIS/Dt.Nascimento e Nome constantes da Receita Federal.
 
 

Carlos, o evento S-2190 pertence ao grupo 2 (Não Periódicos), o seu XML está preenchido com grupo 1.

Você está gerando por onde?
Se for pelo AcBr acredito que esteja desatualizada a sua versão...

Luiz, além de setar o ambiente no componente AcBr, para cada evento tem a propriedade do ambiente.
Provavelmente no componente está homologação, e na geração do evento S-1000 em produção restrita.
No caso do S-1000: evtInfoEmpregador.IdeEvento.TpAmb
@Luiz Neto

@Pedro R Tortoro
Bom dia, ao que tudo indica você não setou valor no campo ideTabRubr.
 

Bom dia, o XML que você anexou foi enviado na versão 2.4.01...

 

Alisson, esse erro ocorre quando a base já está zerada...

É exatamente o que eu disse nesse post, não se trata de sucessão de vínculo.
Você não deve gerar esse grupo (sucessaoVinc), e sim gerar o S-2206.
Esse caso de transferência para matriz/filial não deve gerar sucessão de vínculo, e o tpAdmissao é 1.

Alisson,
Cada registro S-1000 corresponde a um registro no seu banco de dados, correto?
Você precisa salvar o ID de cada evento gerado no seu respectivo registro no banco (é o único campo que você pode vincular quando efetuar a consulta), e após consultar, você deve percorrer a estrutura RetConsultaLote.RetEventos.Count, e ir localizando (em uma query, por exemplo) pelo RetConsultaLote.RetEventos.Items.Id.
No meu caso, nessa query que eu citei, eu dou um select em todos os registros do banco de dados que contém aquele protocolo de envio que eu estou consultando, ou seja, esse é outro campo que eu preencho para cada registro que foi gerado no meu lote. Dessa forma, dou o select em todos os registros do lote que vou consultar, consulto, percorro o retorno (RetConsultaLote.RetEventos.Count), e faço um dmESocial.qryBuscaEventosProtocolo.Locate('ID_EVENTO', RetConsultaLote.RetEventos.Items.Id, []) para encontrar o registro no meu banco.
No loop, você pode verificar o RetConsultaLote.RetEventos.Items.Processamento.cdResposta, para saber se o registro foi processado ou não. Caso tenha sido processado, o campo RetConsultaLote.RetEventos.Items.Recibo.nrRecibo estará preenchido com o devido recibo, caso em que você deve armazenar esse recibo (que é o seu comprovante de entrega), caso contrário, percorra a estrutura RetConsultaLote.RetEventos.Items.Processamento.Ocorrencias.Count, para pegar as ocorrências (erros) desse registro que está percorrendo e armazenar p/ mostrar para o usuário.
Essa é mais ou menos a lógica que estamos utilizando aqui...