(Obrigatório)

Informações Gerais

   Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos). 

(Obrigatório)

Objetivo

<Nesta etapa informar o objetivo da especificação do requisito, ou seja, o que a funcionalidade deve fazer. Exemplo: Permitir que o usuário defina o percentual mínimo em espécie (dinheiro), a referência mínima para calculo dos débitos do aluno e o período de validade do parâmetro de negociação>.

Objetivo

            A especificação presente visa detalhar as etapas necessárias para que o atual módulo de auditoria no sistema se torne genérico para outras telas, facilitando assim que futuras melhorias no sistema possam ser integradas no módulo, simplificando a codificação por parte dos desenvolvedores e tornando o módulo mais completo para os clientes.

            Não obstante, esta melhoria – numa primeira etapa – ainda contemplará o padrão onde as tabelas que vão para auditoria devem ser no formato cabeçalho/item e críticas, ou seja, para que o item desejado vá para auditoria, será necessário que ele contenha o cabeçalho descritivo e seus itens, além da seleção de críticas, para que o sistema possa interligar o cabeçalho com o item e depois, com sua respectiva crítica, selecionada pelo operador no momento em que deseja mandar para auditoria.

            Além disto, é necessário também estabelecer a relação de efeito da auditoria, ou seja, quando for dado o parecer do item em questão, será preciso dar o retorno deste parecer (negado ou autorizado) para o item que foi originado, confirmando que o mesmo já foi auditado. Logo, além das mudanças para incluir o item em questão na auditoria, será necessário também interligar o resultado do parecer com o item, atestando que o mesmo já foi auditado.

            Assim, podemos definir que todos os itens que necessitam de auditoria (desde que no formato descrito no parágrafo anterior) serão encaminhados para o módulo de Auditoria, facilitando a compreensão pelos envolvidos e acelerando o processo de auditoria, que poderá atuar em mais itens e manter o histórico de todas as transações realizadas, além da diminuição do esforço necessário para o controle destes itens, pois tudo ficará centralizado no módulo de auditoria. 

Definição da Regra de Negócio

1. Será necessário alterar várias partes dos fontes envolvidos, mas mantendo as características atuais de funcionamento, sem prejuízo para as funcionalidades existentes hoje no sistema.
2. Criar o campo B53_ROTGEN na tabela B53 – Auditoria por Guia, que terá as opções 0=NÃO e 1=SIM, pois quando for chamado de outras rotinas que não seja o atendimento (ou seja, as existentes hoje), deverá ser marcado com o valor “1” – SIM. O inicializador do campo deverá ter o valor “0”.
3. Criar o campo B53_ALIITE na tabela B53 – Auditoria por Guia, para armazenar o alias da tabela de itens da rotina que está utilizando a função, para que o sistema possa depois recuperar os itens corretamente.
4. Criar o campo B53_ALICRI na tabela B53 – Auditoria por Guia, para armazenar o alias da tabela onde são salvas as críticas do item auditado, para que o sistema possa depois relacionar o item com sua crítica para exibição na tela de análise.
5. Alterar a descrição e o título do campo B53_NUMGUI para outro mais apropriado (sugestão: Número de Controle), pois nem sempre o item auditado será uma guia e poderá causar confusão nos usuários. Selecionar também para que o campo não seja mais obrigatório.
6.  No campo B53_TIPO será necessário criar mais uma opção no combo, chamada Outros. Sempre que a rotina for chamada via rotinas externas, deverá ser marcado esta opção. Sugere-se a alteração do título e descrição do campo, para que fica mais plausível com a nova rotina Genérica (Sugestão: Tipo).
7. Nos demais campos da tabela B53, sempre que algum campo não for preenchido – por se tratar de campo de atendimento – definir o valor padrão para não ou outro status adequado.
8. No tocante as críticas, será necessário verificar e criar função para compatibilização com o módulo existente hoje, para assegurar o correto relacionamento entre item e críticas. Assim, será necessário desenvolver uma rotina específica para tratamento das críticas, para que sejam relacionadas e exibidas corretamente quando necessários.  
   1. A função para compatibilização de críticas terá que ser desenvolvida pensando no modelo existente, para que se torne genérica em qualquer situação.
   2. Será necessário que a rotina possa receber a posição da chave e sequencia de crítica e relacionar isso com o item, para que possa ser exibida corretamente na tela de análise.
   3. Para exemplificar, o funcionamento deve ser idêntico ao que ocorrer hoje, mas mantendo as características genéricas.
