Trocar conhecimento sobre programação e regras de negócio para eSocial, pode ser aqui?

[Rodrigo - Digibyte]

Gostaria de compartilhar algumas idéias sobre como preparar nossos aplicativos para o eSocial, poderia ser por aqui ? O que acham?

[Curitiba Computer Ltda]

boa Rodrigo, to a sofrencia ta grande rsrs...

[jeancantu]

Podemos compartilhar sim conhecimentos, acho que todos estão passando pelos mesmos problemas...

[hnq_campos]

O Pessoal nem fale o Sofrencia hahahahaha

[Rodrigo - Digibyte]

Bom, estou realmente pegando firme agora a questão do eSocial. Estava analisando por exemplo como trabalhar com a tabela de eventos=proventos/descontos (mas a lógica pode servir para outras) e suas alterações/inclusões/exclusões que tem que ser informadas. Pensei o seguinte:

Exclusão de evento: não informar, que fique lá na base do esocial...

Inclusão: setar um campo "novo evento" e "data inclusão". Antes de enviar a folha dar um aviso, ou fazer automático, e enviar a inclusão. Recebendo um retorno positivo resetar o campo "novo evento"

Alteração: setar um campo "evento alterado" e "data alteração" e seguir a lógica da inclusão. Se o usuário alterar o evento e depois alterar novamente, voltando ao que era, a princípio não tenho como saber, vai ser enviada a alteração de qualquer forma.

O que acham, pensam da mesma forma?

[hnq_campos]

E tera que manter backup em tudo ne

 

[Rodrigo - Digibyte]

15 horas atrás, hnq_campos disse:

E tera que manter backup em tudo ne

 

Por qual motivo ?

[hnq_campos]

Por isso motivo que você citou o cara faz uma alteração e depois volta o que estava antes ou seja a alteração pro eSocial "não existe" é isso pode complicar a hora de bater no servidor

[Rodrigo - Digibyte]

4 minutos atrás, hnq_campos disse:

Por isso motivo que você citou o cara faz uma alteração e depois volta o que estava antes ou seja a alteração pro eSocial "não existe" é isso pode complicar a hora de bater no servidor

Mas a idéia não é controlar isso não. Se o cliente marcou uma incidência e depois desmarcou mando o evento pro esocial mesmo assim com nova validade. Logicamente vai estar igual mas duvido que isso será validado.

[hnq_campos]

Hum seila 
Por isso mesmo acho que tera que ser controlado pelo nosso lado porque esperar do governo hahahahahaha

[Curitiba Computer Ltda]

Rodrigo, pensamos igual, criei em todas as tabelas um campo integer "enviado" onde 0=não 1=sim (igual sua colocação acima) e quando gero o xml, ao receber o retorno pretendo colocar como enviado. faço select apenas dos "enviado=0". acredito que sua logica esteja 100% de acordo, deixar os enviados por la no esocial, nós somente não faremos mais referencias a itens excluídos, consequentemente, menor geração de xmls.

outra coisa que fiz que inclusive agilizou muito na hora da exclusao de qualquer cadastro, foi criar um campo "ativo integer" onde ativo=1 e excluido=9, e passei a fazer os selects apenas de cadastro com "ativo = 1". se eu precisar de recuperar algum excluido por "engano" do usuario, volto a condicao de ativo=1. e para o esocial, como voce ja propos, deixa quieto, posso utilizar o cadastro novamente porque nao exclui ele do esocial.

[Curitiba Computer Ltda]

aproveitando o topico, alguém ja passou pela geracao dos arquivos com o componente do esocial do branches? estou tendo algumas inconsistencias e alguns itens adicionados faltantes...

[Joceandro Perin]

1 hora atrás, Julio C J Rodrigues disse:

aproveitando o topico, alguém ja passou pela geracao dos arquivos com o componente do esocial do branches? estou tendo algumas inconsistencias e alguns itens adicionados faltantes...

Boa tarde,

Eu passei e gerei os eventos iniciais e de tabelas com dados reais, algumas coisas que eu encontrei eu ajustei e estão no svn..

O @GuilhermeCosta estava verificando as alterações que tiveram no layout 2.3..

Se quiser passar o que achou de inconsistência, ou quiser ajustar, vamos alinhando..

[GuilhermeCosta]

@Joceandro Perin, eu não tenho o levantamento de tudo que falta dos eventos não periódicos, já faz alguns dias que não consigo mexer no componente... Das ultimas vezes que alterei, eu apenas gerava os arquivos com o demo do Acbr, ai caso não validasse, ai sim eu passo um pente fino para ver o que esta diferente com o leiaute. Realmente, as ultimas alterações que realizei com a geração dos eventos não periódicos eu já postei aqui no forum...

Abraços...

[Curitiba Computer Ltda]

* S2200 a opção CadIni  ainda não está implementada.

* S2200 EvtAdmissao.Vinculo.InfoContrato.AlvaraJudicial não passa sem informações.

* S2200  EvtAdmissao.Vinculo.Desligamento.DtDeslig:= now;

* S2200 -     EvtAdmissao.Vinculo.Desligamento.DtDeslig nao passa sem informações.

