Alisson Souza Pereira

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

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