Jump to content

Delphi chamada_delphi.png acbr.png

C6 chamada_c6.png botao.png

Rotina para enviar lotes de eventos para o eSocial


asamos
Go to solution Solved by LUIZTEC,
  • Este tópico foi criado há 1360 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Recommended Posts

Olá

Nos fontes do pacote eSocial-master2  encontrei um projeto inicial sobre o envio de lotes para o Webservice do e Social. Alguém poderia me informar se foi feito algum exemplo de envio para o eSocial  dentro do projeto ACBreSocial ?  Quem poderia me ajudar a faze-lo ?

Agradeço a ajuda.

Aristarco

 

Link to comment
Share on other sites

  • Consultores
59 minutos atrás, Aristarco Ribeiro disse:

Olá

Nos fontes do pacote eSocial-master2  encontrei um projeto inicial sobre o envio de lotes para o Webservice do e Social. Alguém poderia me informar se foi feito algum exemplo de envio para o eSocial  dentro do projeto ACBreSocial ?  Quem poderia me ajudar a faze-lo ?

Agradeço a ajuda.

Aristarco

 

olha na pasta de exemplos que tem lá o que está sendo subido.

Consultor SAC ACBr Juliomar Marchetti
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

skype: juliomar
telegram: juliomar
e-mail: [email protected]
http://www.juliomarmarchetti.com.br
MVP_NewLogo_100x100_Black-02.png
Projeto ACBr - A maior comunidade Open Source de Automação Comercial do Brasil

 

Link to comment
Share on other sites

  • Consultores
12 horas atrás, Aristarco Ribeiro disse:

Olá Juliomar

você poderia passar o link completo ? a rotina que eu encontrei é de jul/2017 e o projeto não está completo.

Agradeço a sua ajuda.

 

 

acho que tu não atualizou o svn e olhou.

está no trunk2 já foi subido semana passada e essa semana já foram feito outros commits

Consultor SAC ACBr Juliomar Marchetti
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

skype: juliomar
telegram: juliomar
e-mail: [email protected]
http://www.juliomarmarchetti.com.br
MVP_NewLogo_100x100_Black-02.png
Projeto ACBr - A maior comunidade Open Source de Automação Comercial do Brasil

 

Link to comment
Share on other sites

57 minutos atrás, Juliomar Marchetti disse:

acho que tu não atualizou o svn e olhou.

está no trunk2 já foi subido semana passada e essa semana já foram feito outros commits

Bom dia Juliomar, tudo bem ?

No envio do lote do eSocial terá uma forma automática de enviar 50 eventos por vez automaticamente, ou seja, vamos dizer que no evento de funcionarios S-2200 tem um montante de 1000 funcionários, seria um total de 20 lotes de 50 eventos, vou ter que fazer isso manualmente em meu programa, ou nos exemplos tem como enviar automaticamente esses 20 lotes e gerar somente um protocolo ?.

Link to comment
Share on other sites

 

18 minutos atrás, fabibona disse:

Bom dia Juliomar, tudo bem ?

No envio do lote do eSocial terá uma forma automática de enviar 50 eventos por vez automaticamente, ou seja, vamos dizer que no evento de funcionarios S-2200 tem um montante de 1000 funcionários, seria um total de 20 lotes de 50 eventos, vou ter que fazer isso manualmente em meu programa, ou nos exemplos tem como enviar automaticamente esses 20 lotes e gerar somente um protocolo ?.

No caso teria que ser um único lote com os 1000 registros, o eSocial é bem categórico nesta parte, poderão conter apenas 50 eventos por lote e cada protocolo serve para consultar um lote. 

Lembrando que o protocolo é gerado pelo eSocial. 

Então se o eSocial não mudar o seu processo, isso não irá acontecer.

Link to comment
Share on other sites

14 minutos atrás, Alisson Souza Pereira disse:

 

No caso teria que ser um único lote com os 1000 registros, o eSocial é bem categórico nesta parte, poderão conter apenas 50 eventos por lote e cada protocolo serve para consultar um lote. 

Lembrando que o protocolo é gerado pelo eSocial. 

Então se o eSocial não mudar o seu processo, isso não irá acontecer.

Isso mesmo, eu tentei enviar agora como produção restrita 490 funcionários, retorna o erro: Erro Interno: 0   -  Erro HTTP: 413

Mas se o eSocial não mudar isso a única maneira será enviar vários lote e com isso vários protocolos serão gerados, vai ser difícil isso, isso falando de funcionários e quando for enviar a folha de pagamento, levando em conta 1000 funcionários e uma média de 15 eventos para cada funcionário será um montante de 15.000 eventos, dividindo por 50 eventos por lote daria 300 envios / protocolo, não tem outro jeito ?.

