Histórico da Página

Informações Gerais

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

Objetivo

Permitir que seja realizado o cadastro de restrições operacionais do atendente em determinados clientes ou locais de atendimento.

Definição da Regra de Negócio

 Para que seja possível realizar controle de restrições para a alocação dos atendentes em determinados clientes e/ou locais de atendimento, será criado nova rotina no menu (SIGATEC > Atualizações > Atendentes > Restrições). Ao acessar este menu serão listados os atendentes. Ao selecionar o atendente será possível realizar as devidas manutenções das restrições.

Neste cadastro será apresentado tela conforme Protótipo 1, Protótipo 2. Será apresentada aba para cliente e local de atendimento onde será possível realizar o cadastro da restrição para a respectiva entidade (Cliente / Local de atendimento). Para cada aba serão disponibilizados para preenchimento os seguintes campos:

• Identificação Cliente / Local de Atendimento: Será informado o código de identificação da entidade de acordo com a aba selecionada;
• Tempo: Será possível informar se a restrição é por um tempo determinado ou indeterminado;
• Data: Este campo será carregado por padrão com a data do sistema, indicando a data em que foi incluída a restrição;
• Data fim: Caso o campo “Tempo” esteja preenchido como indeterminado este campo ficará em branco. Caso esteja preenchido como “Determinado” deverá ser preenchida uma data superior a data atual do sistema;
• Tipo de Restrição: Neste campo será informado o tipo de restrição de “Aviso” ou “Bloqueio”. Para a restrição de aviso, ao realizar a alocação do atendente no cliente ou local será apresentado somente uma mensagem de alerta e poderá ser possível prosseguir com a alocação. Para a restrição de “Bloqueio” não será possível realizar a alocação do atendente;
• Observações: Neste campo poderá ser informado o motivo do cadastro de restrição do atendente;

Não será permitido incluir uma restrição para o atendente que possuir uma agenda ativa e não atendida no cliente/local em questão. Essa validação irá verificar somente agendas em datas superiores ou igual a data de início da restrição e inferior ou igual a data fim da restrição.

Na rotina de Grupo/Perfil de acesso, será incluída regra de permissão para realização das manutenções das restrições. Caso o grupo do usuário não estiver com a devida permissão este cadastro será aberto somente para visualização.

Na mesa operacional poderá ser acessado o cadastro de restrições por cliente ou local de atendimento. Serão apresentados os atendentes que possuem restrições para o cliente ou local de atendimento posicionado. (Protótipo 3, Protótipo 4).

Definição tecnica

Criar novos fontes e inclui-los no arquivo PRJ do módulo.

Deverá ser criado os seguintes fontes para cadastro das restrições:

• TECA012 – Cadastro de Restrições (Protótipo 1, Protótipo 2)
• TECA012A – Cadastro de Restrições por Cliente. (Protótipo 3)
• TECA012B – Cadastro de Restrições por Local de Atendimento. (Protótipo 4)

A codificação deverá utilizar o padrão MVC. Como os 3 cadastros irão utilizar a mesma tabela, funções de validações deverão ser chamadas a partir do dicionário de dados.

TECA560 TECA680 – GRUPO DE ACESSO/PERFIL

 Na rotina TECA680 deverá ser adicionada na estrutura de permissões (Variável estática aAcessoaPermissao), a nova opção “020” “021” com a descrição “Define Restrição Operacional?”.

TECA012 – CADASTRO DE RESTRIÇÕES

Criar novo menu SIGATEC > Atualizações > Atendentes > Restrições.

Ao acessar a rotina deverá ser listado os atendentes atendente (AA1).

Deverá ser disponibilizada os botões Manutenção e Visualização.

A opção de manutenção poderá ser acessada somente se o usuário logado possuir a permissão de Manutenção de Restrições (020021) do cadastro de “Grupo de Acesso/ Perfil”.

A opção de visualização poderá ser acessada por qualquer usuário.

Deverá ser apresentada tela de cadastro conforme Protótipo 1.

O campo TW2_TIPO não deverá ser apresentado em tela, pois será um controle para identificar o tipo de restrição por cliente ou local de atendimento. Assim ao ser preenchido as informações referente a aba de cliente este campo deverá ser salvo conforme opções (1=Cliente;2=Local de Atendimento)

