TOTVS CRM Automação da Força de Vendas
Linha TOTVS CRM
| Produto: | TOTVS CRM Automação da Força de Vendas |
|---|---|
| Linha de Produto: | Linha TOTVS CRM |
| ERPs impactados: | Protheus, Datasul e ERPs terceiros |
| Módulo: | Agenda/Atendimento/ProjetoAgricola/Geração demanda(Visita) |
| Função: | Usabilidade |
| Ambiente: | Web/Android |
| Ticket: | 16542787 |
| Requisito/Story/Issue: |
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:
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.
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:
2.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 contará 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.
2.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:
O filtro de exibição de atendimentos será alterado para "Tipo atendimento", e será um campo separado do campo "Tipo agenda"
Os campos exibidos como filtro, serão, portanto:
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.
Por padrão, os registros trazidos em tela serão os vinculados com as entidades de filtros ativos (idnativo = 1), entretanto, na tela de pesquisa dos filtros, deve ter a possibilidade de visualizar os tipos inativos, ainda que sejam carregados os filtros ativos por padrão.
A tela alterada a partir dos pontos 2.1 e 2.2 pode ser visualizada pela figura a seguir:
| Antes | Depois |
|---|---|
|
|
2.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.
2.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:
2.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:
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.
2.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.
2.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:
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.
| Antes | Depois |
|---|---|
|
 |
