Jump to content
Notícias do ACBr

click.png

click.png

click.png

click.png

click.png

click.png

clube mobile


Cursos grátis para toda base ACBr
+ Promoção Clube Mobile para o ACBr Pro

Saiba mais

adriano santos

click.png

click.png

click.png

click.png

click.png

click.png

jcmferreira

Membros
  • Content Count

    17
  • Joined

  • Last visited

Community Reputation

1 Neutral

1 Follower

About jcmferreira

  • Rank
    Novato

Profile Information

  • Sexo
    Masculino
  • Location
    Olinda

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Paulo, já suspeitava disso. Mas é sempre bom consultar a experiência de vocês, pois sempre há oq acrescentar. O melhor disso é que se vc entrar no site do "semáforo" do eSocial tá sempre tudo verdinho. Dá pra confiar mesmo? Valeu pela ajuda!
  2. Pessoal, São poucas as vezes, mas acontece também no envio de lotes. Nesse caso, o erro mostra mais clareza e aparenta ser algo efetivamente do web service do eSocial. Novamente, o erro capturado pelo ACBr em negrito. Falha ao enviar lote grupo periódico. Evento: S-1210 Período apuração: 08/2018 Detalhes: WebService: http://www.esocial.gov.br/servicos/empregador/lote/eventos/envio/v1_1_0/ServicoEnviarLoteEventos/EnviarLoteEventos - Inativo ou Inoperante tente novamente. Erro Interno: 10060 Erro HTTP: 500
  3. Bom dia pessoal! Já faz algum tempo (uns 3 meses, acho), tenho notado que algumas consultas ao eSocial de protocolo tem retornado um erro com certa frequência. O conteúdo abaixo é um texto montado pela nossa API, mas o erro capturado pelo ACbr é a parte em negrito. Alguém já se deparou com isso ou tem ideia do que seja? Falha ao consultar o protocolo de nº 1.1.201809.0000000000XXXXXXXXX. Código da hierarquia: 01 Evento: S-1210 Detalhes: Erro Interno: 0 Erro HTTP: 403 Já antecipo meu agradecimento para qualquer ajuda!
  4. Paulo, obrigado pelo retorno! Pelo que vi do teu exemplo, não é tão diferente assim. No nosso caso, no lugar do arquivo PFX, informamos os dados dele, que são gravados no banco de dados da gente. Aqui, temos mais de 100 clientes funcionando e alguns deles, desde a 1ª fase, sem nenhum problema. Apenas nesse, que adere agora na 2ª, aconteceu essa situação.
  5. Boa tarde pessoal! Por acaso, alguém já se deparou com um problema na hora de carregar os dados do certificado digital? Em nosso sistema, um único cliente está tendo esse problema. No cadastro do empregador, alguns dados do certificado, após a sua carga, são salvos no banco de dados. Isso inclui CNPJ/CPF, razão/nome, data de validade e o número de série. Acontece que na nossa rotina, o número de série fica mudando e em alguns casos, vem uma cadeia de zeros, como se a leitura não houvesse sido feita com sucesso. Essa é a forma como estamos carregando o certificado e lendo se
  6. Alisson, Na verdade, apenas queria entender o contexto do erro. Uma forma de resolver isso transparente, sem precisar aprofundar muito na lógica. Mas já que vc entrou nesse assunto, o nosso sistema, na prática, é um web service próprio (desenvolvido por nós mesmos) que fornece uma série de APIs rodando pesadamente em multi-thread e totalmente assíncrono. O RH3 Smart é o produto responsável por todo esse gerenciamento do eSocial dentro do ambiente dos clientes. Tudo de forma transparente e sem interferência do usuário em quase 90% dos casos (salvando-se os eventos que são requisitados para
  7. Alisson, valeu pela preocupação! Esse "erro" (caso confirmado o timeout mencionado por você) está ficando com uma frequência relativamente chata agora. Passou a gerar incomodo em alguns casos. Nossa solução está da seguinte forma: Enviamos um lote (nunca em paralelo) Dependendo do retorno (caso resposta positiva e exista o protocolo), realizamos a primeira consulta (aqui, o tempo não chega em 1 minuto... é na sequencia mesmo) Caso haja 101, tentamos ver se a tag de tempo estimado veio (nunca vi na vida, pra ser sincero). Caso negativo, damos um intervalo de 3 minu
  8. Boa tarde pessoal! Estou com um problema estranho, ocorre de forma aleatória e que ainda não consegui identificar. Em muitos dos nossos clientes, quando tentamos consultar o protocolo com o método Consultar, seguindo rigidamente o padrão implementado pelo projeto ACBr eSocial. ERRO: WebService Consulta Status serviço: - Inativo ou Inoperante tente novamente. Erro Interno: 10060 Erro HTTP: 0 Alguém tem ideia do que seja isso? Meus fontes já estão no Trunk2. Agradeço antecipadamente pela ajuda!
  9. Italo, Show de bola! Esse projeto ACBr eSocial é fantástico!
  10. Lukas, O nº do recibo é sempre retornado através da consulta do protocolo, quando o retorno do processamento realizado pelo eSocial foi realizado com sucesso. Pelo ACBr, você faz o envio dos eventos e após isso, realiza a consulta. Essa operação de consulta vai te trazer os recibos de tudo aquilo que foi validado. São com esses números de recibos que será possível realizar retificações, por exemplo, que exigem o recibo original do evento recepcionado e validado no eSocial.
  11. Boa tarde pessoal, Por acaso, é possível fazer a validação contra um XSD que não seja via arquivo e sim, via stream? Exemplo: O conteúdo XDS de um evento qualquer está gravado em uma tabela no banco de dados e assim, o ACBr faria a carga desse XSD via stream do banco, sem precisar gravar um arquivo fisicamente em disco? Antecipo meus agradecimentos .
  12. Já foi conversado com a equipe de analistas da empresa e podemos fazer uma migração 100% para o ACBr em um momento futuro. Isso facilitaria as nossas vidas nesse sentido. Mas hoje, precisamos apenas fazer o envio e consulta novamente com a nova versão do componente.
  13. Juliomar, Obrigado pela atenção! Já chegamos a dar uma olhada. Percebemos que a nossa versão, até então, possuía a propriedade XML para definir o conteúdo do XML para o envio (que já estava assinado pelo próprio ACBr). Essa propriedade não existe mais e agora, parece ser preciso fazer isso através de Eventos.LoadFromString. Outra modificação é com o objeto que define a consulta ao lote. Também conseguíamos acessar o XML enviado através da propriedade WebServices.ConsultaLote.XMLEnvio. Hoje, não mais. Gostaria de não precisar fazer nenhum tipo de modificação nos arquivos ori
  14. Boa tarde pessoal! Antes de qualquer dúvida, quero dizer que o projeto ACBr eSocial é fantástico e seria extremamente mais simples para mim hoje, poder estar 100% nele. Contudo, o projeto da empresa já foi iniciado há algum tempo e já havia toda uma estrutura de objetos feita para a geração automatizada de arquivos XML baseados nas tabelas do sistema. Isso foi aproveitado na empresa para o eSocial. Hoje, o sistema consegue gerar o XML completo para envio ao eSocial, conforme layout. Utilizamos todo o resto do ACBr: assinatura, validação do XSD, envio e consulta do retorno. Perfeição!
  15. Italo, Na altura do campeonato, não há condições nenhuma de migrar todo o sistema, que é uma API restfull em Delphi rodando em cima do IIS, para utilizar o ACBr em toda a sua capacidade funcional. Acredito que seria muito mais simples, inclusive. Porém, consegui resolver o problema da assinatura dos arquivos. O erro, na verdade, era uma exceção tratando a inexistência de um nó específico. Obrigado pelo feedback.
×
×
  • Create New...