Link to comment
Share on other sites

Também estou achando que devemos enviar lote a lote com arquivo a arquivo.

Por exemplo, Enviei 10 funcionários e 3 deram erros, o retorno so devolve o ID, ai para achar qual funcionário estava errado tem que pegar o ID, ver o arquivo de envio o ID para encontrar o que esta errado.

O eSocial aceitou 7 funcionários e 3 derram recusa. Porem para para retificar os 7 primeiros tem que o suar o NR_Recibo (1o que foi enviado), e os ouros funcionários terão outro NR_Recibo, dificil de controlar.

 

Se enviar arquivo a arquivo, teremos um NO_PROTOCOLO_ENVIO e NR_RECIBO_Consulta para cada arquivo xml enviado, se der erro ja sabemos qual é que esta com problema.

Para as retificações tem que usar NR_Recibo sempre.

O lote seria mais produtivo no envio sem erros, mas com erros não.

 

estou guardando em pasta por nome de PROTOCOLO todos os envios,

Link to comment
Share on other sites

45 minutos atrás, EdmarFrazao disse:

Também estou achando que devemos enviar lote a lote com arquivo a arquivo.

Por exemplo, Enviei 10 funcionários e 3 deram erros, o retorno so devolve o ID, ai para achar qual funcionário estava errado tem que pegar o ID, ver o arquivo de envio o ID para encontrar o que esta errado.

O eSocial aceitou 7 funcionários e 3 derram recusa. Porem para para retificar os 7 primeiros tem que o suar o NR_Recibo (1o que foi enviado), e os ouros funcionários terão outro NR_Recibo, dificil de controlar.

 

Se enviar arquivo a arquivo, teremos um NO_PROTOCOLO_ENVIO e NR_RECIBO_Consulta para cada arquivo xml enviado, se der erro ja sabemos qual é que esta com problema.

Para as retificações tem que usar NR_Recibo sempre.

O lote seria mais produtivo no envio sem erros, mas com erros não.

 

estou guardando em pasta por nome de PROTOCOLO todos os envios,

Estou fazendo da seguinte forma. Ex: Envio os 10 eventos em um lote, destes 3 retornaram com erro. Então separo os corretos e mantenho no mesmo lote, e os demais envio em um novo lote, para receber um novo número de protocolo.

Usei a mesma lógica da NFe, se vc envia 30 NFes em um único lote, e algumas possuem falhas, vc pode enviá-las em um novo lote. Não precisa repetir o mesmo

Link to comment
Share on other sites

13 horas atrás, Alisson Souza Pereira disse:

No momento que estou populando cada evento passo o ID que eu monto e na Unit de cada evento substituo ao invés de chamar a função gerar ID passo Self.ID, com isso você é quem controla o ID de cada evento. 

Estou fazendo o mesmo isso tbm

Link to comment
Share on other sites

Esse eSocial tem cada uma...

Enviei o evento S-1030 (Cargos), um total de 159 eventos, foi direto sem dar qualquer problema, gerou o protocolo corretamente, consultei o protocolo e estava tudo correto.

Fui enviar o evento S-2200 (Admissão), um total de 90 eventos, e retornou o erro que os eventos tem que estar em um total de 1..50, vai entender, alguns tipos de eventos transmite em sua totalidade e alguns não

Como mencionei acima uma empresa com mais de 1.000 funcionários vai ser difícil esta manutenção de protocolos e números de recibo.

Alguém tem alguma sugestão para diminuir esse sofrimento ?.

 

Link to comment
Share on other sites

38 minutos atrás, fabibona disse:

Esse eSocial tem cada uma...

Enviei o evento S-1030 (Cargos), um total de 159 eventos, foi direto sem dar qualquer problema, gerou o protocolo corretamente, consultei o protocolo e estava tudo correto.

Fui enviar o evento S-2200 (Admissão), um total de 90 eventos, e retornou o erro que os eventos tem que estar em um total de 1..50, vai entender, alguns tipos de eventos transmite em sua totalidade e alguns não

Como mencionei acima uma empresa com mais de 1.000 funcionários vai ser difícil esta manutenção de protocolos e números de recibo.

Alguém tem alguma sugestão para diminuir esse sofrimento ?.

 

Um dos clientes aqui da empresa tem 3500 funcionários fixos. O sistema precisa ter uma lógica onde os lotes sejam transmitidos na sequencia correta, para evitar conflitos. Uma sugestão seria organizá-los por funcionário, assim tornaria o controle de erros menos complexo.

