Alisson Souza Pereira

Era bom ver o XML de retorno, não veio nada nas ocorrências? isso acontece p/ todos os eventos?

Mostra o XML

1) Verifique o seu XML no campo ID do evento Caso o ID seja o que o ACBr gerou: Em cada evento utilize SELF.ID Caso o ID seja vc que esteja gerando: lebre-se da regra ( Manual do desenvolvedor v1.5.01 item 6.2 pag 63 (Identificação do Evento)) Na hora de montar o ID

@Rafael Dias Aproveita e já corrige eSocial_Conversao o type tpIndMatProc está desatualizado, não existem as opções 7 e 8 eSocial_Conversao.pas

Sim, se o URI for preenchido o eSocial recusa o lote, acontece o seguinte retorno na hora de consultar o lote Resposta: 142 Caminho ou tag : /eSocial/Signature/SignedInfo/Reference/@URI Descrição: Assinatura do evento inválida. A assinatura do evento deverá ser realizada sobre todo documento Xml (Atributo 'URI' dever ser vazio). por isso fiz aquela alteração, para não deixar preencher com "Id" Justamente por que o ma

Vai em eSocial_Gerador function TeSocialEvento.Assinar substitui XMLAss := SSL.Assinar(String(ArqXML), 'eSocial', NomeEvento); por XMLAss := SSL.Assinar(String(ArqXML), 'eSocial', NomeEvento,'','','','ID');

Aproveita e Corrige a function function TConsultaLote.TratarResposta: Boolean; pois no retorno da consulta de um lote com mais de 1 evento ele esta fazendo errado. Segue em anexo as alterações que fiz na função. ACBreSocialWebServices.pas

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.