9. Será necessário alterar o método SetAuditoria, que fica no fonte PLSA790C, pois este método é o responsável em enviar os itens para o módulo de auditoria. Hoje, ele é focado nas guias existentes no sistema e será necessário deixá-lo genérico, mas mantendo suas características atuais de funcionamento.
10. Dentro do método, será necessário criar variáveis do tipo Default para os parâmetros da função, pois alguns campos não serão passados quando a auditoria vier de outros módulos.
11. Deverá ser observado também a passagem do parâmetro de Status (campo B53_SITUAC), para que a guia fique no status correto (Em Análise / Negado / Aprovados e outros).
12. Dentro do método SetAuditoria, será necessário dividir o bloco de programação existente com if ou outro comando que o desenvolvedor julgar melhor, para separar o legado existente com a nova funcionalidade. Essa divisão é necessária, pois o bloco atual salva os dados conforme as nomenclaturas de campos existentes hoje, o que não irá acontecer com outras tabelas. Logo, será necessário dividir o bloco e trabalhar para a generalização.
13. Devido as diferenças de nomenclaturas, será necessário desenvolver uma função para identificar a posição dos itens que precisam ser relacionados com os campos da tabela B53. Essa função deverá ser usada pelo desenvolvedor que quiser utilizar a rotina genérica, pois será necessário identificar no vetor de cabeçalhos/itens a posição de cada elemento, para que sejam salvos nos campos corretos.
    1. Isso se faz necessário, pois atualmente, por haver padronização nos nomes de campos nas tabelas de atendimento, na função SetAuditoria e em outras partes, o relacionamento é baseado no nome dos campos.
    2. Assim, para se tornar genérica, é necessária essa função, para informar a posição de cada um dos campos que serão salvos na tabela B53, para a gravação correta.
14. Ainda na função SetAuditoria, será necessário receber o alias da tabela pai (B53_ALIITE)e filha (B53_ALICRI), para salvar no campo correspondente da B53. Isso será necessário, para que quando o sistema for exibir os itens para análise, saiba em qual alias buscar o item da auditoria (o campo B53_ALIITE).
15. Tratar o método SetSituac no fonte PLSA790C, para tratar as rotinas que são provenientes da rotina genérica, para que ocorra a validação do status da guia de forma correta. Se for necessário, usar comando if ou outro similar para separar os blocos de códigos entre legado e a nova rotina de auditoria.
16. Tratar o método AtuPClass no fonte PLSA790C, para tratar as rotinas que são provenientes da rotina genérica. Se for necessário, usar comando if ou outro similar para separar os blocos de códigos entre legado e a nova rotina de auditoria.
17. Tratar o método RetAliRel no fonte PLSA790C, para tratar o retorno dos alias envolvidos quando a rotina for genérica. Essa função informar ao fonte Control (PLSA790C) do módulo quais são os alias esperados.
    1. Como a função é baseada em atendimento, os relacionamentos estão fixos no fonte e será necessário tratar isso para quando a rotina for genérica.
    2. Utilizar o comando if ou outro similar para separar os blocos de códigos entre legado e a nova rotina para determinar estes alias.
18. No fonte PLSA790V, será necessário tratar a função PLS790ANA, pois ela é responsável pela exibição da tela de Análise da guia, onde são exibidos os itens para auditoria e as críticas atreladas a cada item.
    1. Esta definição de alias é baseada na rotina RetAliRel. Por isso, a obrigatoriedade em tratar esta função, para que o relacionamento ocorra de forma correta.
19. A função PLS790ALS, no fonte PLSA790V, deverá ser tratada, pois é a responsável pela exibição da tela de Parecer e deverá buscar os dados corretos. Separar a funcionalidade existente hoje coma nova via comando if ou outro similar.
20. Ainda no fonte acima, será necessário verificar a função de validação e commit (gravar) do formulário, para que após a seleção do parecer e for clicado o botão Salvar, o sistemapossa atualizar o status do campo de auditoria na tabela de cabeçalho de origem – o parecer fica na tabela B72.
    1. Ou seja, quando todos os itens forem auditados, será necessário atualizar a tabela de cabeçalho, informando que a mesma não encontra-se mais em auditoria.
    2. As funções responsáveis por estes atos de validações e gravação encontram-se nos fontes PLSANALM e PLSPADRC.
