BLV Técnico Versão 5.03
Boletim de Liberação de Versão
SISTEMA ERGON
Versão: 5.03
Pré requisitos do sistema:
Versão do Banco Oracle: 8.1.7 ou superior, parâmetro NLS_CHARACTER_SET = WE8ISO8859P1, parâmetro NLS_SORT = binary.
Sistema Operacional: Windows NT/2000.
Esta versão requer que a package DBMS_ALERT esteja instalada no usuário SYS e que os usuários HADES, ERGON e C_ERGON tenham o privilégio de execução (GRANT EXECUTE ON DBMS_ALERT TO HADES, ERGON, C_ERGON). A disponibilidade da package e a execução do comando de permissão de execução devem ser executados pelo DBA.
Nas máquinas com NT o usuário do sistema operacional deve ter permissão de acesso (FULL ACCESS) às chaves do registry definidas para execução dos FORMS.
Avisos importantes para a parte técnica :
1) Antes de fazer a instalação do ERGON, deve-se fazer um backup de todas as functions, procedures, package specifications, package bodies e views do usuário customizado C_ERGON. Ao final da migração, deve-se fazer uma comparação do que existia no cliente com a nova estrutura do usuário customizado. As customizações que já haviam sido realizadas devem ser reaplicadas na nova estrutura.
2) Ainda em relação ao ambiente do C_ERGON, a codificação dos entry-points das transações do ERGON estão nas packages PCK_AFTER_CERGON e PCK_BEFORE_CERGON. Essas packages podem conter códigos de customizações específicas criados pelo próprio cliente. Por este motivo é importantíssimo que o procedimento descrito a seguir seja realizado. Em primeiro lugar, esses arquivos precisam ser copiados do CD de instalação do Ergon, onde poderão ser encontrados na pasta denominada "c_ergon". São quatro arquivos que possuem os seguintes nomes: PCK_AFTER_CERGON.PKS, PCK_BEFORE_CERGON.PKS (as especificações das packages) e PCK_AFTER_CERGON.PKB, PCK_BEFORE_CERGON.PKB (o corpo das packages). Após a cópia, estes arquivos deverão ser comparados com os mesmos objetos que estão aplicados no banco e através de um simples COPY/PASTE o cliente deverá adicionar nas packages que estão no seu ambiente os novos entry-points de transação que foram criados. É necessário alterar todos os quatro objetos, ou seja, duas packages specification e duas packages bodies.
Para aqueles clientes que utilizam a emissão de atos, o sistema utiliza-se de macros para a criação desses. Neste caso, para que o Microsoft Word funcione, o nível de segurança para macros não pode estar setado no máximo, pois isto desabilita a execução de macros dentro do editor, impossibilitando assim a emissão dos atos.
Quando da instalação completa do sistema ou quando da migração de versão, sugerimos que todos os segmentos de rollback sejam colocados offline e que apenas um segmento de rollback fique online. Este segmento deverá ser o maior segmento de rollback do banco de dados. Opcionalmente pode-se criar um segmento de rollback muito grande em uma nova tablespace e remover esta tablespace (e seu arquivo físico) após a instalação/migração. Outro aspecto a ser considerado é que o tal segmento para a instalação/migração não pode estar com o OPTIMAL setado porque isto poderá acarretar no erro ORA-01555 : snapshot too old.Sugerimos também que o parâmetro OPEN_CURSORS seja alterado para, pelo menos, 2500 quando da migração, e que o parâmetro SHARED_POOL_SIZE seja revisto, pois os sistemas Archon se utilizam de program units por vezes bastante grandes. Um valor sugerido seria algo em torno de 200Mb.
O parâmetro JOB_QUEUE_PROCESSES, cujo valor default é ZERO, deve ser setado para algum valor diferente de ZERO, entre 1 e 36.
Antes de iniciar a migração do sistema, é necessário que o DBA execute o script ERGON.TBS que se encontra na raiz do CD.
Sugerimos que sejam ajustados as seguintes variávis de ambientes/registry: NLS_NUMERIC_CHARACTERS=",.", NLS_SORT="BINARY" e NLS_DATE_FORMAT="DD/MM/YYYY"
A versão do Developer a ser utilizada deve o Forms 6.0.8.18.3 / Reports 6.0.8.18.0 (patch 9 de correção da Oracle) ou superior.
Para ambientes distribuídos, sugerimos que os forms, os reports, os atos e quaisquer outros recursos que devem estar disponíveis para o usuário através da rede fiquem em máquinas com o mesmo nome (exemplo : ARCHON) para diferentes sub-redes. Desta forma, opções como diretório de help, documentos, entre outros, ficarão facilmente acessíveis para cada sub-ponto da rede, sem acarretar problemas para o administrador de rede, que deve apenas se preocupar com a atualização dos arquivos que devem ser distribuídos.
Novas Características/Implementações
Inclusão de novos dados na geração de informações para os bancos
Visão do usuário:
Foram incluídos os dados de regime jurídico, tipo de vínculo, número da ficha financeira, data de exercício, data de aposentadoria e data de vacância no arquivo que deverá ser enviado para os bancos.
Detalhes Técnicos:
Foram criadas, na tabela FITABANCO, as colunas FICHA como number(14), REGIMEJUR como VARCHAR2(20), TIPOVINC como VARCHAR2(20), DTEXERC como DATE, DTAPOSENT como DATE, DTVAC como DATE e CATEGORIA como VARCHAR2(20).
Também a função GERA_FITABANCO foi alterada para obter os valores das novas colunas, REGIMEJUR, CATEGORIA e TIPOVINC através das funções PACK_ERGON.GET_REGIMEJUR_FUNC, PACK_ERGON.GET_CATEGORIA_FUNC e PACK_ERGON.GET_TIPOVINC_FUNC, respectivamente. A coluna FICHA é obtida através do campo FICHA da view FICHAS_FINANCEIRAS. E as colunas DTEXERC, DTAPOSENT e DTVAC são obtidas através de um select na tabela VINCULOS.
Além disso foi criado um script para migrar essas colunas criadas com os valores registrados no banco de dados para clientes que utilizam versões anteriores do Ergon.
Parâmetro de data para o entry-point da função GET_SETOR_FUNC.
Detalhes Técnicos:
Na função PACK_ERGON.GET_SETOR_FUNC, será passado para o entry-point EP__GET_SETOR_FUNC a mesma data que ela receber.
Anteriormente quando o servidor possuísse vacância, era passado para o EP o dia anterior à vacância.
Novo campo de filtro para geração do grupo de eleitos
Visão do usuário:
A transação "Gera Grupo de Eleitos" recebeu um novo campo para filtragem dos dados. O campo "Empresa" foi criado com o objetivo de permitir que o usuário selecione apenas uma empresa para a geração do grupo de eleitos. Neste caso, somente os vínculos pertencentes à empresa selecionada e que atendam aos demais filtros serão incluídos no grupo de eleitos que está sendo gerado.
No caso de o campo Empresa não ser preenchido, o grupo de eleitos será gerado com vínculos pertencentes a quaisquer empresas cadastradas no sistema, desde que atendam aos demais filtros.
Adição de grupo de eleitos na geração dos arquivos bancários
Visão do usuário:
Foi adicionado o parâmetro "Grupo de Eleitos" como uma nova opção para restringir o conjunto de funcionários para os quais a rotina será executada. Isso é útil, principalmente, se for necessário executar uma correção para alguns funcionários após o término da geração os dados no arquivo bancário. Assim, evita-se reprocessar a rotina para todos os funcionários, bastando executá-la apenas para o grupo desejado. Este filtro do grupo de eleitos é opcional. Se omitido ou tiver valor igual a "0" (zero - padrão) a rotina será processada para todos os vínculos presentes na ficha financeira em questão.
A auditoria dessa rotina ficou mais detalhada, facilitando o acompanhamento do processamento e manutenção da rotina.
Detalhes Técnicos:
Foi adicionado o parâmetro P_ELEITOS para atender à restrição do grupo de eleitos para o qual a rotina será executada. Este parâmetro é opcional. Se omitido ou tiver valor igual a "0" (zero) a rotina será processada para todos os vínculos presentes na ficha financeira em questão.
Foram adicionados logs mais detalhados na auditoria da rotina.
O parâmetro foi cadastrado no sistema.
Nova característica sobre a geração de arquivos bancários
Visão do usuário:
A fim de facilitar a utilização dos dados de arquivos bancários durante o processo de pré-consolidação da folha com emissão de relatórios, a restrição que havia na rotina GERA_FITABANCO de obrigatoriedade da consolidação da folha foi retirada. A partir desta versão, então, é possível executar a rotina GERA_FITABANCO mesmo sem ter consolidado a folha de pagamentos.
A restrição com relação à consolidação da folha de pagamento foi transferida, agora, para o parcelamento de crédito, o próximo passo no processo de geração de arquivos bancários.
Adição do campo Data de geração do arquivo bancário em Folhas
Visão do usuário:
Na transação Folhas foi incluído o campo Data de geração FITABANCO, que irá indicar a data de execução da rotina GERA_FITABANCO (rotina de geração do arquivo bancário). Este campo serve somente para consulta e não poderá ser alterado. Sua alteração será feita apenas pela rotina GERA_FITABANCO. No início da execução da rotina, o campo ficará em branco, sendo preenchido com a data e hora do fim da execução ao término da mesma (se não houver erros). Não será permitido consolidar uma folha de pagamentos se este campo estiver em branco. Após a consolidação da folha de pagamentos não será possível executar a rotina GERA_FITABANCO.
Detalhes Técnicos:
Foi incluído o campo DATA_GERACAO_FITABANCO nas tabelas FOLHAS e FOLHAS_EMP para ser utilizado pela rotina GERA_FITABANCO e para ser apresentado na transação "Folhas", conforme descrito acima.
Restrição de lançamento manual de contracheque
Visão do usuário:
No lançamento manual de contracheque, foi criada uma restrição que irá permitir somente o cadastro das rubricas se elas estiverem cadastradas nos fatores correspondentes ao tipo de vínculo, regime jurídico, categoria e subcategoria do servidor. Foi criado o tipo de fator "LANCAM. MANUAL". Com este tipo de fator, será criado um fator para cada regime jurídico/tipo de vínculo, categoria e subcategoria, com nome composto do prefixo (RJ_, TV_, CT_, SC_) mais a sigla. Por exemplo RJ_CLT, TV_EFETIVO. Devem ser cadastradas as rubricas válidas nos respectivos fatores para o lançamento manual.
Detalhes Técnicos:
No lançamento manual de contracheque, foi criada uma restrição que irá permitir somente o cadastro das rubricas se elas estiverem cadastradas nos fatores correspondentes ao tipo de vínculo, regime jurídico, categoria e subcategoria do servidor. Foi criado o tipo de fator "LANCAM. MANUAL". Com este tipo de fator, será criado um fator para cada regime jurídico/tipo de vínculo, categoria e subcategoria existente, com nome composto do prefixo (RJ_, TV_, CT_, SC_) mais a sigla. Por exemplo RJ_CLT, TV_EFETIVO. Para todos os fatores de lançamento manual serão criado os sinais: 1 - PERMITIDO e 0 - N PERMITID. Devem ser cadastradas as rubricas válidas nos respectivos fatores para o lançamento manual.
Os campos da sigla do fator foram aumentados para 25 caracteres, mas se o fator for utilizado pelos programas de folha, somente será possível cadastrar fatores com até 20 caracteres.
Se o fator correspondente a um regime jurídico/tipo de vínculo/categoria/subcategoria não existir, não será feita a validação. Mas se existir a rubrica a ser lançada, deverá estar cadastrada no fator correspondente.