Paulo Aguiar Junior

Então Lucas, está ocorrendo em qualquer SO aqui, é um problema que já corrigimos no início do eSocial... Porém agora fizeram alterações nesse commit que eu citei e recolocaram o erro no código. Eu fiz o update do ACBr todo e reverti a unit do commit 16184 que alteraram. Valeu!

Fala Italo, beleza? Utilizo a xsLibXml2... Como eu disse, corrigimos no início do eSocial esse problema, e agora com essas alterações, voltou o problema. É como se fosse assinado um XML, e enviado outro (com alguma diferença).

Boa tarde! No commit 16184 (24/12/2018), foram alteradas as units da libXml2 e xmlSec relatando que foram otimizadas. Acontece que agora o eSocial retorna a seguinte mensagem: "Assinatura do evento inválida. Ações Sugeridas: Verificar se houve alteração do evento após a assinatura. Verificar a validade da assinatura." Já realizei os testes revertendo essas duas units e dessa forma os eventos são enviados normalmente, com retorno de sucesso. No começo do eSocial detectamos esse erro e corrigimos, porém nesse ajuste retornou o problema.

A validação é essa. Se você envia um funcionário com início em 10/2018 referindo-se a um cargo com início em 12/2018, o eSocial irá retornar que não encontrou o cargo. Se você tem um funcionário admitido em 2000, você vai enviar a admissão dele em 2000 e informar que é um cadastro inicial, certo? Nesse caso, você deve enviar o cargo (iniValid) com a data de início da obrigatoriedade do eSocial (de acordo com o grupo)... Quando é cadastro inicial, provavelmente, o eSocial procura as suas dependências (cargo, quadro de horários, etc) na data de início da obrigatoriedade.

Beleza lukas, por nada! Nesse caso que você citou, quando enviou o S-2200 o funcionário deveria estar em um cargo já existente. No caso de ser criado um novo cargo em 12/2018, e você queira alterar esse funcionário já existente para o novo cargo, você enviaria um evento S-2206 (alteração contratual) com data 12/2018 informando o novo cargo...

Com toda certeza...

lukas, qual a vigência de início do S-2300? Se for anterior a 12/2018, vai ocorrer o problema mesmo, pois a vigência do seu cargo é 12/2018. Me avise se for esse o problema, do contrário, envie os xml's para analisarmos... Valeu!

Luiz, bom dia! Verifica se você não está preenchendo por engano algum dos outros campos referente a cargo público: acumCargo, contagemEsp ou dedicExcl. Se um deles tiver preenchido, o grupo leiCargo passa a ser obrigatório...

Luana, outra forma de recuperar é através dos XML's. Os seus xml's de envio/retorno não estão salvos em alguma pasta?

Anderson, está estranho... No envio está com tipo 2 (CPF), e no retorno está tipo 1 (CNPJ). Verifica se você não está setando o tipo errado no campo tpInsc.

No meu caso, o componente que gera isso, baseado no tipo de evento, Periódicos, Não Periódicos, etc... Como você está gerando/enviando? Carregando arquivo?

O seu XML está como Grupo 1, sendo que o correto é Grupo 2. <envioLoteEventos grupo="2">

Boa tarde Ramlug, para excluir esse tipo de evento (S-1200), você precisa informar as tags: EvtExclusao.InfoExclusao.IdeFolhaPagto.IndApuracao := iapuMensal; // ou anual EvtExclusao.InfoExclusao.IdeFolhaPagto.perApur := FormatDateTime('YYYY-MM', dtPeriodoApuracao);

Bom dia Carlos, deu certo? Você chegou a receber o recibo do S-1005? Valeu!

Boa tarde, Carlos você precisa estudar o layout, senão vai ser difícil você conseguir trabalhar com o eSocial. Aparentemente o CNPJ que você informou no local de trabalho não está cadastrado no S-1005 (Estabelecimento).

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.

@hpensador ah achei que fosse pelo ACBr, da forma que você utiliza eu nunca trabalhei, não faço nem idéia de como funcione. Abraço

Boa tarde, aqui a gente gera/assina evento por evento. A gente chama a função GerarXML para cada evento que estamos gerando... Exemplo: evtInfoEmpregador.GerarXML; (S-1000) evtTabEstab.GerarXML; (S-1005) EvtTabRubrica.GerarXML; (S-1010) EvtAdmissao.GerarXML; (S-2200) Essa função retorna um boolean que indica se foi gerado/assinado corretamente ou não. Além disso, a gente coloca o GerarXML em um try/except, pois quando há problema de validação de schema, o componente dispara uma exceção, e dessa forma conseguimos pegar a exceção e saber exatamente de qual evento ela veio. E na hora de enviar chamamos apenas o método: ACBreSocial.Enviar(Grupo);

Um exemplo melhor seria uma alteração de salário! Valeu Anderson!!

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.

Pois é, eu fiz o mesmo... fui olhar no semáforo e estava tudo normalizado. O nosso suporte aqui estava conectado remoto ao mesmo tempo em 3 clientes, um em cada máquina, e ao mesmo tempo em um cliente estava enviando e no outro dando a mensagem. Minutos depois acontecia em outro cliente o problema, e em outro processava, e assim por diante...Acredito que esteja bem instável e agora época de fechamento a tendência é piorar. Valeu!!

Boa tarde, nos nossos clientes aconteceu bastante ontem e hoje também... Aparentemente é instabilidade dos próprios webservices, que as vezes retornam, e as vezes não.

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

Carlos, bom dia! Posta o XML enviado por favor...

Tem razão,