Alisson Souza Pereira

No momento que estou populando cada evento passo o ID que eu monto e na Unit de cada evento substituo ao invés de chamar a função gerar ID passo Self.ID, com isso você é quem controla o ID de cada evento.

O item 4 e 5 resolvem o problema da assinatura

Eu estou conseguindo enviar e sem problemas, tive que fazer algumas adaptações. 1) Descomente o FOnTransmissaoEventos em ACBreSocial e fiz funcionar pq seu type (TeSocialEventos) passou para a unit de conversões 2) a URL esta utilizando a antiga em LerServicoDeParams TACBreSocial 3) ACBRESOCIAL_VERSAO = '2.4.01'; 4)No create do ACBreSocial Descomentei a linha que fala que o método será SHA256 5) Em eSocial_Gerador na função Assinar troquei XMLAss := SSL.Assinar(String(ArqXML), 'eSocial', NomeEvento) por XMLAss := SSL.Assinar(String(ArqXML), 'eSocial', NomeEvento,'','','','ID'); 6) TeSocialGrupo em conversoes substituiu o TTypeESocialGrupo em ACBreSocial 7) Em cada evento coloquei Self.Id ao invés de gerar o ID pelo função do ACBr

Em eSocial_Gerador Se o parâmetro for em branco ou "Id" ele entende que tem que assinar para cada evento (Se olhar as funções mais a frente verá que o IdAttr acaba virando "Id" ) Acredito que eles devam consertar isso nos próximos commits. URI sempre será preenchido com "Id" se não for passado algum valor no parâmetro IdAttr. Optei por passar "ID" maiúsculo

Configura o SSL para Utilizar o padrão Sha256 no create do TACBreSocial tem um código comentado Basta remover o comentário.

No caso teria que ser um único lote com os 1000 registros, o eSocial é bem categórico nesta parte, poderão conter apenas 50 eventos por lote e cada protocolo serve para consultar um lote. Lembrando que o protocolo é gerado pelo eSocial. Então se o eSocial não mudar o seu processo, isso não irá acontecer.

Exatamente na seção 5.6.1 deixa bem claro. Tentei recriar este erro p/ verificar se a regra vale apenas para o evento ou para eventos de tabela em geral, ou seja, 1) para enviar S-1010 preciso esperar o processamento de outros S-1010 ou 2) Para enviar S-1010 preciso esperar o processamento de qualquer outro evento de Tabela porém o eSocial processa mais rápido do que eu consigo enviar o manual dá a entender que seria a segunda opção, porém não consegui recriar na prática.

Exatamente, mensalmente será enviado 1 evento para cada colaborador (fluxo normal), ou seja, cada S-1200 é equivalente a 1 colaborador que podem ser agrupados em lotes no momento do envio.

Esse retorno é da requisição de envio ou é o retorno da consulta? Qual o código do retorno ?

Ao consultar os eventos no eSocial por meio do protocolo, todos os eventos estão retornando "101 - Lote aguardando processamento" a mais de 30 min... e geralmente levava entre 1 e 5 seg, Acredito que o WebService deva estar com algum problema, a situação se repete p/ mais alguém? ou sabem o motivo? Não há nenhuma informação referente a isto no portal. Obs* Ainda estou realizando testes em minha mensageria e isto ocorre em ambiente de homologação, não sei se em produção está ocorrendo a mesma coisa.

O Evento S-1060 Pertence ao Grupo de SST e está previsto p/ 2019, logo o mesmo não estará disponível nem mesmo em homologação.

Com base neste exemplo, e após algumas alterações no core, estou conseguindo mandar e receber os dados.

Me deparei com este mesmo problema, por isso continuo trabalhando apenas com PFX

Estou com problemas na assinatura do XML, acontece o seguinte erro. MEU XML XML DE EXEMPLO Acontece isso também obs: meus fontes estão atualizados de acordo com a postagem acima.