Skip to main content

Branch eSocial (Leiaute S-1.0 e eventos SST)

Introdução

No branch em questão, serão feitas as alterações referentes ao leiaute simplificado do eSocial (1.0) e as implementações referentes aos eventos de segurança e saúde do trabalho. 

Tipos de alterações

Roteiro de alterações

N notação SXXXX, o XXXX corresponde ao número do evento (por exemplo: S1200, possui XXXX = 1200).

Inclusão de Grupo

Caso ocorrência do grupo tenha a possibilidade de ser maior do que um, deve-se criar um record com os campos do grupo e na classe do evento, adicionar um TList<RecordCriado> para o preenchimento das informações. Na unit PreencheSXXXX e GeraSXXXX, existirá um laço de repetição responsável por percorrer as informações destes campos, hora para atribuição ao objeto, hora para geração do XML.
Caso contrário, pode-se adicionar os campos diretamente à classe do evento (ou ao grupo pertencente, caso exista). Na unit PreencheSXXXX e GeraSXXXX, não existirá loop, apenas validações (caso necessário) para que a informação seja atribuída ou escrita no XML de forma direta.

Na geração do XML, é necessário adicionar as tags de abertura e fechamento do grupo. Para maiores detalhes, verifique campos já implementados ou tire suas dúvidas com outro desenvolvedor.

Inclusão de campo

Deve-se verificar em qual grupo o campo será adicionado ou se será em um grupo novo. Caso seja um novo grupo, seguir o procedimento de "inclusão de grupo".

Verificar se há necessidade de criação de campos em telas existentes e se necessita de utilização das rotinas de preenchimento obrigatório e/ou demais validações.

  • Incluir o campo na classe do evento (ou do grupo pertencente, caso o mesmo já exista): atributo na classe, property, get e set (eSocial.SXXXX.Classe.Pas);
  • Incluir preenchimento ao atributo criado (PreencheSXXXX.pas);
  • Incluir o campo criado para que seja escrito e exportado no XML, porém necessita atualização do componente do e-Social com o mapeamento dos campos (GeraSXXXX.pas);

Verificar com a equipe da qualidade, caso surja necessidade de criação destes campos em novas telas, onde e como devem ser criados e suas respectivas validações, sobre os novos layout e adequações. 

Inclusão ou remoção de valores possíveis

Normalmente, quando existem campos com um universo limitado de valores possíveis, existem arrays declarados na unit (eSocial_Conversao) que são utilizados para atribuição dos atributos do evento no preenchimento e convertidos em string no momento da geração do XML. Alterações desse tipo envolvem alterações nos arrays de declaração dos itens e nos arrays utilizados para a conversão do indíce do item para uma string.

Para situações onde não existam arrays já definidos, discuta com os outros desenvolvedores a melhor estratégia à ser seguida.

Exclusão de campo
  • Remover o campo da classe (eSocial.SXXXX.Classe.Pas);
  • Remover a atribuição feita na unit responsável por preencher o objeto do evento (PreencheSXXXX.pas);
  • Remover a escrita no XML a partir do objeto criado na unit (GeraSXXXX.pas);

Verificar tratamentos relacionados aos campos removidos do eSocial (Por exemplo, utilização da rotina: TeSocialFuncoes.AdvertePreenchimentoDoCampo ou validações na hora de salvar os cadastros relacionados).

Antes de remover validações e obrigatoriedades de preenchimento, confirme com a equipe da qualidade.

Exclusão de grupo

Quando houver exclusão de grupos, deve-se realizar o procedimento de exclusão de campos para todos os campos do grupo que será excluído. 

Além disso, na geração do XML do evento (GeraSXXXX.pas), as tags de abertura e fechamento do grupo devem ser excluídas.

Alteração de ocorrência

Há dois tipos principais de alteração, tratando-se de ocorrência. A alteração de 1 para N ocorrências ou o contrário, de N ocorrências para 1 ocorrência.
Em situações onde a ocorrência é alterada de 1 para N e o dado relativo ao campo se encontra em um cadastro, essa informação passará a compor um grid, sendo que possivelmente será necessária a criação de uma tabela para realizar a intermediação das informações. Caso essa informação não esteja incluída em um cadastro e já possua seu próprio cadastro, então provavelmente as alterações ocorrerão apenas na classe, preenchimento e geração do XML no respectivo evento (as alterações serão detalhadas logo abaixo).
Em situação onde a ocorrência é alterada de N para 1, e o dado relativo ao campo se encontra em um cadastro, provavelmente essa informação estará sendo relacionada à um grid. Este grid deverá ser removido (junto com os demais componentes relacionados: botão de adicionar, botão de remover, TFDQueries, DataSources, etc) e devem ser adicionados somente os campos para a inclusão de um registro do tipo. (Neste caso, geralmente uma tabela intermediária deixará de ser utilizada)

Nas units relacionadas ao eSocial, as seguintes alterações:

  • Na unit eSocial.SXXXX.Classe.Pas, caso o campo ou grupo tenham N ocorrências, o atributo da classe deve ser um TList<RecordCriado>, caso contrário será um atributo simples.
  • Na unit PreencheSXXXX.pas, caso o campo ou grupo tenham N ocorrências, existirá um loop responsável por percorrer os registros e realizar o preenchimento do objeto do evento. Caso contrário, existirá apenas validações (caso necessário) para o preenchimento do campo diretamente.
  • Na unit GeraSXXXX.pas, caso o campo ou grupo tenham N ocorrências, existirá um loop responsável por percorrer os itens do objeto e realizar a escrita no XML (Verifique se há necessidade escrever tags de inclusão e fechamento de grupos adicionais à cada iteração do loop ou apenas antes da iteração e no final do loop). Caso contrário, existirá apenas validações (caso necessário) para a escrita da informação no XML.
Alteração de condição

Alterações de condições são alterações que indicam sob quais condições, determinado campo será levado ou não para o eSocial, e são muito comuns em atualizações de leiaute. Cabe ao desenvolvedor analisar e discutir com os demais desenvolvedores quais estratégias devem ser seguidas em cada tipo de alteração de condição. Algumas vezes, essas alterações podem ser feitas diretamente no cadastro da informação, em outras, no preenchimento do objeto do evento.

Alteração de tamanho, descrição e/ou validação de campo

Em alterações desse tipo, é natural que as implementações sejam simples e pontuais. Exigindo maior atenção apenas alterações em validações de campos, onde cabe ao desenvolvedor interpretar as validações feitas atualmente para as validações que serão feitas na nova versão.

  • Incluir a validação na hora do preenchimento do objeto ou na hora do cadastro da informação do sistema  (preferencialmente) (PreencheSXXXX.pas);
  • No momento de gerar o XML, geralmente a validação feita é "Existe informação?" se sim, leva para o campo, se não, o campo não deve ser gerado (à menos em situações onde o campo deve ser gerado sem preenchimento). (GeraSXXXX.pas)

Verificar com a equipe de qualidade qual o melhor tratamento para as validações, por exemplo, deve-se apenas informar que pode gerar inconsistência e permitir a gravação ou não permitir salvar sem estar correto.

Verificar alterações feitas, se não irão impactar em campos de outros eventos, como rotinas comuns entre eles, por exemplo, a rotina GetNumeroInscr.

Alteração de grupo pai

Em alterações onde o grupo pai de um grupo ou elemento é alterado, deve-se alterar a classe do evento para a correta hierarquia dos atributos e também a unit de preenchimento e geração do respectivo evento, para que a informação seja corretamente preenchida e gerada no XML dentro do grupo correto.

No Comments
Back to top