2.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.2, será necessário existir os mesmos filtros partindo do ícone de "engrenagem"
A alteração tem como objetivo que possam ser exibidos atendimentos realizados também no ambiente Android.
Para atendimentos avulsos (sem agenda programada), pedidos e viagens, ao clicar 1x sobre o elemento de tela, impendentemente da visão, o sistema deverá enviar o usuário para a tela principal da entidade
2.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, o sistema encaminha o usuário para a tela de cabeçalho de visita, para que seja criada uma visita adicional.
No Android, o sistema abre a tela de cadastro de agenda de tipos de agenda genéricos, com os campos tradicionais da tela de cadastro de agenda.
Agora, o Android deverá encaminhar o usuário para a tela de cadastro de nova visita, como faz a Web, quando clicado para adicionar uma agenda do tipo "Visita de geração de demanda"
Dessa forma, contribuirá para os profissionais que quiserem realizar planejamento de visitas pelo Android, quando for necessário cadastrar visitas adicionais para uma demanda específica.
2.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:
Dessa forma, o sistema permitirá a alteração de data/hora prevista da visita por padrão. Mesmo que a visita não esteja visível, ao receber a mensagem de validação, o usuário poderá alterar o valor do campo "Visível" para "Sim" para poder executar a alteração desejada.
2.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:
Atualmente, para se realizar o lançamento de informações de uma visita de geração de demanda, é necessário acessar a visita através do módulo de "Geração de demanda".
Esse fluxo não é usual, pelo fato de que pode ser que um atendimento ao cliente não seja apenas para realizar ações de "Lado a lado" (tipo de demanda cadastrado). Normalmente se realiza também o cadastro de informações gerais de acompanhamento de cultura (projetos agrícolas).
Portanto, o sistema contará com uma alteração para que as visitas possam ser acessadas através do projeto agrícola, de modo que o "Lado a lado" é um processo de atendimento pertencente ao acompanhamento de cultura.
Dessa forma, a projeto agrícola receberá nova aba "Demanda" em que será possível associar demandas ao projeto agrícola através de botão "Associar demanda".
A partir da associação de demandas ao projeto agrícola, será possível interagir com as demandas e visitas com fluxo igual ao acesso das demandas pelo módulo de "Geração de demanda"
Com o propósito de termos informações de reforçar em tela se a visita foi executada dentro do prazo planejado, o sistema deverá ser alterado segundo os seguintes itens
Atualmente, ao clicar no botão "Realizar visita" o sistema persiste a informação de data de realização no banco, como informação interna, para entendimento se a visita foi realizada dentro ou fora do prazo.
Portanto, não era possível visualizar a data da realização (finalização) da visita na tela.
Ainda, o sistema não persistia a hora de realização, portanto, não era possível avaliar se as visitas dentro do prazo foram realizadas até a hora prevista de finalização.
Dessa forma, o sistema deverá adicionar a informação de data e hora de realização nas seguintes telas:
A hora da realização da visita é campo que deverá ser criado pelo tools opção 5, campo textual para horário (varchar(8)), nullable
Ao clicar em realizar visita, persistir com data e hora atuais, por padrão.
Atualmente, a tela de visita não possui seus campos passíveis de configuração.
Para garantir que a data e hora da realização sejam editáveis, deve haver configuração para esse fim.
Cadastro de validação de -X dias.
Quando preenchidos os campos na tela, o sistema deverá confirmar se o usuário deseja finalizar a visita.
No Android,
Comportamento envolvido por novo parâmetro "Exigir atendimento para realização de visitas de geração de demanda" (novo parâmetro da tela Configurar atendimento > Configurações do Mobile) {
Ao acessar uma visita não realizada pelo módulo de agenda, caso não existam atendimentos correntes ao cliente, o sistema deverá obrigar o usuário a iniciar um atendimento.
Ao clicar em "realizar visita", o sistema deverá abrir a seguinte tela:
O campo de data inicio e hora inicio devem aparecer mediante configuração do parâmetro "Editar data e hora do atendimento", na tela Configurar atendimento > Configurações do Mobile.
Caso os campos não estiverem visíveis, o sistema deve iniciar o atendimento com data e hora correntes.
Caso o parâmetro "Bloquear novo atendimento, caso tenha atendimentos iniciados e não finalizados" estiver marcado, o sistema deverá validar se o horário informado conflita com outros atendimentos do profissional no dia. Se sim, mostrar qual atendimento conflitou e e validar exigindo outro horário de início.
Ao sair da tela de visitas, caso a tela não seja a visão 360 do cliente, o sistema deve mostrar a seguinte tela:
O campo de data fim e hora fim devem aparecer mediante configuração do parâmetro "Editar data e hora do atendimento", na tela Configurar atendimento > Configurações do Mobile.
Não será possível marcar data e hora fim superiores à data e hora atuais
}
Comportamento envolvido por parâmetro "Exigir atendimento para adição/alteração de dados de projeto agrícola" (novo parâmetro da tela Configurar atendimento > Configurações do Mobile) {
Antes de realizar uma ação de persistência de dados de projetos agrícolas (arquivo para pasta alterado) , caso não existam atendimentos correntes ao cliente, o sistema deverá exigir que o usuário inicie um atendimento. Nesse caso sistema deverá abrir a seguinte tela:
O campo de data inicio e hora inicio devem aparecer mediante configuração do parâmetro "Editar data e hora do atendimento", na tela Configurar atendimento > Configurações do Mobile.
Caso os campos não estiverem visíveis, o sistema deve iniciar o atendimento com data e hora correntes.
Caso o parâmetro "Bloquear novo atendimento, caso tenha atendimentos iniciados e não finalizados" estiver marcado, o sistema deverá validar se o horário informado conflita com outros atendimentos do profissional no dia. Se sim, mostrar qual atendimento conflitou e e validar exigindo outro horário de início.
}
A visualização da agenda em lista deverá conter filtro de período, com data inicial e data final.
Dessa forma, não serão exibidos todos os registros de agenda, mas sim os determinados pelo filtro de data.
Por padrão, o sistema deverá exibir apenas agendas cujas datas inicial ou final sejam maiores ou iguais à data atual.
A visualização da agenda em lista deverá possuir botão para exportação da grid em formatos XLS ou CSV, como acontece atualmente com a grid da listagem de atendimentos, por exemplo.
Na tela de agenda, o sistema deverá esconder alguns elementos de tela baseado na permissão de visualização do perfil de acesso do usuário logado, sendo:
Na ação de "realizar visita", caso a data planejada da visita estiver maior que a data atual, o sistema deverá exibir tela de validação, com as seguintes informações.:
O sistema deverá contar com nova regra de perfil de acesso, sendo:
Por padrão essa regra deverá vir não selecionada.
Quando o profissional logado contiver essa permissão, os campos da visita deverão estar abertos para edição, e o botão gravar deverá estar habilitado para clique.
Ao clicar em gravar, o sistema deverá permanecer a visita como finalizada, entretanto realizar as persistências das alterações da tela.
Dentro da visão 360 do Android, deverá existir aba "AGENDA" que exibirá o mesmo conteúdo do módulo Agenda, porém com a marcação com ícone de "estrela" nas agendas relacionadas com o cliente da tela em questão.
Dentro da visão 360 do Android, deverá existir aba "Demanda" que exibirá o mesmo conteúdo do módulo de geração de demanda, porém com demandas e visitas filtradas para o cliente da tela em questão.
