Ir para conteúdo
  • Cadastre-se

arce

Membros
  • Total de ítens

    490
  • Registro em

  • Última visita

  • Days Won

    3

Posts postados por arce

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

     

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

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

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

    • Curtir 2
    • Obrigado 1
  5. 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

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

    Citar

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

     

     

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

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

    • Curtir 1
  9. 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 

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

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

     

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

×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.