Alisson Souza Pereira

O eSocial apresentou algumas inconsistências: 1º) O evento foi enviado, porém retornou um erro informando que não foi possível estabelecer uma conexão com o sistema do CPF. 2º) Como o retorno foi uma inconsistência, o evento foi gerado novamente, porém na segunda tentativa o eSocial retorna que o colaborador já está cadastrado. Se eu consultar pelo protocolo do envio (1) o retorno é que não foi possível estabelecer uma conexão com o sistema do CPF. Se eu consultar pelo protocolo do envio (2) o retorno é que o colaborador já existe na base do eSocial. Hipótese: Me parece que no envio (1), o colaborador foi gravado porém ocorreu um erro posterior, este erro foi retornado para o cliente, porém a gravação ocorreu. Problema: não tenho número de Recibo para estes eventos, logo não consigo retificar nem excluir. Os evento que não dependem do número do recibo tais como (S2205, S2206, etc...), dos que fiz o teste, todos funcionaram. Ambiente - Produção Evento S-2200 CadINI 'S' Vou tentar entrar em contato com o eSocial. Se alguém já tiver passado por isso e conhecer a solução ajudaria bastante.

Todo evento possui a função "validar" para confrontar o XML com os Schemas. Estou fazendo assim: Na proteção de código peço para retornar o ID+ A mensagem de erro, consequentemente dentro do lote vc já sabe qual é o evento com erro. No SVN o fonte pcesS2206 já está dessa forma. Sabendo qual é o evento, e o campo que deu erro fica fácil descobrir o erro.

Desculpe, foi modo de dizer. Aconteceu apenas uma única vez e até agora não aconteceu novamente.

Se não vai na primeira tentativa, na segunda ou terceira vai..

Bom dia, Ao enviar o cadastro do colaborador, o eSocial retornou o erro 301 ( Enviei apenas um colaborador, já em produção) A mensagem indica que o servidor está com problemas mais alguém está passando por isso? Mensagem: A solicitação não pode ser atendida devido a uma falha temporária no ambiente ou não catalogada. Favor tentar novamente mais tarde. Código do erro: 301.4. Caso o erro permaneça, favor acessar o Portal do eSocial através do endereço http://portal.esocial.gov.br. Na opção CONTATO, na seção EMPRESAS, selecione PRODUÇÃO EMPRESAS. Preencha os outros campos e informe o identificador 524EC16F2A823B6FB131779DB36EC6267377982C$$0a24ab24-8699-402c-b407-1505e341a1fe em SUA MENSAGEM para rastreamento do erro. Obrigado

Zerar a base e não excluir @fabibona Manual de orientações do desenvolvedor.

Se vc já tem o cadastro destes colaboradores, não tem por que mandar o S-2190, você pode mandar direto o S-2200.

É o seguinte @fabibona Produção a primeira fase = 2018-01 Produção restrita a primeira fase = 2016-01 1) Zere a base do eSocial com S-1000(Limpar a base) 2)Envie os eventos de tabela como se a primeira fase tivesse inicado em 2016-01 3)envie seus colaboradores Se o colaborador começou antes de 2016-01, CadIni deve ser = S Se o colaborador começou após 2016-01, CadIni deve ser = N

@Danilo Junior Baixe os sChemas em: http://portal.esocial.gov.br/institucional/documentacao-tecnica coloque os ARQUIVOS no seguinte caminho : SEU_ACBr\Exemplos\ACBrDFe\ACBreSocial\Delphi\Schemas\ve240

Os eventos S-2200 e S-2206 dividem a mesma funcionalidade "pcesGerador > GerarDuracao". No layout do S-2206 não existe o campo clauAssec, porém a tag está sendo gerada nos dois eventos. consequentemente a validação do XDS impede que o evento seja enviado quando o tipo do contrato for equivalente a 2. Segue em anexo as units com as correções. @Rafael Dias pcesGerador.pas pcesS2206.pas

Obrigado! Zerei a base de produção restrita e gerei o S-2200 (Carga inicial) como se a primeira fase fosse 2016-01.

Situação: Em homologação, estou enviado S-2200 para colaboradores admitidos antes da obrigatoriedade do eSocial cuja a admissão é retroativa em anos ou até mesmo em décadas. estou informando o campo CadIni = 'S', ou seja, o eSocial sabe que é um cadastramento inicial. Problema: para estes colaboradores cujo a admissão é antes do início dos eventos de tabela tais como cargo, empregador, estabelecimento o eSocial reclama que não há período cadastrado para os eventos de tabela, que percorra a data da admissão. Alguém sabe como proceder?

@Joceandro Perin é assim, isso não é aleatório, o eSocial só aceita um lote de evento de tabela por vez, ou seja, se vc mandar um estabelecimento vc tem que esperar todo o processo concluir p/ só dai mandar um de rubrica. isso está escrito no manual. Manual de orientações do desenvolvedor item 5.6.1 "O primeiro evento a ser enviado deve sempre ser o S-1000 ...." O que pode ter acontecido é que as vezes quando vc manda ele já terminou ou não de processar o primeiro lote.

Bom dia, o eSocial entra em produção no dia 01 logo todas as regras de data do envio tem de respeitar o manual, se ele fala que pode ser enviado até o dia 7 do mês subsequente está tudo certo, mas a admissão por exemplo tem de ser enviado com 1 dia de antecedência. Atenção: Já no dia 28/02 tem de ser enviado os S2200 para os colaboradores que iniciaram o vinculo antes do dia 01/03 (Manual de orientações pág 118 item a v2.4)

@arce Foi justamente isso que fiz, mas para não ficar fora daquilo que o ACBr trás, aguardo a correção do próprio ACBr para a minha cópia de trabalho não ficar muito diferente da Trunk pois lá na frente dificulta bastante o merge. vlw

O Campo tpAcidTransito só pode ser preenchido se o codMotAfastt for equivalente a [01,03] Problema: Como o grupo no qual a tag pertence sempre será assinado, e por ele ser um type, o campo sempre será preenchido mesmo que seja um valor default que no caso é tpatAtropelamento O correto seria: se não foi preenchido não deveria ser informado. @Rafael Dias

Qual evento ?? está mandando em produção ou em homologação? verifique as URLS

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