Jump to content

Assista click.png tectoy.png

C6 chamada_c6.png botao.png

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


Digibyte
  • Este tópico foi criado há 1755 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Recommended Posts

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

* 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


 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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?

 

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • Este tópico foi criado há 1755 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • 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.