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.

Relatório de provisão de 13° salário

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

 

Relatório de provisão de 13° salário

Roteiro do Processo

Relatório de provisão de 13° salário

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:

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.

1

João da Silva

1200,00

0,00

0,00

X

?

8

0

DD/MM/AAAA

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

Parâmetros Adicionais da Empresa

Integração

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

Contabiliza por Centro de Custo considerando o Cadastro de Funcionários e Sócios

Contabiliza por Centro de Custo considerando o Cadastro de Obras

Utiliza conta contábil diferente para cada centro de custo

Utiliza Rateio por Centro de Custo na Folha de Pagamento

 

Documentação de Branches

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

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.

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

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:

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.

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.