16542787 - Usabilidade projeto SFA

01. DADOS GERAIS

02. ESCOPO FUNCIONAL

Melhoria de usabilidade no SFA

Na versão atual do TOTVS CRM SFA, para o cenário de uso dos módulos "Agenda", "Atendimento", "Projeto agrícola" e "Geração de demanda(Visita)", não existe uma "amarração"
entre essas opções, o que dificulta o lançamentos dos dados, tendo em vista que é necessário acessar separadamente cada um dos módulos para fazer os registros,
o que torna a usabilidade do usuário final trabalhosa e um pouco repetitiva.

Para melhor a experiência do usuário, os módulos terão a oportunidade de receber vínculos entre si, para que, ao lançar um registro por exemplo no módulo "Agenda",
seja iniciado um "Atendimento", e com o atendimento iniciado, ser possível realizar manutenções nos "Projetos agrícolas", "Geração de demanda (Visitas)",
para que se possa atingir um fluxo de usabilidade unidirecional, sem haver a necessidade de alternância entre telas para o fluxo de atendimento padrão.

Para alcançar esse objetivo será necessário atender os seguintes itens:

Expansão/Colapso do cabeçalho do atendimento no Android

Visto que o objetivo é que atendimentos possam ser iniciados/finalizados a partir de agenda ou visitas, a visão 360 do Android receberá capacidade de melhor aproveitamento de tela, onde será possível colapsar (esconder) o cabeçalho de atendimento, como mostram as figuras a seguir:

Além disso, para evitar a quebra de linha do cabeçalho, ocupando espaço desnecessário, o nome do cliente (razão social e nome fantasia) será movimentado automaticamente.

Programação/Realização de atendimento a partir da tela de agenda

A tela de agenda, tanto na Web quanto no Android, receberá algumas alterações para que se possa realizar o planejamento/realização de atendimentos sem necessariamente precisar sair da tela, quando o atendimento não precisar de lançamentos específicos.

A fim de alcançar esse objetivo, serão atendidos os seguintes itens:

1. Descontinuação da aba resumo + dialog de visitas na Web