* S1030 - evtTabCargo.infoCargo.DadosCargo.cargoPublico.leiCargo não passa sem informações.

* S1200 tipo de tributação - nao foi implementado para todas as quatro opções, irrf, contribuições sociais, fgts e contribuição sindical, sómente contrib. social e .irrf.

* idem para S1202 as opções de tipo de tributação.

foram alguns que não passaram, ainda to embrião rs, mas se eu detectar mais algum pra frente, vou relatando.

[]s

 

[Joceandro Perin]

Agora, GuilhermeCosta disse:

@Joceandro Perin, eu não tenho o levantamento de tudo que falta dos eventos não periódicos, já faz alguns dias que não consigo mexer no componente... Das ultimas vezes que alterei, eu apenas gerava os arquivos com o demo do Acbr, ai caso não validasse, ai sim eu passo um pente fino para ver o que esta diferente com o leiaute. Realmente, as ultimas alterações que realizei com a geração dos eventos não periódicos eu já postei aqui no forum...

Abraços...

Ahh, tranquilo.. Achei que estivesse vendo alguma coisa ainda.. Eu passei nos eventos iniciais conferindo com o layout 2.3 e a principio esta tudo certinho, agora vou começar nos periódicos e na sequência nos não periódicos.. Se eu achar alguma coisa de diferente, vou ajustando e avisando vocês..

[GuilhermeCosta]

22 horas atrás, Digibyte disse:

Bom, estou realmente pegando firme agora a questão do eSocial. Estava analisando por exemplo como trabalhar com a tabela de eventos=proventos/descontos (mas a lógica pode servir para outras) e suas alterações/inclusões/exclusões que tem que ser informadas. Pensei o seguinte:

Exclusão de evento: não informar, que fique lá na base do esocial...

Inclusão: setar um campo "novo evento" e "data inclusão". Antes de enviar a folha dar um aviso, ou fazer automático, e enviar a inclusão. Recebendo um retorno positivo resetar o campo "novo evento"

Alteração: setar um campo "evento alterado" e "data alteração" e seguir a lógica da inclusão. Se o usuário alterar o evento e depois alterar novamente, voltando ao que era, a princípio não tenho como saber, vai ser enviada a alteração de qualquer forma.

O que acham, pensam da mesma forma?

Lembrando que para os eventos de tabelas, você tem 2 tipos de alteração. A alteração simples, ela se comporta como uma retificação, você informa a chave (no caso da tabela de rubrica você deverá informar "codRubr, ideTabRubr, iniValid, fimValid") para identificar qual  evento você estará retificando. Você retificaria um evento, no caso de te-lo enviado com as incidências erradas por exemplos. Mas digamos que você tenho enviado o evento de forma correta, porém, a partir de uma determinada data, este evento em questão passou a ter um incidência que antes não tinha (seja por uma convenção coletiva ou uma portaria do MTE), neste caso, se o seu sistema utilizar a mesma rubrica, você deverá enviar dois eventos, um de alteração, indicando a data fim para aquele evento, e um de inclusão, informando as novas incidências... Talvez por isso o amigo @hnq_campos mencionou o fato de ter que armazenar tudo. E realmente, gerenciar tudo isso, é um problemao...

[Curitiba Computer Ltda]

aproveitando do conhecimento dos colegas, o exemplo do esocial diz
  ACBreSocial1.Eventos.GerarXMLs;
  ACBreSocial1.Eventos.SaveToFiles;
  ACBreSocial1.Eventos.Clear;
- como procedo para executar o comando acbersocial1.enviar ??
estou maluquinho para ver o circo pegar fogo rsrs, mas não idealizei a forma de enviar>>>
sao gerados tantos xmls quantos cadastros por exemplo, e tambem é gerado um evento especifico para o evento mas nao idealizei ainda a forma de envio.  algum colega pode me auxiliar por exemplo
tenho o evento EvtPgtos.xml e o S-1210-0.xml do evento 1210.
como fazer o envio desse evento?

 

[Rodrigo - Digibyte]

1 hora atrás, GuilhermeCosta disse:

...neste caso, se o seu sistema utilizar a mesma rubrica, você deverá enviar dois eventos, um de alteração, indicando a data fim para aquele evento, e um de inclusão, informando as novas incidências... Talvez por isso o amigo @hnq_campos mencionou o fato de ter que armazenar tudo. E realmente, gerenciar tudo isso, é um problemao...

Pelo que entendi da página 6 do MOS 2.2 não é necessário enviar o fim da validade, isso facilita muito. O fim de validade será considerado automaticamente o movimento anterior ao início enviado. Seria apenas um envio.

[GuilhermeCosta]

27 minutos atrás, Digibyte disse:

Pelo que entendi da página 6 do MOS 2.2 não é necessário enviar o fim da validade, isso facilita muito. O fim de validade será considerado automaticamente o movimento anterior ao início enviado. Seria apenas um envio.

Tem razão, realmente não é necessário enviar dois eventos, porém o armazenamento (pelo menos das chaves) ainda se faz necessário para o caso de uma futura retificação.