BLV Técnico Versão 5.00 (Continuação)
Inclusão do campo empresa na transação Solicitação de Execução
Visão do usuário:
Na transação Solicitação de Execução foi incluído o campo EMPRESA, que irá indicar para qual empresa a execução será realizada. Neste campo será exibido o nome fantasia da empresa e serão mostradas as execuções dessa nas quais o usuário tem acesso.
Transação Destinos e Versões
Visão do usuário:
Na transação Destinos e Versões, foi criado a ficha Empresa, onde serão cadastradas as empresas que o destino irá atender.
Na tela será possível realizar o cadastramento e visualização somente das empresas que o usuário tiver acesso.
Relatórios otimizados
Detalhes Técnicos:
Os relatórios que utilizavam tabelas temporárias para auxiliar a manipulação dos dados agora utilizam as GLOBAL TEMPORARY tables, que visam otimizar o processo de geração de dados temporários, válidas apenas para uma determinada transação ou sessão.
Abrangência do concurso
Visão do usuário:
Foi criado novo campo no cadastro de concursos chamado ABRANGENCIA, e seus possíveis valores estão cadastrados na tabela geral ERG_ABRANG_CONC.
Detalhes Técnicos:
No form ERG0050, no canvas CONCURSOS foi incluído o campo ABRANGENCIA; ligado a ele foi criada a lista ordenada de valores denominada ABRANGENCIA_LOV, cujos valores estão cadastrados na tabela geral ERG_ABRANG_CONC.
Outra alteração feita foi na tabela CONCURSOS, onde foi criado o campo ABRANGENCIAS, através da aplicação do script CONCURSOS.TAB.
Representante legal do dependente
Visão do usuário:
Foi criada nova pasta chamada Endereço, que irá conter os campos do endereço do dependente.
Foram criados também os campos para o representante legal do dependente na transação Dependentes. O representante legal é a pessoa que irá representar o dependente, por exemplo quando o dependente for menor de idade e não possuir documentos e conta bancária.
Neste caso, primeiro deverá ser feito o cadastramento do representante legal como um dependente, e depois feito o cadastramento do dependente com o seu representantante legal.
Detalhes Técnicos:
Na transação dependentes, foram criados campos para o representante legal do dependente.
Foi criada também a pasta Endereço, que irá conter os campos de endereço do dependente.
Devido a estas mudanças, verifique layout da transação com os novos campos.
Histórico de alterações de dados pessoais
Visão do usuário:
Foram criadas formas de armazenamento de dados referentes a histórico de alterações dos dados funcionais. Com isto:
1) É possível armazenar o histórico de alterações das informações particulares de cada funcionário, onde a situação cadastral atual deste é determinada através do histórico cuja data final estiver em branco.
Será criado automaticamente o histórico para o funcionário que está sendo cadastrado no sistema, e terá como data inicial o dia e horário do cadastramento e como data final o valor em branco, representando assim a situação atual do funcionário na empresa.
Se alguma alteração for feita para qualquer funcionário cadastrado, um novo histórico automaticamente será criado, com as caracteríticas descritas acima, e o histórico anterior será encerrado.
Caso o cadastro do funcionário seja removido do sistema, seu histórico será encerrado, na data e horário da remoção.
Existem duas restrições que precisam ser ressaltadas:
1) Não é possível remover um histórico cuja data final está em branco, uma vez que esse representa a situação atual do funcionário;
2) Não poderão ser criados dois históricos com a data final em branco, devendo existir somente um histórico nesta situação.
3) Não é possível remover por completo o histórico de um funcionário se houverem históricos de dependentes, históricos de vínculos e históricos de matrículas relacionados ao funcionário.
Em caso de migração para esta versão, será criado automaticamente o histórico para cada funcionário cadastrado no sistema, e com a data final em branco.
2) É possível armazenar o histórico de alterações das informações particulares de cada dependente de um determinado
funcionário, segundo os mesmos conceitos do histórico de alterações do cadastro de funcionários. Assim, a data final em branco representa a situação cadastral atual do dependente.
Será criado automaticamente o histórico do dependente no momento de seu cadastramento no sistema, tendo como data inicial o dia e horário do cadastro e data final em branco, representando desta forma a situação atual do dependente na empresa.
Se alguma alteração cadastral for feita para qualquer dependente, um novo histórico automaticamente será criado, com as caracteríticas descritas acima, e o histórico anterior será encerrado no segundo anterior ao início do novo histórico.
Se um dependente for removido do sistema, seu histórico será encerrado na data e no horário da remoção.
Existem duas restrições que precisam ser ressaltadas:
1) Não é possível remover um histórico com a data final em branco, pois esse representa a situação atual do dependente;
2) Não poderão ser criados dois históricos com data final em branco, devendo existir somente um nesta situação.
Como ponto de partida na migração desta versão, será criado automaticamente um histórico com data final em branco para cada dependente cadastrado no sistema.
3) É possível armazenar o histórico de alterações das informações particulares de cada pensionista de um determinado funcionário.Com isto, para cada novo pensionista cadastrado no sistema é criado automaticamente um histórico, tendo como data inicial o dia e horário do cadastramento, e como data final o valor em branco. Esta data final identificará a situação cadastral atual do pensionista.
Se alguma alteração cadastral for feita para qualquer pensionista, um novo histórico automaticamente será criado, com as características descritas acima, e o histórico anterior será encerrado.
Caso o pensionista seja removido do sistema, seu histórico será encerrado na data e horário da remoção.
Duas restrições precisam ser ressaltadas:
1) Não é possível remover um histórico com a data final em branco, pois esse representa a situação atual do pensionista;
2) Não poderão ser criados dois históricos com data final em branco, devendo existir somente um histórico nesta situação.
Como ponto de partida na migração desta versão, será criado automaticamente um histórico com a data final em branco, para cada pensionista cadastrado no sistema.
4) É possível armazenar o histórico de alterações de matrículas de um determinado funcionário.
A descrição feita aqui é idêntica aos históricos citados acima, ou seja, ele será criado automaticamente para a matrícula que está sendo cadastrada no sistema, tendo como data inicial o dia e horário do cadastramento e como data final o valor em branco. Igualmente, a data final em branco representa a situação atual da matrícula do funcionário.
Se alguma alteração cadastral for feita para qualquer matrícula, um novo histórico será automaticamente criado, com as caracteríticas descritas acima, e o histórico anterior será encerrado.
No caso da matrícula ser removida do sistema, seu histórico será encerrado com a data e horário da remoção.
Existem duas restrições que precisam ser ressaltadas:
1) Não é possível remover um histórico com a data final em branco, pois esse representa a situação atual da matrícula;
2) Não poderão ser criados dois históricos cuja data final esteja em branco, devendo existir somente um histórico nesta situação.
3) Não é possível remover por completo o histórico de uma matrícula se houverem históricos de vínculos relacionados a essa matrícula.
Como ponto de partida na migração desta versão, será criado automaticamente um histórico com data final em branco para cada matrícula cadastrada no sistema.
5) É possível também armazenar o histórico de alterações de vínculos de um determinado funcionário.
A descrição feita aqui é identica a feita para os históricos acima, ou seja, o sistema criará automaticamente um histórico cadastral para o vinculo que está sendo cadastrado no sistema, com data inicial igual ao dia e horário do cadastramento e data final em branco, representando a situação cadastral atual do vínculo.
Se alguma alteração cadastral for feita para qualquer vínculo, um novo histórico será automaticamente criado, com as caracteríticas descritas acima, e o histórico anterior será encerrado.
Caso o vínculo seja removido do sistema, seu histórico será encerrado na data e horário da remoção.
Vale ressaltar aqui três restrições:
1) Não é possível remover um histórico com a data final em branco, pois esse representa a situação atual do vínculo;
2) Não poderão ser criados dois históricos com data final em branco, devendo existir somente um histórico nesta situação.
3) Não é possível remover por completo o histórico de um vínculo se houverem históricos de pensionistas relacionados a esse.
Como ponto de partida na migração desta versão, será criado automaticamente um histórico com data final em branco para cada vínculo cadastrado no sistema.
Detalhes Técnicos:
Foram criadas 5 novas tabelas: ERG_HIST_FUNC, ERG_HIST_DEP, ERG_HIST_PENS, ERG_HIST_MATRIC, ERG_HIST_VINC. Segue abaixo as características de cada uma:
1)Tabela ERG_HIST_FUNC:
Esta tabela é uma cópia da tabela FUNCIONARIOS, tirando apenas a coluna FOTO. Outras três colunas foram adicionadas à ela:
DTINI DATE NOT NULL
DTFIM DATE
USUARIO VARCHAR2(15)
Os comentários das colunas foram gerados também.
Para esta tabela foi criada a chave primária ERG_HIST_FUNC_PK com as colunas (NUMERO, DTINI).
Foi criada a foreign key ERG_HIST_FUNC_USUARIO_FK da coluna USUARIO para a coluna USUARIO da tabela USUARIO do HADES.
O índice ERG_HIST_FUNC_IDX para a coluna NUMERO também foi criado.
Foram geradas as triggers da tabela conforme o padrão. São elas: T_B_IUD_ERG_HIST_FUNC, T_BS_IUD_ERG_HIST_FUNC e T_A_IUD_ERG_HIST_FUNC.
A package PCK_ERG_HIST_FUNC também foi gerada para a tabela, e algumas alterações foram feitas:
Na package specification foi feito o help padrão das validações.
Na package body foram adicionadas duas novas validações; uma na procedure MAIN_PRE, para que permitir remover histórico com data fim nula, e outra na procedure MAIN_POS para não permitir cadastramento de histórico com a data de fim nula, caso já exista histórico com esta data. Além disso, ao remover o histórico, é verificado se ele é o último histórico do funcionário cadastrado na tabela. Se for, é verificado se existem históricos de dependentes, vínculos e matrículas relacionados ao vínculo. Se houverem, a remoção só será possível, removendo-se todos os registros de históricos de dependentes, vínculos e matrículas.
2)Tabela ERG_HIST_DEP:
Esta tabela é uma cópia da tabela DEPENDENTES, com exceção da coluna FOTO, e mais três outras colunas foram criadas:
DTINI DATE NOT NULL
DTFIM DATE
USUARIO VARCHAR2(15)
Os comentários das colunas foram todos gerados.
Para esta tabela foi criada a chave primária ERG_HIST_DEP_PK, com as seguintes colunas : NUMFUNC, NUMERO e DTINI.
Também foi criada a foreign key ERG_HIST_DEP_USUARIO_FK da coluna USUARIO para a coluna USUARIO da tabela USUARIO do HADES.
O índice para a coluna NUMFUNC e NUMERO foi criado e denominado ERG_HIST_DEP_IDX .
Foram geradas as triggers da tabela conforme o padrão e denominadas T_B_IUD_ERG_HIST_DEP, T_BS_IUD_ERG_HIST_DEP e T_A_IUD_ERG_HIST_DEP.
Foi gerada também a package PCK_ERG_HIST_DEP para a tabela, e algumas alterações foram feitas:
- Na package specification foi feito o help padrão das validações.
- Na package body foram adicionadas duas validações : uma na procedure MAIN_PRE, para não permitir remoção de histórico com data fim nula; e outra na procedure MAIN_POS, para não permitir cadastramento de histórico com a data de fim nula, caso já exista histórico com data de fim nula.
3)Tabela ERG_HIST_PENS:
Esta tabela é uma cópia da tabela PENSIONISTAS, mas com mais três novas colunas criadas:
DTINI DATE NOT NULL
DTFIM DATE
USUARIO VARCHAR2(15)
Os comentários das colunas foram gerados.
Para esta tabela foi criada a chave primária ERG_HIST_PENS_PK, com as colunas (NUMFUNC, NUMVINC, NUMERO, DTINI).
Além disso, foi criada a foreign key ERG_HIST_PENS_USUARIO_FK da coluna USUARIO para a coluna USUARIO da tabela USUARIO do HADES.
O índice para a coluna NUMFUNC, NUMVINC e NUMERO também foi criado e denominado ERG_HIST_PENS_IDX.
Foram geradas as triggers da tabela conforme o padrão, e nomeadas como T_B_IUD_ERG_HIST_PENS, T_BS_IUD_ERG_HIST_PENS e T_A_IUD_ERG_HIST_PENS.
Também foi gerada a package PCK_ERG_HIST_PENS para a tabela, e algumas alterações foram feitas:
- Na package specification foi feito o help padrão das validações.
- Na package body foram adicionadas duas validações; uma na procedure MAIN_PRE, para não permitir remover histórico com data fim nula; e outra na procedure MAIN_POS, para não permitir cadastramento de histórico com a data de fim nula, caso já exista histórico com esta data.
4)Tabela ERG_HIST_MATRIC:
Esta tabela é uma cópia da tabela ERG_MATRICULAS, com mais três novas colunas:
DTINI DATE NOT NULL
DTFIM DATE
USUARIO VARCHAR2(15)
Foram gerados os comentários das colunas.
Para esta tabela foi criada a chave primária ERG_HIST_MATRIC_PK, com as colunas NUMFUNC, MATRIC e DTINI.
Também foi criada a foreign key ERG_HIST_MATRIC_USUARIO_FK da coluna USUARIO para a coluna USUARIO da tabela USUARIO do HADES.
O índice ERG_HIST_MATRIC_IDX para a coluna NUMFUNC e MATRIC também foi criado.
Foram geradas as triggers da tabela conforme o padrão, e denominadas como T_B_IUD_ERG_HIST_MATRIC, T_BS_IUD_ERG_HIST_MATRIC e T_A_IUD_ERG_HIST_MATRIC
Foi gerada também a package PCK_ERG_HIST_MATRIC para a tabela, e algumas alterações foram feitas:
- Na package specification foi feito o help padrão das validações.
- Na package body foram adicionadas duas validações: uma na procedure MAIN_PRE, que não permite remover histórico com data fim nula; e outra na procedure MAIN_POS, que não permite cadastrar histórico com a data de fim nula, se já existe histórico com esta data. Além disso, ao remover o histórico, é verificado se este é o último histórico da matrícula cadastrado na tabela. Se for, é feita a verificação se há histórico de vínculos relacionado à matrícula; se houverem, a remoção só será possível removendo-se todos os registros de históricos de vínculos.
5)Tabela ERG_HIST_VINC:
Esta tabela é uma cópia da tabela VINCULOS, com mais três novas colunas:
DTINI DATE NOT NULL
DTFIM DATE
USUARIO VARCHAR2(15)
Os comentários das colunas foram gerados.
Para esta tabela foi criada a chave primária ERG_HIST_VINC_PK com as colunas (NUMFUNC, NUMERO, DTINI).
Foi criada também a foreign key ERG_HIST_VINC_USUARIO_FK da coluna USUARIO para a coluna USUARIO da tabela USUARIO do HADES.
O índice criado para a coluna NUMFUNC e NUMERO foi denominado ERG_HIST_VINC_IDX.
Também foi criado o índice ERG_HIST_VINC_MATRIC_IDX para a coluna NUMFUNC e MATRIC.
Foram geradas as triggers da tabela conforme o padrão, e denominadas: T_B_IUD_ERG_HIST_VINC, T_BS_IUD_ERG_HIST_VINC e T_A_IUD_ERG_HIST_VINC.
Foi gerada também a package PCK_ERG_HIST_VINC para a tabela, e algumas alterações foram feitas:
- Na package specification foi feito o help padrão das validações.
- Na package body foram adicionadas duas validações. Uma na procedure MAIN_PRE, que não permite remover histórico com data fim nula; e outra na procedure MAIN_POS, que não permite cadastrar histórico com a data de fim nula, se já existe histórico com esta data. Além disso, ao remover o histórico, é verificado se este é o último histórico do vínculo cadastrado na tabela. Caso seja, é averiguado se existe histórico de pensionistas relacionados ao vínculo. Havendo, a remoção só será possível se antes forem removidos todos estes registros de históricos de pensionistas.
Para gerar os históricos automaticamente para funcionários, dependentes, matrículas, vínculos e pensionistas foram adicionados códigos nas packages PCK_FUNCIONARIOS, PCK_DEPENDENTES, PCK_PENSIONISTAS, PCK_VINCULOS e PCK_ERG_MATRICULAS.
Nestas packages, se no update for detectado alguma alteração de informações do cadastro, um novo histórico será gerado. Se for um insert um novo histórico será gerado também. E se for removido o registro, o histórico atual é fechado na data e horário da remoção.
Devido a este esquema, alguns novos erros foram inseridos na tabela HAD_ERROS para serem utilizados.
Além disso, foram elaborados 5 scripts que, ao serem aplicados os scripts de criação desses históricos, gerarão históricos com data fim nula, para todos os funcionários, dependentes, pensionistas, matrículas e vínculos cadastrados no sistema. Este processo será o ponto de partida.