Histórico da Página

(Obrigatório)

Informações Gerais

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

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

Permitir que seja possível configurar os atendentes que terão a integração com o horário através da agenda efetiva no local de atendimento ou então que seja considerado a marcação automática do módulo SIGAGPE.

Definição da Regra de Negócio

Para a realização de prestação de serviços, existem atendentes que realiza uma jornada de trabalho fixa, porém a alocação nos postos é realizada de forma muito dinâmica pois em um mesmo dias estes atendentes são alocados em diversos postos de trabalho e nem sempre este horário realizado representa o horário de trabalho do atendente, como é o caso de atendente que realiza a cobertura de almoço, janta e até mesmo atendentes que ficam na reserva.

CADASTRO DE ATENDENTES

Será criado novo campo no cadastro de atendentes para que possa ser configurado o “tipo de envio de marcação” (Protótipo 1), onde terá as seguintes opções:

• Agenda – Será considerado os horários da agenda do atendente para o envio de marcação e para o calendário do módulo SIGAPON.
• Funcionário – Será considerado o horário padrão do turno configurado no cadastro de funcionários do módulo de Gestão de pessoal (SIGAGPE) e será considerada as faltas conforme manutenções realizadas na agenda do atendente do módulo Gestão de Serviços (SIGATEC).

GERAÇÃO DE MARCAÇÕES

Ao ser executado o processamento de envio de marcação de atendentes através da rotina de geração de marcações, será verificado a configuração do campo “Tipo de envio de marcação” observando as seguintes regras:

Configurado como “agenda”:

Será realizado o processamento existente atualmente onde é enviada a marcação conforme os horários da agenda que o atendente realizou.

Configurado como “Funcionário”:

Será realizado o envio de marcações considerando o turno do funcionário, desta forma será enviado as marcações com o horário constante no horário padrão do funcionário. Não serão enviadas as marcações para os dias identificados como falta no módulo de Gestão de Serviços (SIGATEC).

Definição técnica

CADASTRO DE ATENDENTES – TECA020

No cadastro de funcionários (TECA020) incluir novo campo AA1_TIPMAR, conforme dicionário de dados.

ENVIO DE MARCAÇÕES – TECA910       

Para o processamento da rotina deverá ser consultado o campo AA1_TIPMAR, quando o campo estiver com valor “1” ou branco “”, deverá ser realizado o processamento já existente atualmente, onde são geradas as marcações conforme a agenda efetivada.

Caso o campo AA1_TIPMAR esteja com valor “2”, deverá ser realizado o envio de marcações conforme horário padrão configurado no cadastro de funcionários desconsiderando os dias identificados como falta nas agendas efetivadas do atendente para isso deverá ser realizado os seguintes procedimentos:

• Utilizar a função criaCalend para recuperar o calendário do funcionário no período

CriaCalend(<dDataIni>, <dDataFim>, <cTurno>, <cSeq>, <@aTabPadrao>, <@aTabCalend>, <cFilSR6>)

• Recuperar os dias das agendas com manutenções de falta no período, para isso será necessário consultar a agenda (ABB) que esteja com indicação de manutenção (ABB_MANUT == “1”), e assim verificar o tipo de manutenção de falta (ABN_TIPO == “01”). O Relacionamento entre ABB e ABN ocorrerá utilizando também a tabela ABR através dos campos ABB_CODIGO e ABR_AGENDA e então ABR_MOTIVO e ABN_CODIGO.

• Realizar a geração da marcação considerando os dias do calendário do funcionário e não enviar os dias que foram identificados como falta na agenda. Para a realização de envio de marcações deverá ser incluída novas linhas no array aRetorno da função At910GerMa, desta forma a rotina irá realizar o processamento de envio de marcações existente atualmente.

• O campo AB9_MPONTO deverá ser atualizado conforme função (At910AtAB9) para que se possa identificar que os atendimentos da agenda já foram processados. Ou seja, caso seja identificado um cenário que o atendente tenha no mesmo dia 3 agendas de cobertura de almoço (AG1 => 12:00 às 13:00, AG2=> 13:00 ás 14:00, AG3=>14:00 ás 15:00) e o horário do seu turno seja das 08:00 às 17:00, será gerada a marcação referente ao horário 08:00 às 17:00, e as 3 agendas referente a intervalo terá o conteúdo do campo AB9_MPONTO atualizado com a indicação que o processamento foi realizado.

Orientações

É indicado que seja consultado o campo AA1_TIPMAR na estrutura query chamada através da função At910Qry(), e adicionar o campo na estrutura do array retornado na função At910AProc() para posterior verificação da configuração do cadastro de atendentes.

RDMAKE PNMTABC01

No RdMake PNMTABC01 que realiza o processamento para que seja considerado o horário da agenda do atendente como o seu horário padrão, deverá ser realizado tratamento para que só seja executado quando a configuração do atendente indicar que o controle de marcação considere a agenda (AA1_TIPMAR == “1”)

Na rotina TrataAgenda, somente deverá ser considerada as agendas em que são do tipo trabalhada (Tipo = “S”)

If aAgenda[nPos][2][nI][AGENDA_TIPODIA] == "S"

//Gera Linha de acordo com a agenda, gerando limite de marcação na primeira entrada e ultima saida

                aAdd(aRows, GetRowByAg( aRow, aAgenda[nPos][2][nI], nI, .T., If(nI==1, .T., .F.)))

                aAdd(aRows, GetRowByAg( aRow, aAgenda[nPos][2][nI], nI, .F., If(nI==Len(aAgenda[nPos][2]), .T., .F.)))

EndIf

(Obrigatório)

<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

• AA1 – Atendentes
• ABB – Agenda
• ABN – Tipo de Manutenção
• ABR – Manutenção da agenda
• AB9 – Atendimento da Ordem de serviço
• SRA – Funcionário
• SR6 – Turno de Trabalho
• 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

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