# Módulo de Folha de Pagamento # Relatório de provisão de 13° salário Neste capítulo, se encontram as informações referentes ao relatório de provisão de 13° salário, desde a sua definição, parametrização e variáveis envolvidas. Este é um projeto piloto para documentação dos processos do sistema, por isso, seus documentos são considerados como documentos experimentais. # Definição do Processo ##### **Resumo do processo** O processo de geração do relatório de provisão de 13° salário, é um processo existente no sistema SSFolha, responsável por calcular e exibir, em forma de relatório, os valores de provisão de 13° salário para os funcionários. Do ponto de vista contábil, uma provisão é a consideração de um gasto tido como certo ou com grandes chances de ocorrência. Se tratando da provisão de 13° salário, uma vez que um colaborador trabalhou durante um período considerado como um avo, este colaborador já possui direito ao respectivo avo no pagamento do 13°. Embora o pagamento não ocorra no momento da completude do avo, ele vai ocorrer em algum momento posterior. O relatório de provisão tem o objetivo de exibir e detalhar estes valores para acompanhamento e verificação dos valores à serem provisionados. ##### **Envolvidos no processo** **Sistema:** SSFolha **Usuário:** Qualquer usuário com permissões para gerar relatórios de provisões ##### **Etapas do processo** - O Usuário deve navegar até a tela de provisões, através do menu:

Relatórios > Provisão > 13° Salário

- Definir os parâmetros para a geração do relatório (serão detalhados numa fase posterior do projeto). - Selecionar a forma de saída da provisão (impressão, visualização, geração do arquivo ou envio por e-mail) ##### **Ponto inicial do processo** Abertura da tela de provisão de 13°. ##### **Ponto final do processo** Conclusão do procedimento escolhido pelo usuário como saída da provisão. ##### **Resultado esperado** É esperado que, após o processamento das informações, o relatório de provisão de 13° detalhe as informações do colaborador e os respectivos valores de provisão para o mesmo, de forma que, ao gerar o 13° salário para o colaborador, os valores sejam os mesmos. # Roteiro do Processo # Caso de uso 1 - Mensal Simples Neste documento, vamos considerar Provisão de 13° Salário como uma coisa só, sendo que, de antemão, sabemos que uma provisão não necessariamente é de 13°. Então, ao avançar neste documento observaremos quais atributos fazem parte da classe “Provisão” e quais atributos fazem parte da extensão “13° Salário”. ##### **Processo como é hoje:** Nos modos **Mensal, Integral e Proporcional**, as seguintes informações estarão presentes: Código do funcionário, nome, salário, hora extra, comissão, valor acumulado, data de admissão, INSS recolhido do funcionário, INSS pago pela empresa, FGTS, IRRF. Selecionando o tipo “**Mensal**”, o relatório deve exibir as informações já citadas e o valor do 13° salário correspondente ao mês definido. (Valor referente ao avo do mês); Selecionando o tipo “**Integral**”, o relatório deve exibir as informações já citadas e o valor do 13° salário integral. Selecionando o tipo “**Proporcional**”, o relatório deve exibir as informações já citadas, a data de referência utilizada, o número de avos a que o funcionário tem direito e o valor acumulado do 13° salário até a data de referência. Selecionando o tipo “**Geral**”, o relatório deve exibir as seguintes informações: Código, Nome, Cargo/Função do Funcionário, Salário, período proporcional a que se refere o relatório, número de avos, valor acumulado do 13°, valor/mês do 13°, INSS acumulado, INSS/mês, FGTS acumulado e FGTS/mês. ##### **Como deve funcionar “por baixo” dos panos:** Para entender como a provisão deve funcionar, devemos levar em consideração alguns fatores importantes: - A data de admissão/rescisão do funcionário; - Afastamentos ou Férias; - O Tipo de salário do funcionário (mensal, diária, por hora, outro(?)); - Caso seja horista, - Parâmetro da empresa para cálculo do funcionário horista (dias do mês, sempre 30, ou média de horas trabalhadas); - Alterações salariais; - Faltas; ##### **Caso ideal:** Funcionário mensalista, admitido no ano anterior, sem desligamento, sem afastamento, sem férias no período, não comissionado, sem horas extras e sem alteração salarial no período. Código do Funcionário: 1 Nome: João da Silva Salário: R$1200,00 Hora Extra: R$0,00 Valor Acumulado: R$0,00 INSS: R$91,50 / 12 = R$7,625/mês INSS empresa: \* Varia de acordo com atividade exercida (eu acho) FGTS: Salário \* 0,08 = R$96,00 = R$8,00/mês IRRF: R$0,00. ##### **Mensal** Neste caso, o relatório deve exibir os seguintes valores, independente do mês gerado.

