(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

Permitir ao usuário consultar as tarefas destinadas a ele no Fluig e possa realizar a execução ou reagendamento da mesma. Podendo a execução ser de forma online ou offline.

(Obrigatório)

Definição da Regra de Negócio

Pré Requisitos.

  1 - Serviço "WSEXECBO" cadastrado no ambiente Fluig, apontando para o ambiente do ERP..

  2 - Ações das campanhas devem possuir workflow associado.

  3 - Etapa inicial do WorkFlow deve estar configurado para somente o usuário de integração executar a atividade (  datasul.framework.properties ).

  4 - Programa crm00397 cadastrado.

  5 - Haver uma agenda de execução para processos automáticos configurada no Fluig.

  6 - Usuários do CRM que serão responsáveis pelas tarefas estarem cadastrados no Fluig.

Restrições.

  Não serão enviadas atualizações para o fluig quando alterado os dados da conta que possuir tarefas abertas que estão integradas com Fluig. O único gatilho para enviar atualização para o fluig é realizando a alteração da tarefa.

  Não será permitido suspender uma tarefa quando integrada com o Fluig.

Associação do workflow a ação da campanha (Metadados).

  Alterar o programa de ações da campanha, adicionando o campo "Permite alterar a tarefa no CRM quando integrada com o Fluig?" (log_livre_1) , onde este campo terá o valor default igual a falso.

  Alterar o programa de ações da campanha, adicionando o campo "Obriga coleta coordenada GPS" (log_livre_2) , onde este campo terá o valor default igual a falso.

  Este campo deve ficar visível somente para as ações que possuem um workflow associado.

  Este campo tem por objetivo permitir que as tarefas que possuem integração com o Fluig sejam ser alteradas dentro do CRM.

  Realizar manutenção no programa que apresenta os workflows que podem ser associados a ação da campanha, a manutenção a ser realizada é para que não faça mais a leitura dos parâmetros do CRM ( usuário, senha, ip servidor do fluig), estes parâmetros devem ser obtidos da api de integração (utp/ut-integra-ecm), afim de manter os parâmetros de integração com o Fluig em um único ponto.

WorkFlow

  Neste momento iremos detalhar a construção do Workflow e seus eventos.

  Construir um diagrama de workflow seguindo o protótipo 01.

  Este diagrama é composto por algumas etapas que possuem algumas regras:

  Etapa "Início".

    Esta etapa deve conter no mecanismo de atribuição o valor "Atribuição por Usuário" e informado o usuário que será utilizado para realizar a integração das tarefas do CRM com o Fluig, isto se faz necessário para que somente o usuário de integração tenha acesso para criação de novas solicitações baseado neste diagrama. ( sempre fazer uso do parâmetro configurado no "datasul_framework.properties" "ecm.integration.user.login").

  Etapa "Informações da Tarefa".  

    Esta etapa deve conter no mecanismo de atribuição o valor "Atribuição por Executor de Atividade" e configurado para a etapa seja sempre executada pelo usuário que executou a etapa. Esta configuração é necessária caso o usuário informe que deseja realizar o reagendamento da tarefa.

  Etapa "Validação". 

    Esta etapa deve conter duas condições de validação

      1 - Verificar se o input "method" possui o valor "reschedule" ou "result_finish_task"  possui o valor "false", se a condição for verdadeira a atividade deve retornar para a etapa "Informações da Tarefa".

      2 - Verificar se o input "method" possui o valor diferente de "reschedule", se a condição for verdadeira a atividade deve ser enviada para a etapa "transferência de anexos gerados para o CRM".

  Etapa "Fim". 

    Esta etapa finaliza a pendência que estava disponível para o usuário.

  propriedades do workflow

  Eventos do workflow

    "afterStateEntry" - Este evento será responsável por setar o prazo da atividade que acaba de ser criada, o evento deverá executar o método disponibilizado pelo Fluig (setDueDate) para setar o prazo data/hora da Atividade. A execução da função setDueDate deve ser realizada somente quando a pendência estiver entrando na etapa "Informações da Tarefa". Quando a atividade tiver sendo reagendada via fluig, o valor para ser passado para o "setDueDate" deve ser pego dos campos que foram informados pelo usuário ( data início / hora início ), caso contrário o valor deve ser pego do modelo de tarefa ( data início / hora início ).

                                  Este evento também será responsável por informar o CRM que a atividade possui anexos,o evento deverá realizar a validação sobre o input "method" para validar se a alteração da atividade foi realizada por um reagendamento ou checkin, caso a condição seja verdadeira, deve-se executar o método "downloadAttachmens" da "fch/fchcrm/fchcrm2001.p" passando como parâmetro o id da tarefa.

    "beforeStateEntry"  - Este evento será responsável por enviar ao CRM os dados de reagendamento e checkin. Este evento deve acessar o input "method" e verificar qual ação foi realizada pelo usuário para então realizar a chamada ao método correspondente no CRM. 

               se "method" for igual a reagendamento,  deve-se enviar para o programa fchcrm2001.p "rescheduleCRMTask" os dados que foram informados pelo usuário no momento do reagendamento. Dados este como data início/hora início, Data fim/hora fim e observação.

               se "method" for igual a check-in,  deve-se enviar para o programa fchcrm2001.p "executeCRMTask_1" os dados que foram informados pelo usuário no momento da execução da tarefa. Dados este como resultado, observação e dados de próximas ações

      As chamadas aos programas do CRM devem ser realizadas fazendo uso do serviço WSEXECBO, sempre autenticando com o usuário logado.

  Eventos do formulário

    "displayFields" - Este evento será responsável por inicializar as variáveis que serão utilizadas durante a execução da atividade.

    "inputFields" - Este evento será responsável por formatar as datas dos campos de reagendamento, nele é necessário realizar a formatação do valor presente no campo para o modelo correto "dd-mm-yyyy".

    "beforeSendValidate" - Este evento está declarado junto ao código do formulário, e será responsável por validar se os valores informados pelo usuário são os mínimos necessários para prosseguir com a operação. 
           1 - Não permitir que o processo seja enviado sem que o usuário tenha executado a ação de check-in ou reagendamento.

           2 - Quando executado o reagendamento

                   a - Os campos de data início, hora início, data fim, hora fim e observação devem estar preenchidos.

                   b - O campo data/hora não podem ser menor que a data/hora atual. 

           3 - Quando executado o check-in

                  a - Quando obriga registro de ação para executar tarefa, o campo de resultado e observação deve estar preenchidos.

                  b - Quando o resultado selecionado possuir próxima ação e dentre as ações houver algumas obrigatórias, todas elas devem ser preenchidas antes de enviar o processo adiante.

           Caso alguma das condições acima não forem atendidas, a operação deve ser abortada e uma mensagem deve ser apresentada ao usuário informando o motivo da atividade não ser enviada adiante.

Formulário do WorkFlow

  Criar um formulário para associação ao workflow de check-in check-out, este formulário terá os campos (ocultos) que irão ser usados para controle e também será utilizado para execução da tarefa.

  O formulário a ser construído deve seguir o protótipo 02, 03, 05, 06.

  O formulário html deve ser construído usando o style guide do fluig, afim de não ocorrer perda de formatação e incompatibilidade.

  O formulário deve ser construído com a técnica de consumo de informações dos campos omitidos que possuem as informações que serão apresentadas para o usuário realizar a operação.

  O formulário construído possui quatro sessões que são apresentadas de acordo com a operação realizada pelo usuário. Abaixo os detalhes de cada sessão.

     Sessão 01 - Detalhes da Tarefa

       Quando o usuário acessar a tarefa disponível ele irá ser posicionado na primeira sessão que possui todas as informações da tarefa criada para ele executar.

      Ao acessar esta sessão e a variável "is_gps_required" estiver com valor verdadeiro, deve-se tentar realizar a coleta da coordenada GPS, caso não haja sucesso, deve-se apresentar uma mensagem para o usuário que é obrigatória a coleta da localização para executar a tarefa e após isto bloquear os botões de reagendar/checkin.

       Os dados da tarefa estão divididos em grupos para facilitar a leitura.

       Grupo Dados Gerais

           Este grupo apresenta os dados que foram usados para gerar a tarefa:          

       Grupo Conta

           Este grupo apresenta os dados da conta selecionada na criação da tarefa:

           Para o campo de endereço, será apresentado o endereço de correspondência, ao lado do endereço haverá dois botões que irão permitir que o usuário abra o aplicativo de mapa ( google maps ou waze ).

           Para o campo de telefone, serão apresentados os telefones tipo telefone_erp1 e telefone_erp2 

       Grupo Contato

           Este grupo apresenta os dados da conta selecionada na criação da tarefa: 

           Para o campo de telefone, serão apresentados os telefones tipo telefone_erp1 e telefone_erp2. Ao clicar sobre o telefone, deve ser aberta a discadora do dispositivo móvel, porem isto deve ocorrer apenas quando o usuário estiver usando o mobile.

           Para o campo de e-mail, serão apresentados os dois e-mails que o contato possui. Ao clicar sobre o e-mail, deve ser aberta o programa de envio de e-mail do dispositivo móvel, porem isto deve ocorrer apenas quando o usuário estiver usando o mobile.

       Grupo Descrição

           Este grupo possui apenas um campo, campos este que irá apresentar o texto informado no momento da criação da tarefa.

       Grupo Tarefa Origem

           Este grupo apresenta os dados da tarefa origem, tarefa esta que foi usada para criação da nova tarefa no CRM.

           Este grupo será apresentado somente se a tarefa criada possuir uma tarefa origem associada a ela.

       Grupo Ocorrência

           Este grupo apresenta os dados da ocorrência origem, ocorrência esta que foi usada para criação da nova tarefa no CRM.

           Este grupo será apresenta somente se a tarefa criada possuir uma ocorrência origem associada a ela.

    Grupo Oportunidade. 

           Este grupo apresenta os dados da oportunidade origem, oportunidade esta que foi usada para criação da nova tarefa no CRM.

           Este grupo será apresenta somente se a tarefa criada possuir uma oportunidade origem associada a ela.

   Grupo Histórico de Ação. 

           Este grupo apresenta os dados do histórico de ação origem, Histórico este que foi usada para criação da nova tarefa no CRM.

           Este grupo será apresenta somente se a tarefa criada possuir um histórico origem associado a ela.

  Ações disponíveis para o usuário

   Nesta sessão o usuário terá duas opções:

    Reagendar

      Quando o usuário fizer uso da opção reagendar, ele deve ser direcionado para a tela (protótipo 03) que lhe permitirá informar os dados de reagendamento.

    Executar

      Quando o usuário fizer uso da opção executar, ele está dando início a execução da tarefa, neste momento deve ser coletada a coordenada GPS mais data/hora da execução para que possa ser utilizada na hora do registro da informação no CRM. Após isto deve ser encaminhado para a sessão de executar. caso a ação da tarefa indique que é obrigatória a coleta GPS, o usuário não poderá continuar a operação caso não fornecer sua localização.

 Sessão 02 - Reagendar

  A sessão deve seguir o protótipo 03.

  Nesta sessão estão todos os campos necessários para realizar o reagendamento da tarefa.

  Todos os campos são de preenchimento obrigatório.

  Sessão 03 - Executar

  A sessão deve seguir o protótipo 05.

  Ao clicar sobre a opção de executar, deve-se verificar se o parâmetro do CRM " deseja registrar uma ação para quitar a tarefa" não está ativo e então apresentar uma mensagem ao usuário informando que a tarefa pode ser finalizada, mas se o parâmetro estiver ativo, deve apresentar a tela para preenchimento dos dados do registro de ação ( protótipo 06 ).

  Ao selecionar o resultado, deve-se verificar se ele possui próximas ações, se possuir deve-se apresentar os demais campos para preenchimento das próximas ações.

  Acima dos campos de próximas ações deve-se apresentar o total de próximas ações e o total de próximas ações obrigatórias.

  Para confirmar a aproxima ação, o usuário deverá preencher todos os campos obrigatórios ( identificados com * ) e pressionar o botão salvar presente na base da tela. Após salvar a próxima ação o contador deverá ser atualizado, e a ação deve ser removida da lista de próximas ações.

  Abaixo a lista de campos disponíveis nesta sessão:

Lista Tarefa Criadas

 As tarefas criadas para o usuário serão apresentadas na central de tarefas do usuário e estas possuirão algumas informações de identificação do CRM.

Programas CRM

 Para enviar e receber os dados do Fluig, será necessário realizar ajustes nos programas do CRM, afim de usar um único programa de integração com o Fluig, para isto assumiremos que os novos programas do CRM de integração com o Fluig serão criados com a nomenclatura fchcrmZZZZapi.p, onde o ZZZZ deve ser substituído por números maiores que 2000.

  O programa "apiCrmIntegrTarEcm02.p" deve ser descontinuado, sendo assim, todos os programas que acessavam seus métodos devem acessar os métodos do programa "fnd\utp\ut-integra-ecm.p", que é o programa oficial que possui os métodos de integração com o Fluig, pois este programa possui os tratamentos para conversão do usuário quando o identity está ativo.

  fchcrm2001

  Criar o programa fchcrm2001 que será responsável por integrar as tarefas do CRM com o Fluig, sendo o envio e o recebimento dos dados.

  Para enviar os dados de tarefa para o Fluig, deve-se criar a procedure sendTaskECM_1 que será responsável pela seleção e envio dos dados para o fluig. Como parâmetros de entrada do método, ele deve receber o id da tarefa, operação ( insert, update, delete ) para que seja possível enviar os dados para o fluig de forma correta.

  Quando a operação for:

      Insert

          Nesta situação devem ser coletados os dados da tarefa juntamente com os dados origens da tarefa e então montar o cardData que deverá ser enviado ao Fluig.

          Caso a tarefa possua anexos, eles devem ser adicionados ao cardData.

          Após gerado o conteúdo do cardData, deve-se executar a chamada ao método de criação da pendencia no Fluig ( método do programa ut-integra-ecm ), lembrando que a pendencia deve ser criada e após sua criação ela deve ficar disponível na etapa de tarefa. 

          Como a pendencia que está sendo criada está configurada para que apenas um usuário possa iniciar o processo, o usuário de criação da atividade deve ser o usuário de integração que está configurado no arquivo datasul.framework.properties.

           Caso ocorra algum erro no processo de criação da pendencia no Fluig, deve ser criado um registro na tabela "crm_log_integr_fluig" com o id da tarefa caso não exista um registro com o mesmo id da tarefa. No registro adicionado estará descrito o motivo do erro, usuário que executou a tarefa, data/hora da geração do erro e outros dados. Após criar o registro, deve-se criar uma pendencia de execução no RPW para a tarefa  que acabou de gerar o erro de integração, onde este agendamento que será criado para o programa crm00397 será responsável por realizar o envio das tarefas que geraram erro para o Fluig. Lembrando que a pendencia no RPW deve ser criada para o servidor RPW que está associado ao usuário logado.

      Update

           Quando a operação for update, devemos verificar se o parâmetro "l_only_card_data" está ativo, se ele estiver ativo devemos enviar os dados para o Fluig atraves do método "updateCardDataECM" presente no programa ut-integra-ecm. Este deve ser o caminho a ser utilizado para que caso a tarefa no fluig esteja em uso por algum processo, os dados sejam atualizados com sucesso. Caso o parâmetro esteja inativo devemos enviar os dados através do método "saveAndSendTaskECM" presente no programa ut-integra-ecm. Porem quando a tarefa estiver  com status fechado, devemos informar ao método saveAndSendTaskECM que a tarefa deve ser movimentada para próxima etapa.

      Delete

            Não realizar operação.

  Para o recebimento dos dados do Fluig, deve-se criar a procedure executeCRMTask_1 que será responsável pela execução da tarefa e a criação das próximas ações caso existam.

  Ao processar os dados enviados do Fluig, verificar se os dados de histórico de ação foram preenchidos, se sim então deve-se gerar o histórico de ação e em seguida criar as próximas ações caso elas tenham sido informadas no Fluig. Caso os dados do histórico de ação não tenham sido preenchidos no Fluig, deve-se quitar a tarefa.

   Obs. Durante a criação das próximas ações que foram geradas a partir da integração do Fluig com o CRM, não deve ser validado a data de início da tarefa, pois uma vez que o usuário gere essa tarefa de forma off-line e envie os dados para o servidor depois da data início informada nas tarefas criadas, a validação iria abortar todo o registro realizado por ele.

   Caso ocorra erro de negócio ou de programa durante a execução das rotinas acima, deve-se popular a row-error e retornar ela para o Fluig.

  Para o recebimento dos anexos do Fluig, deve-se criar o método downloadAttachments que irá receber o id da tarefa CRM e o usuário responsável pela atividade, ao receber o id da tarefa do CRM, deve-se verificar se atividade possui workflow associado, caso exista realizar o download de todos os anexos existentes na atividade do fluig. ao receber os anexos devem ser verificados se os mesmos já estão disponíveis na tarefa do CRM, se tiverem devem ser ignorados, caso contrário devem ser adicionados a tarefa do CRM. Obs. ao solicitar os anexos do fluig, deve ser passado como parâmetro o usuário que foi enviado do fluig, caso contrário, não serão localizados os anexos.

Rotina

Tabelas Utilizadas

Opcional

Protótipo de Tela

 Protótipo 01

Protótipo 02

 Protótipo 03

Protótipo 04

Protótipo 05

Protótipo 06

Protótipo 07

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