Edited by arce
Link to comment
Share on other sites

  • Solution
19 minutos atrás, fabibona disse:

Esse eSocial tem cada uma...

Enviei o evento S-1030 (Cargos), um total de 159 eventos, foi direto sem dar qualquer problema, gerou o protocolo corretamente, consultei o protocolo e estava tudo correto.

Fui enviar o evento S-2200 (Admissão), um total de 90 eventos, e retornou o erro que os eventos tem que estar em um total de 1..50, vai entender, alguns tipos de eventos transmite em sua totalidade e alguns não

Como mencionei acima uma empresa com mais de 1.000 funcionários vai ser difícil esta manutenção de protocolos e números de recibo.

Alguém tem alguma sugestão para diminuir esse sofrimento ?.

 

Bom dia.

Estou transmitindo e recebendo os arquivos do s1000 ao s2206 perfeitamente. Incorporei o projeto acbresocial ao sistema da empresa. Estou enviando os fontes alterados do acbr para quem quiser dar uma olhada. Repito, funcionando 100% tanto com A1 como com A3, já com as alterações da versao 2.4.01.

O que eu faço é o seguinte:

1 - configuracao

VESocial.Configuracoes.Geral.SSLLib        := libOpenSSL;  
VESocial.Configuracoes.Geral.SSLHttpLib    := httpWinHttp;
VESocial.Configuracoes.Geral.SSLCryptLib   := cryWinCrypt; 
VESocial.Configuracoes.Geral.SSLXmlSignLib := xsXmlSec;    

 

2 - criei flags nas tabelas para saber se o registro é NOVO, ALTERADO, TRANSMITIDO. Exemplo no S1000 criei um campo GERA_S1000 que enquanto ficar nulo indica que existe um novo registro a ser transmitido ao esocial. Ao transmitir ele muda o status para transmitido e nao gero mais esse arquivo. Criei uma trigger em cada tabela que ao fazermos alguma alteracao em algum campo exigido no esocial e o flag do registro estiver como TRANSMITIDO, o mesmo muda de status de TRANSMITIDO para ALTERADO, ai sei que tenho um registro de alteracao para enviar ao esocial. Tudo automatico para o cliente. Se tenho 300 registros para enviar, ele envia 50, muda o status para TRANSMITIDO (somente muda se tiver retorno do número do recibo), então na hora que for gerar de novo meu select irá pegar sozinho os proximos 50, pois o select nao olha arquivos transmitidos.

3 - como preciso guardar tudo que foi enviado ao esocial, criei tabelas separadas com as informações dos arquivos gerados. Uma tabela espelho para cada arquivo. Exemplo: no S1000 tenho uma tabela com o numeroprotocolo, numerorecibo, id e os campos enviados ao esocial. Na hora que transmitir gravo esse registro pois já tenho o protocolo. Se por ventura não tiver retorno na hora, posso a qualquer hora consultar esse recibo, ai sim pego o número do recibo gravo e altero o flag para transmitido, ou seja, se enviar 50 funcionarios, 10 estão com erro, na transmissao gravo os 50 funcionarios com protocolo e id. No retorno, gravo os 40 recibos mudo o flag para TRANSMITIDO, e os 10 gravo as mensagens de erro para o cliente consultar o que houve de errado. Então esses 10 registros com erro continuam com o flag nulo, ou seja, continua aparecendo para o cliente que  precisa ser enviado ao esocial.

4 - Como os fontes são propriedade da empresa não posso dispor para vcs, mas tudo foi feito a partir do exemplo do Leivio.

Segue os fontes que alterei no esocial: (Trabalho com orgão público e privado então está alterado para transmitir os dois).

componente.rar

 

Espero ter ajudado. A disposição para qualquer dúvida.

 

 

  • Like 1
  • Thanks 2
Link to comment
Share on other sites

50 minutos atrás, arce disse:

Um dos clientes aqui da empresa tem 3500 funcionários fixos. O sistema precisa ter uma lógica onde os lotes sejam transmitidos na sequencia correta, para evitar conflitos. Uma sugestão seria organizá-los por funcionário, assim tornaria o controle de erros menos complexo.

Vou ter que fazer isso mesmo, vai ser melhor, não vai ter outro jeito, quem sabe até lá o governo muda esse esquema e passa aceitar um número infinito de eventos, pois em seu exemplo acima com 3500 funcionários, geralmente tem uma média de proventos e descontos de 15 registros por funcionário, multiplicando dá um total de 52.500 eventos / 50 = 1.050 lotes (Protocolo e Recibo), isso todo o mês.

Obrigado pela dica.

Link to comment
Share on other sites

Agora, fabibona disse:

Vou ter que fazer isso mesmo, vai ser melhor, não vai ter outro jeito, quem sabe até lá o governo muda esse esquema e passa aceitar um número infinito de eventos, pois em seu exemplo acima com 3500 funcionários, geralmente tem uma média de proventos e descontos de 15 registros por funcionário, multiplicando dá um total de 52.500 eventos / 50 = 1.050 lotes (Protocolo e Recibo), isso todo o mês.

Obrigado pela dica.

São 3500 funcionários então vão ser 3500 / 50=70 envios, pois cada funcionário conta como um evento, ou seja, mesmo que ele tenha 30 proventos e descontos, é um evento só.

Link to comment
Share on other sites

14 minutos atrás, LUIZTEC disse:

São 3500 funcionários então vão ser 3500 / 50=70 envios, pois cada funcionário conta como um evento, ou seja, mesmo que ele tenha 30 proventos e descontos, é um evento só.

É verdade eu me confundi, cada funcionário tem todos os registros de sua folha de pagamento em seu evento, obrigado.

1 hora atrás, LUIZTEC disse:

Bom dia.

Estou transmitindo e recebendo os arquivos do s1000 ao s2206 perfeitamente. Incorporei o projeto acbresocial ao sistema da empresa. Estou enviando os fontes alterados do acbr para quem quiser dar uma olhada. Repito, funcionando 100% tanto com A1 como com A3, já com as alterações da versao 2.4.01.

O que eu faço é o seguinte:

1 - configuracao

VESocial.Configuracoes.Geral.SSLLib        := libOpenSSL;  
VESocial.Configuracoes.Geral.SSLHttpLib    := httpWinHttp;
VESocial.Configuracoes.Geral.SSLCryptLib   := cryWinCrypt; 
VESocial.Configuracoes.Geral.SSLXmlSignLib := xsXmlSec;    

 

2 - criei flags nas tabelas para saber se o registro é NOVO, ALTERADO, TRANSMITIDO. Exemplo no S1000 criei um campo GERA_S1000 que enquanto ficar nulo indica que existe um novo registro a ser transmitido ao esocial. Ao transmitir ele muda o status para transmitido e nao gero mais esse arquivo. Criei uma trigger em cada tabela que ao fazermos alguma alteracao em algum campo exigido no esocial e o flag do registro estiver como TRANSMITIDO, o mesmo muda de status de TRANSMITIDO para ALTERADO, ai sei que tenho um registro de alteracao para enviar ao esocial. Tudo automatico para o cliente. Se tenho 300 registros para enviar, ele envia 50, muda o status para TRANSMITIDO (somente muda se tiver retorno do número do recibo), então na hora que for gerar de novo meu select irá pegar sozinho os proximos 50, pois o select nao olha arquivos transmitidos.

3 - como preciso guardar tudo que foi enviado ao esocial, criei tabelas separadas com as informações dos arquivos gerados. Uma tabela espelho para cada arquivo. Exemplo: no S1000 tenho uma tabela com o numeroprotocolo, numerorecibo, id e os campos enviados ao esocial. Na hora que transmitir gravo esse registro pois já tenho o protocolo. Se por ventura não tiver retorno na hora, posso a qualquer hora consultar esse recibo, ai sim pego o número do recibo gravo e altero o flag para transmitido, ou seja, se enviar 50 funcionarios, 10 estão com erro, na transmissao gravo os 50 funcionarios com protocolo e id. No retorno, gravo os 40 recibos mudo o flag para TRANSMITIDO, e os 10 gravo as mensagens de erro para o cliente consultar o que houve de errado. Então esses 10 registros com erro continuam com o flag nulo, ou seja, continua aparecendo para o cliente que  precisa ser enviado ao esocial.

4 - Como os fontes são propriedade da empresa não posso dispor para vcs, mas tudo foi feito a partir do exemplo do Leivio.

Segue os fontes que alterei no esocial: (Trabalho com orgão público e privado então está alterado para transmitir os dois).

componente.rar

 

Espero ter ajudado. A disposição para qualquer dúvida.

 

 

Vou fazer dessa forma que você mencionou, vai ser o melhor a fazer, muito obrigado pelas informações.

  • Like 1
Link to comment
Share on other sites

  • 7 months later...

Muito obrigado LuizTec, sua forma de transmitir é ótima e serviu como roteiro que eu tanto buscava dentro da ACBr, deveria ser um Topico no topo para a discussão de criação de um módulo de Mensageria do específica do eSocial dentro da ACBr.

  • Like 1
Link to comment
Share on other sites

  • Este tópico foi criado há 1360 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.
Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.