wsenviarloteseventos Rotina para enviar lotes de eventos para o eSocial

[asamos]

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

 

[Juliomar Marchetti]

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.

[asamos]

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.

 

 

[Juliomar Marchetti]

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

[fabibona]

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

[Alisson Souza Pereira]

 

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.

[fabibona]

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

[EdmarFrazao]

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,

[arce]

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

[EdmarFrazao]

como esta fazendo para pegar no retorno o ID que foi enviado e separar os eventos.

No Retorno tem o ID, e os dados cod_retorno , msg etc.

 

Como vc esta achando qual ID pertence o registro.

[Alisson Souza Pereira]

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. 

[arce]

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

[fabibona]

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

 

[arce]

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.

Editado 26 Janeiro, 2018 por arce

[LUIZTEC]

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.

 

 

[fabibona]

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.

[LUIZTEC]

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

[fabibona]

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.

[Luiz Neto]

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.