Questão: | A dúvidas é sobre o layout e comportamento do ambiente do eSocial em relação a validade dos eventos de tabela. Não sabemos se uma nova validade de tabela pode ser gerada a partir das tags novaValidade e também a partir de uma nova inclusão daquela tabela, conforme exemplos abaixo: Exemplo: Utilizando novaValidade: *Tipo de Evento: Quando inclusão, indica que serão geradas as tags de inclusão; quando alteração, indica que serão geradas as tags de alteração; quando exclusão, indica que serão geradas as tags de exclusão. No exemplo acima, o código 001 na base do Governo ficaria da seguinte maneira: Dúvida 1: As tags de novaValidade devem ser utilizadas somente para este fim? Para alterar a vigência de uma tabela? Exemplo: Utilizando nova inclusão da tabela: No exemplo acima, o código 001 na base do Governo ficaria da seguinte maneira:
Dúvida 2: Ao realizar a inclusão de uma nova tabela com mesmo código em período diferente, a tabela anterior deixa de ser ativa, ou seja, somente a última tabela incluída é ativa? Dúvida 3: Caso no exemplo acima somente uma permaneça ativa, no caso de excluir a última tabela enviada a partir de nova inclusão, a tabela anterior passa a ser ativa novamente? Ou deve ser enviada uma alteração com nova Validade para que ela passe de inativa à ativa? |
Resposta: | A administração do período de validade das informações é importante pois impacta diretamente os demais eventos que as utilizam, portanto deve ser observado o seu período de vigência.
Quando da primeira informação dos itens que compõem uma tabela, deve ser preenchido obrigatoriamente o campo data de início da validade {iniVali}. Caso haja necessidade de alterar informação especifica de uma tabela enviada anteriormente poderá fazê-lo enviando-se novo evento da tabela, com o item que deve ser alterado, informando a nova data de validade. Neste caso, a data fim de validade da informação prestada anteriormente passa a ser o mês/ano imediatamente anterior ao da data de início da nova informação.
Não é necessário o envio de evento especifico para informar a data fim de validade do item enviado anteriormente, no entanto o seu envio terá o mesmo efeito do procedimento anterior.
As informações constantes do Eventos de Tabelas são mantidas no eSocial de forma histórica, não sendo permitidas informações conflitantes para um mesmo item dentro da mesma Tabela e período de validade. Nesse sentido, todos os eventos de tabelas possuem 4 grupos de informações:
Exemplos: Inclusão Inicio Validade: 01/2017 Fim Validade _________ INSS Sim IRRF Sim
Se mudou a partir de 11/2017
Inclusão Inicio Validade 11/2017 Fim Validade _________ INSS Não IRRF Sim
Se a vigência não era 11/2017, mas 09/2017
Alteração Inicio Validade 11/2017 Fim Validade _________ INSS Não IRRF Sim Novo Inicio Validade 09/2017 Novo Fim Validade _______
Em resumo, sempre que quiser mudar algo a partir de uma validade diferente, sempre inclusão.
Alteração “é a retificação”, ou seja, corrigir algo já informado errado. Nesses caso, Inicio Validade e Fim Validade “são a chave”, são os valores já informados anteriormente. Novo Inicio e Novo Fim de Validade são os novos valores que passarão a ser “as novas chaves”.
Fim de validade é SEMPRE opcional. Nesse exemplo que coloquei acima o final de validade é subentendido. Isso é, o item com inicio validade 01/2017 perde sua validade em 10/2017, pois em 11/2017 já há uma nova entrada.
|
Chamado/Ticket: | 1614697. |
Fonte: | https://portal.esocial.gov.br/institucional/documentacao-tecnica |