BLV Técnico Versão 5.04 (Continuação)
Customização de férias e período aquisitivo de férias
Visão do usuário:
Foi criado um entry point que permite alterar os dados utilizados para obter os parâmetros de contagem: tipo de vínculo, regime jurídico, categoria, subcategoria.
No cadastro de férias os parâmetros de contagem serão obtidos na data final do período aquisitivo de férias.
Detalhes Técnicos:
Foi criado um entry point que permite alterar os dados utilizados para obter os parâmetros de contagem: tipo de vínculo, regime jurídico, categoria, subcategoria. Para alterar esses dados, será criado o entry point EP__GET_PARAM_FUNC em C_Ergon. Se essa função retornar TRUE, então será utilizado o código normal do produto, e se for alterado o comportamento.
No cadastro de férias os parâmetros de contagem serão obtidos na data final do período aquisitivo de férias.
Dados pessoais de um classificado em concurso que é funcionário
Visão do usuário:
A partir de agora, ao tentar cadastrar os dados pessoais para um classificado em concurso, o sistema realizará uma busca de funcionários pelo CPF informado para o classificado. Se encontrar funcionários já cadastrados com este CPF, o sistema permitirá ao usuário escolher um destes funcionários ou, então, cadastrar um funcionário novo.
Com relação ao ingresso do classificado, não mais será permitido que a tela de ingresso seja aberta para um classificado já ingressado.
Transação Ocorrências de Freq/Func - ERG0101
Visão do usuário:
Esta transação passa a aceitar todos os códigos de frequência do tipo normal. Passam a ser pesquisados também: licenças/afastamentos, férias e licenças especiais.
Detalhes Técnicos:
O form ERG0101 foi alterado para incluir pesquisa nas tabelas LIC_AFAST, FERIAS e LIC_ESP
Cadastro de pensionista a partir do dependente
Visão do usuário:
A transação de cadastro de pensionistas (Histórico Funcional / Pensões Especiais / Dados Pessoais) passa a permitir o cadastro de pensionistas a partir dos dados dos dependentes, caso o pensionista esteja também cadastrado como dependente do funcionário. Para isso, no campo "Dep" deve ser informado o número do dependente. Neste caso os dados comuns serão copiados do cadastro do dependente para o cadastro do pensionista. A partir daí os dados copiados ficam disponíveis para livre alteração.
A transação de histórico de pensionistas (Histórico Funcional / Pensões Especiais / Histórico de Pensionistas) passa a exibir o campo "Dep". Esta transação passa a ter layout semelhante à transação de cadastro de pensionistas (com "tabs").
As 2 transações acima tiveram seus layouts de telas alterados para comportar os novos campos criados. Se houver edição de tela desta transação, ela deverá ser refeita.
Detalhes Técnicos:
A tabela PENSIONISTAS foi alterada e incluído o campo NUMDEP. Este campo passa a conter o número do dependente a partir do qual os dados do pensionista foram copiados. Foi criada uma foreing-key da tabela PENSIONISTAS (campos NUMFUNC e NUMDEP) para a tabela DEPENDENTES. Nesta tabela também foi criado um novo índice nos campos (NUMFUNC, NUMDEP).
A tabela ERG_HIST_PENS foi alterada e incluído os campos NUMDEP, REPRESENTANTE_LEGAL, NUM_REPR_LEGAL e FLEX_CAMPOS (do 6 ao 20).
O form ERG0179 (transação Histórico Funcional / Pensões Especiais / Dados pessoais) foi alterado. Neste form foi incluído o campo NUMDEP.
O form ERG0176 (transação Histórico Funcional / Pensões Especiais / Histórico de Pensionistas) foi alterado. Neste form foram incluídos os novos campos da tabela ERG_HIST_PENS.
Inclusão do botão GERAR MATRÍCULA no form de cadastro de funcionários ( ERG0074 )
Visão do usuário:
Foi incluído o botão GERAR MATRÍCULA para criar matrículas seguindo a regra abaixo.
A matrícula gerada será a concatenação do número funcional com o próximo número de vínculo disponível. Caso já exista a matrícula com o número funcional e o número do vínculo a função somará 1 ao número do vínculo até encontrar uma matrícula não cadastrada.
O cliente poderá customizar este procedimento em C_ERGON ( pack_cergon.ep__gera_matricula )..
Detalhes Técnicos:
Foi incluído o botão GERAR MATRÍCULA para criar matrículas seguindo a regra abaixo.
A matrícula gerada será a concatenação do número funcional com o próximo número de vínculo disponível. Caso já exista a matrícula com o número funcional e o número do vínculo a função somará 1 ao número do vínculo até encontrar uma matrícula não cadastrada.
O cliente poderá customizar este procedimento em C_ERGON ( pack_cergon.ep__gera_matricula )..
Em C_ERGON foi criada na PACK_CERGON a função EP_GERA_MATRICULA. Esta função será usada para customizar a geração da matrícula. Caso ela retorne qualquer valor diferente de null o código do produto não será executado.
Data limite para lançamento manual de atributos
Visão do usuário:
Foi criado o campo "Limite Lanç. Manual" na transação "Tipos de Atributo". Este campo é do tipo DATA e tem por objetivo armazenar a data máxima para lançamento manual de um determinado atributo.
Este campo somente poderá ser preenchido para atributos que aceitam lançamento manual (campo "Aceita Lançamento Manual" selecionado), sendo que o seu preenchimento é opcional para o atributo em questão. Se for preenchido, significa que o atributo só aceitará lançamento manual ATÉ a data informada. Senão, significa que o atributo aceitará lançamento manual independente da data.
Com isso, as transações "Atributos de Funcionários", "Cadastro de Funcionários para Atributo" e "Atributos de Dependentes" foram alteradas para validar o período de lançamento dos atributos com a data limite, impedindo que atributos sejam lançados em data posterior ao limite.
Detalhes Técnicos:
A tabela TIPO_VANTAGEM_ e a view TIPO_VANTAGEM foram alteradas para acrescentar o campo LIMITE_MANUAL (tipo DATE).
Com esta alteração, será necessário regerar as triggers T_BS_IUD_TIPO_VANTAGEM, T_B_IUD_TIPO_VANTAGEM e T_A_IUD_TIPO_VANTAGEM.
Inclusão de campos na transação Dependentes - ERG0068
Visão do usuário:
No bloco documentos foram incluídas as seguintes informações : UF e município do cartório e tipo de documento.
O campo tipo de documento possuí lista de valores em tabela geral item TIPO_DOC_CERT.
No bloco Histórico de Dependentes os flex_campos 03,04 e 05 foram alterados para monoregistro.
Devido a alteração no layout da transação a edição de tela será apagada, sendo assim o cliente deverá refazer a edição de tela.
Detalhes Técnicos:
No bloco documentos foram incluídas as seguintes informações : UF e município do cartório e tipo de documento.
O campo tipo de documento possuí lista de valores em tabela geral item TIPO_DOC_CERT.
No bloco Histórico de Dependentes os flex_campos 03,04 e 05 foram alterados para monoregistro.
Devido a alteração no layout da transação a edição de tela será apagada, sendo assim o cliente deverá refazer a edição de tela.
Inclusão de campos na transação Funcionário - ERG0074
Visão do usuário:
No bloco documentos foram incluídas as seguintes informações : UF e município do cartório e tipo de documento.
O campo tipo de documento possuí lista de valores em tabela geral item TIPO_DOC_CERT.
Devido a alteração no layout da transação a edição de tela será apagada, sendo assim o cliente deverá refazer a edição de tela.
Detalhes Técnicos:
No bloco documentos foram incluídas as seguintes informações : UF e município do cartório e tipo de documento.
O campo tipo de documento possuí lista de valores em tabela geral item TIPO_DOC_CERT.
Devido a alteração no layout da transação a edição de tela será apagada, sendo assim o cliente deverá refazer a edição de tela.
Criação de novo tipo de valor na transacão Tipos de Atributo
Visão do usuário:
Foi criado um novo item para o campo Tipo de Valor. O novo item chama-se Horas ( HH:MM ). Este campo deverá armazenar o valor em horas e minutos.
Detalhes Técnicos:
Foi criado um novo item para o campo Tipo de Valor. O novo item chama-se Horas ( HH:MM ). Este campo deverá armazenar o valor em horas e minutos.
No banco de dados o valor será armazenado em minutos. Apenas a apresentação na tela será em HORAS:MINUTOS.
O tipo deverá ser parametrizado como INTEIRO.
Correções (Bugs)
Herança da classe de propriedades BLOCK_DML_VIEWS para as telas baseadas e Visões que aceitam DML.
Visão do usuário:
O Forms6i possui um "bug" para telas baseadas em Visões que aceitam DML. Para funcionarem adequadamente no grupo de propriedades DATABASE, a propriedade Key Mode deve ter o valor UPDATEABLE e a propriedade Enforce Primary Key de estar com Yes. E deve-se escolher as colunas que serão chave primária do bloco. Para centralizar essas mudanças, foi criada a property class BLOCK_DML_VIEW. Após atribuir ao bloco a herança dessa classe de propriedade, definir quais colunas serão as primary keys do bloco.
Essa classe de propriedades foi colocada no object group OG_MODOS_FORM da CLASSES.OLB.
Para corrigir o problema, as telas foram abertas, feito o procedimento descrito acima e re-compiladas as telas.
Detalhes Técnicos:
O Forms6i possui um "bug" para telas baseadas em Visões que aceitam DML. Para funcionarem adequadamente no grupo de propriedades DATABASE, a propriedade Key Mode deve ter o valor UPDATEABLE e a propriedade Enforce Primary Key de estar com Yes. E deve-se escolher as colunas que serão chave primária do bloco. Para centralizar essas mudanças, foi criada a property class BLOCK_DML_VIEW. Essa classe de propriedades deve ser herdada pelos blocos baseados em VIEWS que permitem operações DML. As propriedades que deverão ser herdadas são as seguintes:
ENFORCE PRIMARY KEY = YES
KEY MODE = UPDATEABLE
Após atribuir ao bloco a herança dessa classe de propriedade, definir quais colunas serão as primary keys do bloco.
Essa classe de propriedades foi colocada no object group OG_MODOS_FORM da CLASSES.OLB.
Para corrigir o problema, as telas foram abertas, feito o procedimento descrito acima e re-compiladas as telas.
Correções na geração da RAIS para vínculos encadeados.
Visão do usuário:
O procedimento de geração da RAIS foi alterado para fazer o tratamento de vínculos encadeados, ou seja, quando um funcionário possuir vínculos nessa situação, na RAIS, apenas o último deverá ser informado com a data de admissão (exercício) do primeiro vínculo da seqüência e a data de desligamento (aposentadoria ou vacância) do último. Outras informação são mescladas entre o primeiro e o último vínculo. Resumindo, teremos um único vínculo com o número do último e com o início e fim englobando todos os vínculos da seqüência.
Esse tratamento é feito por sub-empresa. Por isso nem todos os vínculos encadeados irão forma o único vínculo e sim apenas os vínculos em atividade na sub-empresa no dentro do ano base de geração da RAIS. Se uma parte da seqüência dos vínculos encadeados estiverem em sub-empresas diferentes, será criado um único vínculo para cada uma.
No caso de vínculos não encadeados, todos aparecerão na RAIS. Se ocorrer de mais de um vínculo possuir a mesma data de exercício, a data de admissão será atualizada para um dia a mais ou a menos dentro do ano base da RAIS.
Detalhes Técnicos:
O procedimento PRC_GERA_VALORES da PACK_RAIS foi alterado para fazer o tratamento de vínculos encadeados, ou seja, quando um funcionário possuir vínculos nessa situação, na RAIS, apenas o último deverá ser informado com a data de admissão (exercício) do primeiro vínculo da seqüência e a data de desligamento (aposentadoria ou vacância) do último. Outras informação são mescladas entre o primeiro e o último vínculo e as remunerações de todos os vínculos são adicionadas ao último vínculo. Resumindo, teremos um único vínculo com o número do último e com o início e fim englobando todos os vínculos da seqüência.
Esse tratamento é feito por sub-empresa. Por isso nem todos os vínculos encadeados irão forma o único vínculo e sim apenas os vínculos em atividade na sub-empresa no dentro do ano base de geração da RAIS. Se uma parte da seqüência dos vínculos encadeados estiverem em sub-empresas diferentes, será criado um único vínculo para cada uma.
No caso de vínculos não encadeados, todos aparecerão na RAIS. Se ocorrer de mais de um vínculo possuir a mesma data de exercício, a data de admissão será atualizada para um dia a mais ou a menos dentro do ano base da RAIS.
A tabela RAIS_INFO também foi alterada, com a adição das colunas DATA_ADMISSAO e DATA_DESLIGAMENTO, para gravar a data de admissão e desligamento do vínculo funcional. A data de admissão é o valor da data de exercício do vínculos e a data de desligamento é, na ordem, a data de aposentadoria ou a data de vacância. Mesmo que o funcionário possua aposentadoria/vacância, mas estão no ano posterior ao ano base da geração da RAIS, a data de desligamento estará em aberto.
Para tratar os vínculos encadeados, foi criada o sub-procedimento VERIFICA_VINCULO_ENCADEADO do PRC_GERA_VALORES. Essa rotina é chamada após a geração das informações da RAIS, tratando todos os vínculos que possuam um numero de vínculos anterior (NUMVINCANT) ou um número de vínculo posterior. Para ordenar a seqüência dos vínculos encadeados, determinando o primeiro ao último da cadeia é utilizada a sub-função PROCESSA_TABELA_VINCULOS. Ela também define o primeiro e último vínculo da cadeia por sub-empresa. Um vínculo encadeado que troca de sub-empresa, mesmo que não seja o primeiro da seqüência, na sub-empresa é considerado como o primeiro. Feita a ordenação, o sub-procedimento ATUALIZA_VINCULOS_ENCADEADOS faz a atualização da tabela RAIS_INFO, alterando o último vínculo da seqüência com a data de exercício do primeiro e mais algumas outras informações. Após a alteração, os outros vínculos são removidos da RAIS.
Também foi adicionado o sub-procedimento ALTERA_DATA_ADMISSAO do PRC_GERA_VALORES. Essa rotina é chamada após a VERIFICA_VINCULO_ENCADEADO e quando ocorrer de mais de um vínculo possuir a mesma data de exercício, a data de admissão da RAIS_INFO será atualizada para um dia a mais ou a menos dentro do ano base da RAIS.