O cabeçalho da tela deverá ser o código (AA1_CODTEC) e nome (AA1_NOME) do atendente posicionado no browser.

A grid da aba de clientes deverá ser a tabela TWSTW2, considerando o campo AA1_CODTEC e o campo TW2_TIPO = ‘1’

A grid da aba de Local de Atendimento deverá ser a tabela TWSTW2, considerando o campo AA1_CODTEC e o campo TW2_TIPO = ‘2’

Ao ser incluído um atendente na restrição deverá ser verificado se o atendente possui agenda no cliente ou local em questão. Deverá ser considerada agendas ativas (ABB_ATIVO = ‘1’) e não atendida (ABB_ATENDE = ‘2’) verificando sempre a agenda superior a data inicial da restrição. Caso o tempo de restrição seja determinado deverá ser verificado agendas dentro do período da restrição. Caso o tempo de restrição seja indeterminado deverá ser verificado agendas superior superiores a data inicial da restrição. Ao identificar a existência de agenda deverá ser apresentada mensagem “Atendente com alocação no período de restrição”.

Para verificar agenda para o local deverá ser considerado o campo ABB_LOCAL

Para verificar agenda para o cliente deverá ser considerado o campo ABS_CODIGO e ABS_LOJA. Para chegar na ABS através da Agenda (ABB) deverá ser utilizado o campo ABB_LOCAL

O campo TW2_DTFIM deverá ser habilitado para edição somente quando o campo TW2_TEMPO estiver como 2=Determinado.

Ao ser alterado o campo TW2_TEMPO para 1=Indeterminado deverá ser alterado o conteúdo do campo TW2_DTFIM para vazio.

TECA012A – CADASTRO DE RESTRIÇÕES POR CLIENTES

Deverá ser incluída nas “Outras opções” da rotina TECA190A (Mesa Operacional – Visão Contratos) a chamada para “Restrições do cliente” (TECA012BTECA012A)

Deverá ser criada rotina TECA012A conforme Protótipo 3.

O cabeçalho dessa tela deverá ser o cliente (SA1) do local de atendimento posicionado na grid da mesa operacional – Visão Contratos.

A Grid deverá ser as informações da tabela TW2, do respectivo cliente (TW2_CLIENT+TW2_LOJA).

Somente poderá editar as informações dessa tela o usuário que tiver permissão 020 cadastrada no Grupo/Perfil de Acesso (TECA560). Caso não tenha permissão a tela deverá ser aberta somente como visualização.

As regras e validações dos campos deverão obedecer o dicionário de dados.

TECA012B – CADASTRO DE RESTRIÇÕES POR LOCAL DE ATENDIMENTO

Deverá ser incluída nas “Outras opções” da rotina TECA190A (Mesa Operacional – Visão Contratos) a chamada para “Restrições do local de atendimento” (TECA012B)

Deverá ser criada rotina TECA012B conforme Protótipo 4.

O cabeçalho dessa tela deverá ser o local de atendimento posicionado (ABS) NA grid da mesa operacional – Visão Contratos.

A Grid deverá ser as informações da tabela TW2, do respectivo local de atendimento (TW2_LOCAL).

Somente poderá editar as informações dessa tela o usuário que tiver permissão 020 cadastrada no Grupo/Perfil de Acesso (TECA560). Caso não tenha permissão a tela deverá ser aberta somente como visualização.

As regras e validações dos campos deverão obedecer o dicionário de dados.

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

• SE2 – Cadastro de Contas a Pagar
• FI9 – Controle de Emissão de DARF>.

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

 Image Removed

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

Tabelas Utilizadas

• AA1 - Atendentes
• ABB - Agendas
• ABS – Local de Atendimento
• SA1 - Clientes
• TW2 – Restrições

Protótipo de Tela

Protótipo 01 – Restrições Aba Clientes

Image Added

Protótipo 02 – Restrições Aba Locais de Atendimento

Image Added

Protótipo 03 – Restrições Cliente

Image Added

Protótipo 04 – Restrições Local de Atendimento

Image Added

 Image Added

Dicionário de Dados

Arquivo ou Código do Script: TW2 – Restrições  

v

Gatilho

Relacionamento (X9)

Arquivo: TW2 - Restrições

(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>.