arce

@brunotiem casos como este, estou marcando tag perHorFlexivel como Sim. Devido a esta inconstância dos horários.

Fiz duas coisas para evitar esse tipo de problema, não resolve, mas evita que aconteça. Primeiro aumentei o timeout para que o componente espere mais pela resposta do webservice. ACBrReinf1.Configuracoes.WebServices.AguardarConsultaRet := 90000; // tempo padrão que vai aguardar para consultar após enviar ACBrReinf1.Configuracoes.WebServices.IntervaloTentativas := 3000; // Intervalo entre as tentativas de envio ACBrReinf1.Configuracoes.WebServices.Tentativas := 10; // quantidade de tentativas de envio ACBrReinf1.Configuracoes.WebServices.AjustaAguardaConsultaRet := False; // Não ajusta o "AguardarConsultaRet", mantendo o tempo de espera ACBrReinf1.Configuracoes.WebServices.TimeOut := 18000; E a segunda medida, foi limitar a quantidade de registros por lote para 50, apesar do Reinf permitir 100 (vide manuais). Assim o processamento no webservice terá uma resposta mais rápida. Terei q enviar mais lotes? Certamente, mas evita a perda de recibo. Como disse, estes procedimentos não resolvem o problema, mas podem ajudar a evitá-los.

Tbm estou fazendo desta forma.

Ao transmitir o Lote, guarde o número do protocolo que o ACBr carrega em ACBreSocial.WebServices.EnvioLote.RetEnvioLote.dadosRecLote.Protocolo; Depois utilize o comando ACBreSocial.WebServices.Consultar('numero do protocolo'); para consultar o status do lote e saber o retorno. Fazendo este procedimento, vc evita erros causados por inconstâncias do webservice, afinal o modelo do e-social é Assíncrono.

@Italo Jurisato Junior Seria este o problema apresentado? Saiu uma nota oficial da EFD-Reinf sobre http://sped.rfb.gov.br/pagina/show/2687

O S-2200 é a admissão/Cadastramento inicial no qual devem ser enviadas todas as informações do trabalhador, caso haja alguma alteração referente ao contrato de trabalho (jornada, salário, estabelecimento, etc) envia-se o S-2206, se o que foi alterado é alguma informação referente a dados pessoais (estado civil, inclusão de dependente, alteração de endereço, etc) envia-se o S-2205. Basicamente nos sistemas de RH, estes dados são provenientes de um mesmo cadastro (Funcionário/Trabalhador), cabe ao desenvolvedor identificar quais campos pertencem aos eventos S-2200, S-2205 e S-2206, e transmiti-los ao e-Social qndo estes forem alterados.

Entendi desta forma também, e é como estou gerando

O grupo dadosProcJud, dependendo do toProc não pode ser gerado. Se vc passar qualquer info das tags deste grupo o ACBr cria a instância deste no evento S-1070.

A validação do número do processo (campo nrProc) é de acordo com a opção informada no campo tpProc. Isto está escrito no manual, na orientação do campo nProc.

Boa tarde, @Italo Jurisato Junior Ao enviar os eventos S-1295 e S-1299, os métodos de leitura dos arquivos XML do retorno dos eventos S-5011 e S-5012, apresentaram alguns erros semelhantes ao que tinha ocorrido no S-5002 identificado neste post (classes não instanciadas e utilização incorreta dos métodos leitor.rExtrai ). Segue em anexo a correção da leitura do retorno, e os XMLs para realização dos testes. Por favor verifique se as customizações estão corretas. pcesS5011.pas pcesS5012.pas S5011.xml S5012.xml

@michella uma sugestão, como é um evento do primeiro mês, e se ainda não foi lançado nenhum outro evento de folha para o referido funcionário, envie uma Retificação do S-2200 que terá o mesmo efeito

O S-5001 só retorna valores, se houver informações de Retenção de Contribuição Social, ou seja, rubricas do codIncCP que indiquem bases e valores de INSS. O mesmo vale para o S-5002, se não houver retenção de IRRF (exemplo, salário baixo) não constará dados de valores no retorno.

Anexe o XML para análise

verifique o IniValid do evento S-1005 e S-1020, ambos precisam estar com data 2018-01

Anexe o Lote de envio para análise

@Italo Jurisato Junior Fiz a correção do evento S-5002, por favor analise se está correto pcesS5002.pas

@Italo Jurisato Junior parte do problema é que a classe foi nomeada como baseIrrf e o correto é basesIrrf, entretando está dando um erro nas classes desses collection q não está instanciando nos métodos Add, porém não encontrei a falha =/

Sim, pq ele é um evento relacionado a Saúde e Segurança do Trabalho

Caro @anderson.mendonca, usando como base a produção restrita. Pense da seguinte forma, informações anteriores ao e-Social deverão ser inicializadas com a data do inicio da obrigatoriedade do e-Social para a empresa (2016-01). Se um funcionário foi admitido em 15/02/2014, ou seja, já estava contratado qndo o e-Social começou, as tabelas que serão relacionadas a ele tbm devem ser inicializadas em 2016-01. As tabelas são salvas de forma história, tomemos como exemplo o campo aliqRat do evento S-1005: Em 2016-01 o valor era 1% (evento transmitido), depois no ano seguinte o valor foi alterado, logo deverá ser enviado um novo evento de inclusão com o valor de 2% e InValid 2017-01. Ou seja, os eventos coexistem. Pq em 2016 o percentual era um e em 2017 outro. Por isso que o ws aceita vc enviar o S-1000 e S-1005 com iniValid 2018-01. OBS: Recomendo ler em sua totalidade este manual de orientação de preenchimento http://portal.esocial.gov.br/manuais/mos-manual-de-orientacao-do-esocial-2-4-publicada.pdf

@anderson.mendonca Se a empresa que vc está utilizando para testes (Empregador) foi aberta antes de 2016, vc precisa colocar como IniValid 2016-01. Se ela for posterior, vc deve colocar a data de abertura. Ex: Empregador iniciou as atividades em setembro de 2000: usar IniValid 2016-01 Ex: Empregador iniciou as atividades em agosto de 2017: usar IniValid 2017-08 OBS: Em produção usar como base inicial o ano de 2018, em produção restrita (homologação) o ano de 2016.

Além de mudar a propriedade da versão do layout no componente do ACBr, é necessário utilizar os schemas disponível em: ...trunk2\Exemplos\ACBrDFe\Schemas\eSocial\v2_04_02

O XML está correto, me enganei com a transmissão de um dos departamentos =/, que estava com o período incorreto. Mesmo assim, obrigado pela atenção de todos.

<localTrabalho> <localTrabGeral> <tpInsc>1</tpInsc> <nrInsc>59XXXXXX000196</nrInsc> </localTrabGeral> </localTrabalho> S-2200.xml

Bom dia, hoje (19/04/2018) comecei a reenviar todos os eventos após a manutenção do ambiente de homologação. Transmiti corretamente todos os eventos de tabela e o S-2300. Ao tentar enviar o evento S-2200, está retornando a ocorrência 272 - "A inscrição informada deve ser o CPF do empregador, caso de empregador doméstico, ou ser um estabelecimento do empregado devidamente cadastrado no sistema no período ". Verifiquei, e as tabelas estão com o período inicial (2016-01), os funcionários não são domésticos e o empregador é pessoa jurídica. Seria um erro de validação do webservice?

Como mencionei acima o webservice de HOMOLOGAÇÃO está em manutenção hoje dia (18/04/2018) https://portal.esocial.gov.br/noticias/limpeza-da-base-de-dados-do-ambiente-de-producao-restrita-acontecera-em-18-04