21. Na tela de auditoria – PLSA790V – será necessário também controlar o menu Outras Ações, pois quando for rotina genérica (o campo B53_ROTGEN estará com o valor “1”), os menus que pertencem as funções de guia não poderão ser disponibilizados ao usuário, já que as guias serão de diversos tipos. Assim:
    1. Será necessário criar uma função de controle para estes menus, no fonte PLSA790C, onde alguma variável (sugestão de nome: lTratRotG) irá receber o valor lógico Verdadeiro (.T.) quando for totina genérica.
    2. De acordo com essa variável, se o valor for verdadeiro, será necessário bloquear (neste caso, deverá exibir uma mensagem (ALERT/MSGALERT) explicativa) ou então, impedir a visualização destes menus para o usuário, pois são funções distintas que servem apenas para guias de atendimento.
    3. A ação deste bloqueio ou ocultação de menus é para evitar transtornos cos usuários e evitar enganos.

Observações Importantes:

1. Devido à complexidade da tarefa, será necessário também analisar e testar outros fontes pertinentes a auditoria, para verificar o pleno funcionamento da auditoria genérica.
2. Caso seja necessário, deverá ser mudado índices, para comportar novas formas de chave única e evitar erros de duplicação ou não salvamento das operações.
3. O desenvolvedor terá que criar uma forma de testar a funcionalidade e deverá ser replicado esta maneira para o departamento de SQA, para que possam testar a funcionalidade (RdMake).

(Obrigatório)

Definição da Regra de Negócio

<Regra de negócio é o que define a forma de fazer o negócio, o processo definido e/ou as regras que devem ser contempladas. Devem ser descritas restrições, validações, condições e exceções do processo. Caso necessário, incluir neste capítulo também regras de integridade que devem ser observadas no momento do desenvolvimento>.

<Na tabela abaixo informe quais são as rotinas envolvidas, o tipo de operação, a opção de menu e se necessário uma breve descrição das regras de negócio relacionadas a rotina>.

Exemplo de Aplicação:

• Criar o campo “% Mínimo Espécie” (AAA_PERESP) onde o usuário informará o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação.
• Criar o campo “Referência Mínima para Cálculo” (AAA_REFCAL) onde o usuário informará um dos 4 valores disponíveis para pagamento das mensalidades  como a referência mínima para calcular o débito total do aluno.
• Criar o parâmetro MV_ACPARNE que definirá se as informações de “% Mínimo Espécie” e “Referência Mínima para Cálculo” serão obrigatórias.
• O parâmetro MV_ACPARNE deve ter as seguintes opções: 1=Obrigatório e 2=Opcional. Deve ser inicializado como opcional>.

Tabelas Utilizadas

Tabelas Utilizadas

• B53 – Auditoria por Guias.
• B72 – Interna Saúde.

Observação
Em consonância com as melhores práticas de programação e necessidades no desenvolvimento do requisito, poderão ser incluídos mais fontes ou outras funções de apoio e consulta, para executar da melhor maneira possível o proposto neste documento. 

Opcional

Protótipo de Tela

<Caso necessário inclua protótipos de telas com o objetivo de facilitar o entendimento do requisito, apresentar conceitos e funcionalidades do software>.

Protótipo 01

Opcional

Fluxo do Processo

<Nesta etapa incluir representações gráficas que descrevam o problema a ser resolvido e o sistema a ser desenvolvido. Exemplo: Diagrama - Caso de Uso, Diagrama de Atividades, Diagrama de Classes, Diagrama de Entidade e Relacionamento e Diagrama de Sequência>. 

Opcional

Dicionário de Dados

Arquivo ou Código do Script: AAA – Negociação Financeira / *Versao=CP.2014.12_03*/

(Opcional)

Grupo de Perguntas

<Informações utilizadas na linha Protheus>.

Nome: FINSRF2

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

Consulta: AMB

(Opcional)

Estrutura de Menu

<Informações utilizadas na linha Datasul>.

Procedimentos

Programas

Cadastro de Papéis

<O cadastro de papéis é obrigatório para os projetos de desenvolvimento FLEX a partir do Datasul 10>.

<Lembrete: o nome dos papeis em inglês descrito neste ponto do documento, devem ser homologados pela equipe de tradução>.