jcmferreira

Olá Juliana, uma dúvida: estou utilizando o Trunk2 e sempre executo o SVN update dele. Porém, essa modificação ainda não consta. Peço desculpas pela ignorância mas, como eu posso saber quando uma alteração/correção vai ficar disponível oficialmente? Ou já está e eu estou olhando para a URL do SVN errada? Obrigado!

Boa tarde! Realizei o update do Trunk2 nesse momento. Percebi um detalhe: a propriedade "pAliqRat.AliqRat" do pcesGerador, mesmo quando vc não define um valor para ela, vem com o default arat1 (tpAliqRat). Com isso, a tag está sendo sempre gerada. Não sei se é uma falha minha na utilização mas, acredito que ainda existe problema no S-1005.

Boa tarde pessoal! Essa função estava funcionando normalmente, mas parece que alguém subiu de forma errada. Também peguei essa situação nesse sábado, conforme tópico que abri: Basta esse ajuste e pronto.

Pessoal, acho que ainda existe divergência no entendimento do FAP no leiaute novo. > Obrigatório e exclusivo para Pessoa Jurídica com Estabelecimento CNO ou CNPJ "E" fator informado diferente do definido pelo órgão competente. Ou seja, se vc informar um FAP e o eSocial conseguir essa informação do órgão competente, ele rejeita a sua informação. A bronca aí é que se vc enviar sem o FAP e ele não conseguir sozinho, o evento é rejeitado pedindo para vc reenviar com o FAP informado. Cara, bizarro esse tratamento no S-1005 do S-1.0!!!

Amigo, Uma ideia interessante, até pq, o eSocial fez a gente ficar nas mãos com relação ao FAP. Antes, na 2.5, o FAP era enviado e se fosse divergente, era rejeitado exigindo o processo. Agora, vc não deve mandar o FAP e caso o eSocial não localize na base, vc reenvia o evento com o FAP. E como ficam os clientes usando o software e que mal sabem ler um retorno desses de eSocial? A simplificação esse ponto virou um complicador, isso sim.

Boa tarde pessoal! Acabei de fazer um update no Trunk2 e após isso, os envios ao eSocial leiaute simplificado S-1.0 deixaram de funcionar. Após um breve debug, percebi que a função "versaoeSocialToStr" foi modificada. Antes: function VersaoeSocialToStr(const t: TVersaoeSocial): String; begin result := EnumeradoToStr(t, ['02_04_01', '02_04_02', '02_05_00', '_S_01_00_00'], [ve02_04_01, ve02_04_02, ve02_05_00, veS01_00_00]); end; Agora: function VersaoeSocialToStr(const t: TVersaoeSocial): String; begin result := EnumeradoToStr(t, ['02_04_01', '02_04_02', '02_05_00', 'S01_00_00'], [ve02_04_01, ve02_04_02, ve02_05_00, veS01_00_00]); end; Alguma explicação pra essa mudança ou melaram o repositório? Posso subir a correção? Obrigado!

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!

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

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!

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.

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 seus dados: mAcbr.Configuracoes.Geral.SSLLib := libOpenSSL; mAcbr.Configuracoes.Geral.SSLXmlSignLib := xsXmlSec; mAcbr.Configuracoes.Certificados.Senha := GetCertSenha; mAcbr.SSL.DadosPFX := ReadStrFromStream( cert, cert.Size ); // cert é o objeto Stream do certificado. try mAcbr.SSL.CarregarCertificado; except on E: Exception do SendErrorResponse( e.Message ); end; Após instalar o certificado no Windows, o número de série exibido é: 55a2808e817b47001285bba956b709a9 Via ACBr, fica alterando os valores: 55A2808E817B47003200630048005300 e 55A2808E817B470069006E0064006F00 Outro detalhe, a data de validade vem com a hora errada. Agradeço antecipadamente pela ajuda de todos!

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 auditoria pré-envio). A descrição feita foi um pequeno trecho do processo de envio de lote e sequencial consulta do protocolo. Mas isso, de forma macro, está ocorrendo em paralelo com outros lotes e consultas, sempre respeitando as regras impostas pelo eSocial. Alguns de nossos clientes na fase de adesão, chegaram a enviar mais de 100.000 eventos em mais de 2.000 lotes de forma assíncrona. Buscamos dignificar o resultado das respostas exibidas aos usuários, numa tratativa mais elegante que um erro HTTP de código "genérico" ao usuário.

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 minutos para a próxima consulta. Fica no "loop" repetindo os passos acima até finalizar todos os lotes que precisam ser enviados, de todos os eventos. Talvez, o problema esteja na consulta imediatamente após o envio do lote, não? Mas confesso que se sim, começou faz coisa de um mês apenas.

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!

Italo, Show de bola! Esse projeto ACBr eSocial é fantástico!

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.

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 .

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.

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 originais do projeto, para podermos ficar sempre atualizando o repositório e manter a compatibilidade que, muito com certeza, foi perdida já faz algum tempo. Já conseguimos validar o XML e assiná-lo, mas o envio não está sendo feito, pois a estrutura e o formado atual é completamente diferente de como estava antes.

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! Nosso único problema é que após a atualização do ACBr para a última versão do Trunk2, isso deixou de funcionar. Gostaria muito de poder descobrir uma forma de continuar fazendo o envio de um arquivo XML de terceiros pelo ACBr. Agradeço antecipadamente pela atenção de todos.

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.

Pessoal, apenas para dar um norte para quem puder ajudar: O XML é totalmente gerado por nossa aplicação e a partir disso, entra o componente ACBr para assinar o XML, fazer o envio ao eSocial e tratar o retorno através da consulta do protocolo.

Olá, bom dia à todos! Estou usando o novo instalador Trunk2 da ACBr e estou precisando assinar digitalmente um arquivo XML de terceiros. Antes, utilizávamos uma versão da ACBr aonde bastava executar o método ACBreSocial.SSL.Assinar. Contudo, depois da atualização, não é mais possível assinar o XML pois o ACBr retorna um erro dizendo que não foi possível localizar o nó da assinatura. Aonde consigo encontrar um manual ou dica de como "migrar" o formato de assinar para a nova versão do ACBr? Ou se alguém tem alguma dica útil que possa salvar meu dia, já agradeço antecipadamente. Valeu pela atenção de todos!