BLV Técnico Versão 5.02 (Continuação)
Criação da data de início do ingresso
Visão do usuário:
A data de nomeação era obrigatória durante o processo de ingresso de um funcionário. Entretanto, existem situações em que a data de nomeação não existe. Um exemplo disso é a contratação de um servidor através de um contrato temporário de trabalho. Neste caso, a data de nomeação não existirá. Apenas existirá a data de exercício.
Sendo assim, o processo de ingresso de um servidor passou a ter uma data de início, esta sim obrigatória. Com isso, ao ingressar um servidor, a data de início do ingresso receberá o valor da data de nomeação ou da data de exercício, dependendo de qual estiver sendo usada. O preenchimento deste campo é feito automaticamente pela transação "Ingresso". Esta transação não sofreu alteração aparente, apenas foi mudada para que ela faça o preenchimento automático da data de início. Isto, porém, não afeta em nada o modo de utilização da transação.
Obs.: A data de início do ingresso deve, portanto, ser OBRIGATORIAMENTE igual à data de nomeação ou à data de exercício.
Detalhes Técnicos:
A coluna DTNOM da tabela ERG_INGRESSO deixou de fazer parte da Unique Key da tabela e também deixou de ser NOT NULL. Foi criada uma nova coluna, chamada DTINI, que é NOT NULL e tomou o lugar de DTNOM na Unique Key de ERG_INGRESSO. Durante a execução dos scripts de aplicação destas alterações, é feito um processo de migração de dados, de modo a preencher a nova coluna DTINI, com os valores da coluna DTNOM. Após terminada esta migração, a Unique Key da tabela é alterada.
Como a coluna DTNOM desta tabela deixou de ser NOT NULL, todos os objetos de banco e os forms que utilizam esta coluna em comandos SQL, deverão fazer o tratamento da possibilidade desta coluna ter valor nulo. Assim, o uso desta coluna foi trocado pela expressão NVL(DTNOM, DTEXERC), uma vez que pelo menos uma das duas datas anteriores deve, obrigatoriamente, ser informada.
Campos adicionais nas transações de mudança
Visão do usuário:
As transações "Mudança de Cargo", "Mudança de Horário de Trabalho", "Mudança de Referência" e "Mudança de Setor" receberam 5 novos campos adicionais no bloco de consulta do provimento atual. Estes campos adicionais não permitem alteração, pois estão relacionados a um bloco de consulta (Dados do Provimento Atual).
Em caso de necessidade de alteração do valor dos campos adicionais, é necessário configurá-los também no bloco referente aos Novos Dados do Provimento, pois neste bloco a alteração dos campos é permitida.
Novas opções para a folha de pagamentos
Visão do usuário:
Foram criadas quatro novas opções no grupo FOLHAS, conforme explicação a seguir:
- Opção GRAVACAO_CALCULO : Indica se os resultados de cálculos devem ser gravados no Folha16 ou Folha03;
- Opção MESES_PRE_ERGON : Quantidade de meses pré-Ergon que pode ser calculados;
- Opção REPETE_FOLHA02 : Indica se os cálculos de folhas irão executar os Folha02 em duas passagens;
- Opção REPETE_FOLHA16 : Indica se os cálculos de folhas irão executar o Folha16 em duas passagens.
Funcionalidade nos campos de data para transação de licença especial
Visão do usuário:
Na transação 'Aquisição Licença Especial' foi implementado nos campos 'Término' e 'Prescrição', a funcionalidade de digitação do número de dias, que serão somados à data inicial, retornando na tela a nova data calculada. Nestes campos, poderá ser informada a data ou o número de dias a somar, precedido pelo sinal de soma (+).
Detalhes Técnicos:
No form ERG0181 foi implementado nos campos 'Término' e 'Prescrição' a funcionalidade de digitação do número de dias, que serão somados à data inicial, retornando na tela a nova data calculada. Nestes campos, poderá ser informada a data ou o número de dias a somar, precedido pelo sinal de soma (+). Este cálculo é feito pela function FORMAT_DATA_PERIODO, que foi incluída na trigger de WHEN-VALIDATE-ITEM dos campos DTFIM_AUX e DT_PRESCRICAO_AUX, que estão no bloco PERAQLICESP.
Melhor detalhamento dos perfis de segurança de atributo e freqüência
Visão do usuário:
Para detalhar melhor os perfis de segurança por atributo e frequência, foi preciso criar três novas campos nas transações correspondentes.
As transações alteradas são as seguintes:
- Transação "Perfis de Frequência" (form ERG0182)
Nesta transação foram adicionados ao bloco "Frequência" os campos:
"Alt." : Os usuários que têm acesso (padrão de acesso) a esta frequência podem alterá-la na base de dados?
"Cad." : Os usuários que têm acesso (padrão de acesso) a esta frequência podem cadastrá-la na base de dados?
"Rem." : Os usuários que têm acesso (padrão de acesso) a esta frequência podem removê-la da base de dados?
- Transação "Perfis de Segurança por Atributo" (form ERG0213)
Nesta transação foram adicionados ao bloco "Atributos" os campos:
"Alt." : Os usuários que têm acesso (padrão de acesso) a este atributo podem alterá-lo na base de dados?
"Cad." : Os usuários que têm acesso (padrão de acesso) a este atributo podem cadastrá-lo na base de dados?
"Rem." : Os usuários que têm acesso (padrão de acesso) a este atributo podem removê-lo da base de dados?
Foram necessárias algumas alterações na base de dados para refletir essas alterações nos perfis de atributos e de frequências.
Para utilizar melhor as alterações feitas nos perfis de atributos e de frequências, algumas transações foram modificadas.
- A primeira transação alterada foi a de "Freqüência", form ERG0102.
- A segunda transação alterada foi a de "Atributos de Funcionários", form ERG0105.
- A terceira transação alterada foi a de "Lista de Incompatibilidade de Atributos", form ERG0323.
Observação:
Para migrar para esse novo detalhamento dos perfis de frequências e de atributos, foi elaborado um script com essa finalidade, mantendo a compatibilidade da versão anterior com essa nova implementação. Para isso, todos os perfis existentes terão permissão de alteração, cadastro e remoção para manter compatibilidade com o esquema anterior.
Para utilizar os recursos desse novo esquema, o usuário deverá selecionar o perfil desejado e configurar as opções de alteração, cadastro e remoção da forma desejada.
Detalhes Técnicos:
Para refletir essas alterações no banco de dados, as seguintes alterações foram feitas:
A tabela PERF_FREQ_CODFREQ foi alterada, adicionando-se as seguintes colunas:
PODEALT VARCHAR2(1): Indica que a frequência pode ser alterada (valor "S");
PODECAD VARCHAR2(1): Indica que a frequência pode ser cadastrada (valor "S");
PODEREM VARCHAR2(1): Indica que a frequência pode ser removida (valor "S").
A tabela PERF_VANT_VANTAGEM foi alterada, adicionando-se as seguintes colunas:
PODEALT VARCHAR2(1): Indica que o atributo pode ser alterado (valor "S");
PODECAD VARCHAR2(1): Indica que o atributo pode ser cadastrado (valor "S");
PODEREM VARCHAR2(1): Indica que o atributo pode ser removido (valor "S").
Para controlar o perfil de frequências nas operações sobre os registros de frequência, a função PCK_FREQUENCIAS.PERFIL_FREQ foi alterada, adicionando-se a verificação aos valores dessas três novas opções. No procedimento PCK_FREQUENCIAS.MAIN_PRE, está sendo utilizada a função PCK_FREQUENCIAS.PERFIL_FREQ para cada uma das operações possíveis sobre os registros de frequência (INSERT, UPDATE, DELETE).
Para controlar o perfil de atributos nas operações sobre os registros de atributos, a função PCK_VANTAGENS.PERFIL_VANTAGEM foi alterada, adicionando-se a verificação aos valores dessas três novas opções. No procedimento PCK_VANTAGENS.MAIN_PRE, está sendo utilizada a função PCK_VANTAGENS.PERFIL_VANTAGEM para cada uma das operações possíveis sobre os registros de atributo (INSERT, UPDATE, DELETE).
Para utilizar melhor as alterações feitas nos perfis de atributos e de frequências, algumas transações foram modificadas.
- A primeira transação alterada, foi a de "Freqüência", form ERG0102. O mecanismo de configuração dinâmica dos campos foi modificado. Em função do padrão de acesso e perfil de frequência, os campos podem permitir ou não alterações e remoções. Isso já era feito, porém com as novas implementações, algumas modificações foram necessárias, como a utilização da função PACK_HADES.PADRAO_ACESSO_TRANSACAO.
- A segunda transação alterada, foi a de "Atributos de Funcionários", form ERG0105. O mecanismo de configuração dinâmica dos campos foi modificado. Em função do padrão de acesso e perfil de atributos, os campos podem permitir ou não alterações e remoções. Isso já era feito, porém com as novas implementações, algumas modificações foram necessárias, como a utilização da função PACK_HADES.PADRAO_ACESSO_TRANSACAO.
- A terceira transação alterada, foi a de "Lista de Incompatibilidade de Atributos", form ERG0323. Foi feita correção no controle do perfil de acesso nos RECORDS GROUP VANTAGEM_RG e MNEMFREQ_RG. No RECORD GROUP VANTAGEM_RG, foi adicionada a função PCK_VANTAGENS.PERFIL_VANTAGEM. No RECORD GROUP MNEMFREQ_RG, foi adicionada a função PCK_FREQUENCIAS.PERFIL_FREQUENCIA. Nos blocos TIPO_VANTAGEM e ERG_VANT_INCOMPAT_VANT, na clausula WHERE, foi adicionada a função: MOSTRA_VANTAGEM(FLAG_PACK.GET_USUARIO, VANTAGEM) = 1.
Com a finalidade de migrar para esse novo detalhamento dos perfis de frequências e de atributos, foi elaborado um script, mantendo a compatibilidade da versão anterior com essa nova implementação. Para isso, todos os perfis existentes terão permissão de alteração, cadastro e remoção para manter compatibilidade com o esquema anterior.
Para utilizar os recursos desse novo esquema, o usuário deverá selecionar um perfil e configurar as opções de alteração, cadastro e remoção da forma desejada.
Perfis de Segurança por Tipo de Evento
Visão do usuário:
A transação "Perfis de Segurança por Tipo de Evento", form ERG0288, foi criada.
Esta transação destina-se a estabelecer critérios de segurança para cada um dos tipos de evento cadastrados no sistema. Estes critérios (ou perfis) são baseados na existência de um padrão de acesso. Este padrão de acesso pode conter um conjunto de tipos de evento e o perfil pode conter um conjunto de padrões de acesso. Quando um determinado padrão de acesso é destinado a um usuário do sistema, o mesmo poderá ter acesso ao conjunto de tipos de evento do perfil de segurança ao qual o padrão de acesso encontra-se vinculado. Um "perfil de tipo de evento" terá os tipos de evento disponíveis para cadastramento, alteração e ou remoção e o padrão de acesso habilitará quais os usuários do sistema poderão cadastrar, alterar e ou remover esses tipos de evento. Três opções para cada tipo de evento determina qual a operação permitida para aquele perfil. Assim, o usuário somente poderá cadastrar, alterar e ou remover os tipos de evento disponíveis no perfil ao qual ele está habilitado e com a opção correspondente ao tipo de operação, habilitada.
O cadastro nesta tela é feito em três blocos, sendo que o perfil de segurança deve ser cadastrado no bloco "Perfil de Tipo de Evento".
A correspondência do perfil de tipo de evento com o padrão de acesso de usuário é feito no bloco "Padrão de Acesso".
E no bloco "Tipos de Evento" é feito o lançamento dos tipos de evento que compõem um perfil de segurança. Cada tipo de evento cadastrado possuirá três opções que funcionam da seguinte forma:
"Alt." : Se habilitada, os usuários que têm acesso (padrão de acesso) a este tipo de evento podem alterá-lo na base de dados.
"Cad." : Se habilitada, os usuários que têm acesso (padrão de acesso) a este tipo de evento podem cadastrá-lo na base de dados.
"Rem." :Se habilitada, os usuários que têm acesso (padrão de acesso) a este tipo de evento podem removê-lo da base de dados.
Foram necessárias algumas alterações na base de dados para refletir a criação dessa nova transação e colocar em prática a segurança por perfil de tipo de evento.
As transações cujo acesso será controlado pelos "Perfis de Segurança por Tipo de Evento" são as seguintes:
- Transação "Eventos de Cargo" (form ERG0302);
- Transação "Eventos de Progressão" (form ERG0303);
- Transação "Eventos de Mudança de Cargo" (form ERG0304);
- Transação "Eventos de Remoção" (form ERG0305);
- Transação "Eventos de Mudança de Jornada" (form ERG0306);
- Transação "Eventos de Substituição" (form ERG0300);
Detalhes Técnicos:
A transação "Perfis de Segurança por Tipo de Evento", form ERG0288, foi criada.
Para criar esta tela, foi necessário criar as seguintes estruturas no banco:
Tabela ERG_PERFIL_TIPOEV para cadastro do nome e da descrição de um perfil de tipo de evento. Ela apresenta as colunas:
- PERFIL : Nome do Perfil de Tipo de Evento.
- DESCRICAO : Descrição do Perfil de Tipo de Evento.
Com a PRIMARY KEY: ERG_PERFIL_TIPOEV_PK (PERFIL).
Tabela ERG_PERFIL_TIPOEV_PADACES para cadastro de perfil de tipo de evento por padrão de acesso. Ela apresenta as colunas:
- PERFIL : Nome do Perfil de Tipo de Evento.
- PADACES : Padrão de Acesso.
Com a PRIMARY KEY: ERG_PERFIL_TIPOEV_PADACES_PK (PERFIL, PADACES).
Com FOREIGN KEY: PERFTIPOEVPAD_PERFTIPOEV_FK (PERFIL) REFERENCES ERG_PERFIL_TIPOEV (PERFIL).
Com FOREIGN KEY: PERFTIPOEVPAD_PADACES_FK (PADACES) REFERENCES PADACES (PADACES).
Com índice: PERFTIPOEVPAD_PADACES_I ON ERG_PERFIL_TIPOEV_PADACES (PADACES).
Tabela ERG_PERFIL_TIPOEV_TIPOEV para cadastro de perfil de tipo de evento por tipo de evento. Ela apresenta as colunas:
- PERFIL : Nome do Perfil de Tipo de Evento.
- TIPOEVENTO : Nome do Tipo de Evento.
- PODEALT : Indica se o tipo de evento pode ser alterado (valor "S").
- PODECAD : Indica se o tipo de evento pode ser cadastrado (valor "S").
- PODEREM : Indica se o tipo de evento pode ser removido (valor "S").
Com a PRIMARY KEY: ERG_PERFIL_TIPOEV_TIPOEV_PK (PERFIL, TIPOEVENTO).
Com FOREIGN KEY: PERFTIPOEVTIPOEV_PERFTIPOEV_FK (PERFIL) REFERENCES ERG_PERFIL_TIPOEV (PERFIL).
Com FOREIGN KEY: PERFTIPOEVTIPOEV_TIPO_EV_FK (TIPOEVENTO) REFERENCES TIPO_EVENTO_ (TIPOEVENTO).
Com índice: PERFTIPOEVTIPOEV_TIPO_EV_I ON ERG_PERFIL_TIPOEV_TIPOEV (TIPOEVENTO).
Para controlar o acesso do usuário, foi criada a função "PERFIL_TIPOEV" na package PCK_EVENTO_FUNC. A função tem por finalidade verificar se o usuário tem permissão para manipular o tipo de evento passado como parâmetro. Essa permissão é determinada pelo conjunto formado pelo padrão de acesso do usuário, a transação que está utilizando e o perfil de segurança por tipo de evento. A definição desse conjunto e das permissões são feitas pelas tabelas ERG_PERFIL_TIPOEV_TIPOEV e ERG_PERFIL_TIPOEV_PADRAO. A função retorna um VARCHAR2 com até três posições, que indica o tipo de permissão que o usuário possui para manipular um determinado tipo de evento. Os possíveis valores são:
- Se o usuário for privilegiado ou tem permissão para todas as operações, o valor de retorno é "CAR";
- Se o usuário somente tem permissão para cadastrar, o valor de retorno é "C";
- Se o usuário somente tem permissão para alterar, o valor de retorno é "A;
- Se o usuário somente tem permissão para remover, o valor de retorno é "R".
- Se o usuário tem permissão para cadastrar e alterar, o valor de retorno é "CA";
- Se o usuário tem permissão para cadastrar e remover, o valor de retorno é "CR";
- Se o usuário tem permissão para alterar e remover, o valor de retorno é "AR";
- Se o usuário não tem nenhuma permissão, o valor de retorno é "N".
Os parâmetros de entrada são:
- P_USUARIO: Identificação do usuário;
- P_TIPOEVENTO: Identificação do tipo de evento;
- P_TRANSACAO: Nome da transação que está sendo utilizada;
A funçao deve ser utilizada nas triggers de transações e de tabelas que permitam o lançamento de tipos de evento.
A package PCK_EVENTO_FUNC foi alterada, adicionando-se a função PCK_EVENTO_FUNC.PERFIL_TIPOEV para fazer a verificação do perfil de segurança por tipo de evento para qualquer operação feita pelo usuário (cadastro, alteração e remoção). Se o perfil de segurança indicar que o usuário não tem permissão de executar determinada operação, sobre um determinado tipo de evento, a operação não será permitida.
Além da package, o controle de segurança também é feito barrando o cadastro de um tipo de evento, caso o usuário não tenha tal permissão. Esse esquema, foi implementado nas seguintes transações:
- Transação "Eventos de Cargo" (form ERG0302), ao record group TIPOEVENTO_RG foi adicionado a condição INSTR(pck_evento_func.perfil_tipoev(flag_pack.get_usuario, TIPOEVENTO, 'Eventos de Cargo'), 'C') <> 0;
- O form ERG_CLAS foi alterado, modificando o record group RG_CARGO_SETOR adicionando-se a condição INSTR(pck_evento_func.perfil_tipoev(flag_pack.get_usuario, TE.TIPOEVENTO, flag_pack.get_transacao), 'C') <> 0 e criando a LOV CARGO_SETOR_LOV. As alterações foram repassadas para o object group OG_EVFUNC_ATUAL e salvando na object library ERGON.OLB.
Essa mudança foi herdada pelos forms:
+ Transação "Eventos de Progressão" (form ERG0303);
+ Transação "Eventos de Mudança de Cargo" (form ERG0304);
+ Transação "Eventos de Remoção" (form ERG0305);
+ Transação "Eventos de Mudança de Jornada" (form ERG0306);
Observação:
Na transação "Eventos de Substituição" (form ERG0300), a segurança está sendo feita apenas através da package PCK_EVENTO_FUNC.
Os erros foram cadastrados e o help da tela foi feito.