Cod	Nome	Salário	H. Extra	Valor Acum	INSS Func	INSS Empr	FGTS	IRRF	13° mês
1	João da Silva	1200,00	0,00	0,00	7,625	?	8,00	0,00	100,00

##### **Integral** Neste caso, o relatório deve exibir os seguintes valores:

Cod	Nome	Salário	H. Extra	Valor Acum	INSS Func	INSS Empr	FGTS	IRRF	13° sal.
1	João da Silva	1200,00	0,00	0,00	91,50	?	96,00	0,00	1200,00

##### **Proporcional** Neste caso, o relatório deve exibir os seguintes valores para os valores proporcionais ao mês **N**:

Cod

Nome

Salário

H. Extra

Valor Acum

INSS Func

INSS Empr

FGTS

IRRF

Dt. Admit

Dt. Ref

Avos

13° prop.

João da Silva

1200,00

0,00

**X**

DD/MM/AAAA

**N**

**Y**

Sendo que: X = (INSS ref mês 01) + (INSS ref mês 02) + .... + (INSS ref mês N); Y = (13° ref mês 01) + (13° ref mês 02) + ... + (13° ref mês N); ##### **Geral** No modo geral, pode-se considerar uma forma híbrida entre o tipo “Proporcional” de acordo com o mês de referência e o tipo “mensal” indicando os valores mensais do mês de referência.

Infos do Funcio	Período Prop.	Avos	Base 13°	13° Acum.	13° Mês	INSS Acum	INSS Mês	FGTS Acum	FGTS Mês
Abstraídas	01/01/AAAA - DD/MM/AAAA	N	1200,00	X	100,00	Y	7,625	Z	8,00

Sendo que: **N** = Mês selecionado; **X** = (13° ref mês 01) + (13° ref mês 02) + ... + (13° ref mês N); **Y** = (INSS ref mês 01) + (INSS ref mês 02) + .... + (INSS ref mês N); **Z** = (FGTS ref mês 01) + (FGTS ref mês 02) + .... + (FGTS ref mês N); # Parâmetros Adicionais da Empresa # Integração [![image-1618411500002.png](https://wiki.supersoft.com.br/uploads/images/gallery/2021-04/scaled-1680-/image-1618411500002.png)](https://wiki.supersoft.com.br/uploads/images/gallery/2021-04/image-1618411500002.png) *Versão 10.252* Para habilitar os parâmetros dessa tela deve-se considerar os seguintes critérios: #### Será Integrado a Contabilidade - Campo "IntegraLFLCX" desabilitado, - não tem Centro de Custo na tabela de Obras e - não tem CodEvento na tabela ContabFP #### Contabiliza por Centro de Custo considerando o Cadastro de Funcionários e Sócios - Campo IntegraContab habilitado, - campo CCusto na tabela ParamCb com o valor = S **OU** - não tem informação na tabela ParamCb **OU** - não tem CodEvento na tabela ContabFP #### Contabiliza por Centro de Custo considerando o Cadastro de Obras - Opção "Contabiliza por Centro de Custo considerando o Cadastro de Funcionários e Sócios" habilitado e marcado - Não tem Centro de Custo cadastrado na tabela Obras - Tipo de Empresa é "C" (Construção Civil) ou "L" (Locação Mão de Obra) #### Utiliza conta contábil diferente para cada centro de custo - Opção "Contabiliza por Centro de Custo considerando o Cadastro de Obras" habilitado e marcado - Tipo de Empresa é "C" (Construção Civil) ou "L" (Locação Mão de Obra) #### Utiliza Rateio por Centro de Custo na Folha de Pagamento - Opção "Contabiliza por Centro de Custo considerando o Cadastro de Funcionários e Sócios" habilitado # Documentação de Branches # 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** - [**Inclusão de grupo**](#bkmrk-inclus%E3%A3o-de-grupo) - [**Inclusão de campo**](#bkmrk-para-inclus%E3%A3o-de-camp) - [**Inclusão ou remoção de valores possíveis**](#bkmrk-inclus%E3%A3o-ou-remo%E3%A7%E3%A3o-d) - [**Exclusão de campo**](#bkmrk-para-exclus%E3%A3o-de-camp) - [**Exclusão de grupo**](#bkmrk-exclus%E3%A3o-de-grupos) - [**Alteração de ocorrência**](#bkmrk-altera%E3%A7%E3%A3o-de-ocorr%E3%AAnc) - [**Alteração de condição**](#bkmrk-altera%E3%A7%E3%A3o-de-condi%E3%A7%E3%A3) - [**Alteração de tamanho, descrição e/ou validação de campo**](#bkmrk-altera%E3%A7%E3%A3o-de-tamanho) - [**Alteração de grupo pai**](#bkmrk-%E2%A0-2) #### **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.