-
Total de ítens
490 -
Registro em
-
Última visita
-
Days Won
3
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por arce
-
-
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.
-
27 minutos atrás, ALTAMOGIANA disse:
Boa Tarde Arce
Estou realizando este procedimento(armazeno o protocolo), mas o problema ocorre no momento do retorno da consulta(que da energia ou rede).
Andei pesquisando aqui no Forum e o pessoal está enviando o ID do evento no envio do Lote para retornar o número do recibo.
Esta solução(gambiarra) que o governo criou não consta nos manuais e sim no site(perguntas e respostas).
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
- 1
-
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.
- 2
- 1
-
2 horas atrás, Italo Jurisato Junior disse:
Bom dia Luciano,
Você deve estar se referindo ao evento 2010, correto?
Pois bem, segundo o layout desse evento o campo cnpjPrestador só ocorre uma única vez dentro do XML, portanto o grupo <nfs> que aparece abaixo pode ocorrer "N" vezes.
Logo todas as notas ADD no evento são de um único prestador.
Não conheço a fundo o Reinf, mas concluo que caso você tenha notas de 3 prestadores será necessário gerar o evento 2010 3 vezes, um para cada prestador com as suas respectivas notas.
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.CitarInformar o número do processo administrativo/judicial ou do benefício de
acordo com o tipo informado em {tpProc}.
Validação: Deve ser um número de processo/benefício válido e:
a) Se {tpProc} = [1], deve possuir 17 (dezessete) ou 21 (vinte e um)
algarismos;
b) Se {tpProc} = [2], deve possuir 20 (vinte) algarismos;
c) Se {tpProc} = [3], deve possuir 10 (dez) algarismos;
d) Se {tpProc} = [4], deve possuir 16 (dezesseis) algarismos.
-
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.
-
@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.
- 1
-
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
-
@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 =/
-
1 hora atrás, anderson.mendonca disse:
@Italo Jurisato Junior, encontrei este vídeo e nele diz que o evento S-1060 só deverá ser enviado a partir de 01/2019.
Pesquisei e encontrei vários links que relatam o mesmo.
Procede?Sim, pq ele é um evento relacionado a Saúde e Segurança do Trabalho
- 1
- 1
-
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.
-
Agora, anderson.mendonca disse:
Sim @Paulo Aguiar Junior, mas se eu gero na versão 2.04.02 a mensagem de erro é a mesma.
Vou gerar na versão 2.04.02 e anexar os arquivos...À propósito, obrigado por responder.
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>
-
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)
Dúvidas: S-1050 x Professor
em ACBreSocial
Postado
@brunotiem casos como este, estou marcando tag perHorFlexivel como Sim. Devido a esta inconstância dos horários.