Na Web, a aba de resumo será descontinuada, para que a dialog exibida quando clicado uma vez sobre o elemento do calendário faça o papel de visualização rápida. Dessa forma, o sistema conterá sempre o mesmo comportamento, sendo uma tela para acesso à informações rápidas (acessada com 1 clique sobre o evento) e outra tela para informações completas (acessada com 2 cliques sobre o evento.

No Android, o sistema conterá com apenas a tela de visualização completa para visitas (acessada com 1 clique sobre o evento)

Portanto, o sistema conterá uma tela suspensa (dialog) ao clicar no evento do tipo "visita de geração de demanda", como acontece com outros tipos de evento (exceto atendimentos, pedidos e viagens)

Na tela de visualização rápida de visitas, será possível conferir os principais campos fixos do cabeçalho da visita. Entretanto, o intuito principal é que os campos de data e hora de planejamento sejam abertos para edição, quando a visita estiver em status agendado, para que se possa editar a data e a hora da agenda / visita sem sair da tela de agendamento, realizando assim o planejamento de visitas sem sair da tela.

A alteração da tela pode ser visualizada a partir das figuras a seguir:

2. Reposicionamento da configuração da agenda para o cabeçalho na Web

Com o objetivo de melhorar a experiência de quantidade de cliques e aproveitamento de tela na tela de agenda da Web, serão realizados os seguintes itens:

1. O menu "Configuração" será reposicionado para o cabeçalho da tela, sempre sendo exibido.

2. O filtro de exibição de atendimentos será alterado para "Tipo atendimento", e será um campo separado do campo "Tipo agenda"

3. O filtro de exibição de visitas de geração de demanda será alterado para "Tipo visita", e será um campo separado do campo "Tipo agenda"
4. Da mesma forma dos pontos 3 e 4, os filtros de pedidos e viagem serão novos campos "Tipo pedido" e "Tipo viagem"

O sistema contará com um novo parâmetro geral "sim3g.agenda.filtro.sem.selecao.todosregistros", que deverá ser criado pelo tools, opção 5.

Os valores dos filtros, quando não selecionados, caso o parâmetro "sim3g.agenda.filtro.sem.selecao.todosregistros" esteja com valor 1, trarão todos os registros das respectivas entidades no calendário.

Caso contrário, não exibirão nenhum registro da entidade em questão no calendário. 

A tela alterada pode ser visualizada pela figura a seguir:

3. Tipo agenda vinculado com tipo atendimento

No cadastro de tipo agenda, deverá ser possível selecionar um vínculo direto com "Tipo de atendimento".

Para esse fim, na tela de cadastro de tipo agenda, será adicionada coluna "Tipo atendimento", campo seleção, consultando os registros ativos de tipo de atendimento, exibindo a descrição na tela de busca.

O campo será persistido em tipoagenda.idtipoatendimento, campo FK para tabela tipoatendimento nullable que deverá ser criado pelo tools, opção 3.

4. Configuração de exibição de campos da agenda

O objetivo dessa seção é tornar a tela de agendamento mais simples, visto que não há a necessidade de utilizar muitos campos que atualmente estão sendo exibidos. Além disso, para agendas vinculadas com tipo de atendimento, é necessário que haja validação de obrigatoriedade para os campos profissional, parceiro e local, portanto, deverão ser cadastrados como obrigatórios.

Portanto, Na tela de Configuração > Cadastro > Agenda, deverá haver registros de código:

• "agenda", com os seguintes registros de campo:
  
  • descricao
  • data
  • hora
  • dataconclusao
  • horaconclusao
  • classificacao
  • idnimportante
  • situacao
  • profissional
  • profissional_multiplo
  • parceiro
  • parceiro_multiplo
  • local
  • localpromotora
  • contato_multiplo
  • qtdpartioutros
  • localrealizacao
  • pontogps
  • observacao
• "agendadespesa"
• "agendalembrete"
• "agendaimagem"
• "agendarecorrencia"

5. Abertura do campo "Participantes" para economia de cliques

A partir da configuração dos campos definidos pelo campo 4, o grupo de elementos "Participantes" não existirá mais, sendo substituído pelos campos diretos:

• profissional
  • Campo pesquisa de seleção única de profissionais ativos abaixo da hierarquia.
  • Persistido no campo agenda.idusuarioresponsavel
• profissional_multiplo
  • Campo pesquisa de seleção múltipla de profissionais ativos abaixo da hierarquia.
  • Persistido na tabela agendausuario
• parceiro
  • Campo pesquisa de seleção única de clientes da carteira do profissional logado e sua hierarquia direta
  • Persistido no campo agenda.idparceiro
• parceiro_multiplo
  • Campo pesquisa de seleção múltipla de clientes da carteira do profissional logado e sua hierarquia direta
  • Persistido na tabela agendaparceiro
• local
  • Campo pesquisa de seleção única de locais relacionados aos parceiros selecionados nos campos "parceiro" ou "parceiro_multiplo"
  • Persistido no campo agenda.idlocal
• contato_multiplo
  • Campo pesquisa de seleção múltipla de contatos relacionados à parceiros e locais selecionados nos campos "parceiro" ou "parceiro_multiplo" e "local"
• qtdpartioutros
  • Campo aberto para digitação numérica

Portanto, não será necessário clicar no botão "Adicionar participantes" na Web, como também o grupo de elementos retrátil "Participantes" no Android não existirá mais. Dessa forma, alguns cliques serão economizados no fluxo de usabilidade.

6. Dialog de visualização rápida sendo exibida em todas as visões de visita

Atualmente, na Web, para as agendas do tipo "visita de geração de demanda", o resumo de agendas somente é visualizado quando a visão do calendário está marcada como "Lista".

Visto que o resumo será substituído pela tela de visualização rápida, será alterado para que, mediante um clique na agenda, seja qual for o tipo da visão, a tela de visualização rápida seja carregada semelhantemente à visão "Lista", como acontece com outros tipos de agenda.

No Android, tanto 1 clique quanto 2 cliques devem levar o usuário diretamente para a tela da visita.

7. Dialog de visualização rápida para atendimentos ou agendas vinculadas à tipo atendimento

Além disso, o resumo atualmente não é exibido para atendimentos. Agora, o sistema deverá exibir a tela de visualização rápida tanto para atendimentos realizados sem agenda, como também para agendas vinculadas com tipo atendimento.

Para as agendas vinculadas com tipo de atendimento, deverão existir abas de nome:

• Planejado: Aba que exibirá campos de agendamento, conforme os campos exibidos atualmente
• Realizado: Aba que exibirá o resumo de atendimentos realizados ou iniciados, como também os botões de ação para interação com o atendimento sem sair da tela de agenda.
  • Para atendimentos já realizados serão exibidos, em condição não editável, os campos de:
    • • Profissional responsável
      • Outros profissionais
      • Cliente
      • Local
      • Tipo de atendimento
      • Contato
      • Data/hora início
      • Data/hora fim
      • Tempo
      • Justificativa
      • Observação
    • Além desses campos, será exibido o botão de ação:
      • Detalhes
        • Clicando sobre o botão, tal como clicar 2x sobre o elemento do evento no calendário, será aberta a tela do atendimento realizado (Histórico de atendimento)
  • Para atendimentos iniciados, porém ainda não finalizados serão exibidos, em condição não editável, os campos:
    • • Profissional responsável
      • Cliente
      • Local
      • Tipo de atendimento
      • Tempo
    • Em condição editável, os campos:
      • Contato
      • Outros profissionais
      • Data/hora início
      • Data/hora fim
      • Justificativa
      • Observação
    • Além desses campos, serão exibidos os botões de ação:
      • Detalhes
        • Clicando sobre o botão, tal como clicar 2x sobre o elemento do evento no calendário, será aberta a tela do atendimento na Web, e a visão 360 do cliente no Android, com o atendimento vinculado em estado corrente.
      • Gravar
        • Clicando sobre o botão, o sistema deverá gravar as informações dos campos editáveis alterados
      • Finalizar
        • Clicando sobre o botão, o sistema deverá finalizar o atendimento, exigindo justificativa caso esteja parametrizado dessa forma
  • Para registros de agenda sem atendimento ainda criado, o sistema deverá mostrar os campos em condição não editável:
    • • Profissional responsável
        • Deverá vir do campo "Profissional" da agenda
      • Cliente
        • Deverá vir do campo "Cliente" da agenda
      • Local
        • Deverá vir do campo "Local" da agenda
      • Tipo de atendimento
        • Deverá vir do campo "Tipo atendimento" vinculado ao tipo da agenda criada
    • Além dos campos acima, deverá mostrar os seguintes campos em estado editável:
      • Outros profissionais
      • Contato
      • Data/hora início
        • Ao lado do campo, deverá existir o botão "Iniciar" que, quando clicado, preencherá o campo data/hora inicio com a data/hora atual e gravará o atendimento.
      • Data/hora fim
      • Tempo
      • Justificativa
      • Observação
    • Além desses campos, serão exibidos os botões de ação:
      • Detalhes
        • Clicando sobre o botão, tal como clicar 2x sobre o elemento do evento no calendário, na Web será aberta a tela de novo atendimento com os campos não editáveis previamente preenchidos. No Android, deverá encaminhar para a tela de visão 360 com os campos não editáveis previamente preenchidos
          • Caso na tela de atendimento, o usuário alterar qualquer um dos campos Profissional, Cliente, Local ou Tipo atendimento, o sistema deverá exibir uma mensagem:
            • "Ao alterar o campo, o atendimento perderá o vínculo com a agenda planejada. Deseja prosseguir?" Sim/Não.
              • Se sim, o sistema deverá desassociar o atendimento à agenda, tratando as lógicas como um atendimento avulso.
              • Se não, o sistema deverá executar um rollback e voltar o campo para a seleção anterior.
      • Gravar
        
        • Dessa forma, o sistema deverá iniciar o atendimento com o horário informado no campo Data/hora inicio, gravando as informações preenchidas na tela.
          • Caso o campo data/hora início não estiver preenchida, o sistema deverá iniciar o atendimento com a data/hora de início atual.

Para atendimentos realizados sem vinculo de agenda, tanto 1 clique quanto 2 cliques devem levar o usuário para a tela de histórico de atendimentos.

PS: os atendimentos não finalizados não aparecerão no calendário sem registro de agenda vinculado.

8. Exibição de atendimentos no Android + filtros no Android

Atualmente, no Android, não são exibidos os atendimentos finalizados do profissional, como acontece na Web.

Além de atendimentos, os pedidos e viagens também devem aparecer no Android, por questão de completude do requisito.

Tal como o ponto 2, será necessário existir os filtros de "tipo atendimento", "tipo pedido" e "tipo viagem" partindo do ícone de "engrenagem"

A alteração tem como objetivo que possam ser exibidos atendimentos realizados também no ambiente Android.

9. Adição de "Visita geração demanda" pelo Android

Atualmente, existem comportamentos diferentes entre o sistema Web e Android quanto à adição de uma visita de geração de demanda adicional, ou seja, não criada automaticamente pela criação da demanda.

Na Web

10. Exibir "Sim" por padrão + Adição de campo "Visível" na tela de visita

Atualmente, no cabeçalho da visita, não existe o campo "Visível" apenas exibido na tela de demanda, através do botão do tipo "Switch".

Dessa forma, não é possível alterar a data e hora prevista da visita, recebendo a mensagem de "Não é possível editar, pois a visita não está visível."

Portanto, serão adotadas as seguintes alterações:

• O valor padrão do campo "Visível" será sim, tanto para visitas criadas pela criação da demanda, quanto para visitas adicionais.
• No cabeçalho da visita de geração de demanda, existirá o campo "Visível" editável quando a visita estiver com status "Agendada"

11. Obrigar informação de demanda na visita

No cabeçalho de visitas, o campo "Demanda" não é obrigatório.

Deverá ser possível configurar via Configuração > Cadastro > Visita, o registro de código DEMANDA, em que a coluna "Obrigatório" poderá ser selecionada como Sim/Não.

Caso seja cadastrada como Sim, o campo "Demanda" deverá ser informada para que o registro de visita seja criado.

Na busca dos registros do campo "Demanda", o sistema atualmente mostra apenas a descrição do "tipo demanda" da demanda em questão.

Deverão ser adicionadas novas colunas, para que se tenha clareza que qual é a demanda que se está selecionando, sendo eles:

• Data inicio (demanda.datainicio)

11. Atendimentos sendo abertos a partir de agenda

Na Web, além do resumo do atendimento na tela de agenda

Demandas/Visitas pertencente à projeto agrícola

Visitas sendo lançadas somente com atendimento corrente

Tipo visita vinculado com tipo atendimento

Atendimento corrente exibido no cabeçalho da Web

03. ESCOPO TÉCNICO