business-rule3.md

Business Rules - Service request

Neste documento será apresentado a regra de negócio relacionada às entidades de solicitação de serviço que devem ser aplicadas no sistema Keepfy.

O Campo de branch define o registro de maneira que em todas as entidades JAMAIS deve ser alterado.

---

Solicitação de Serviço

• Abertura

  • Campo branch é obrigatório e possui relacionamento com a tabela saas.branch, seu conteúdo deve existir na coluna id da tabela
  • Campo id é obrigatório e seu conteúdo deve ser único
  • Campo code obrigatório, devendo ser sequencial com tamanho de 6 (seis) dígitos e alfanumérico
  • Campo equipment não é obrigatório e possui relacionamento com a tabela mnt.equipments , seu conteúdo, se preenchido deve existir na coluna id da tabela de acordo com a branch do registro
  • Campo description é obrigatório armazenando a descrição da ocorrência
  • Campo status é obrigatório e deve possuir o conteúdo como 'awaiting-analysis' no processo de abertura
  • Campo requester é obrigatório e possui relacionamento com a tabela saas.user, seu conteúdo deve existir na coluna id da tabela de acordo com a branch do registro
  • Campo observation deve ser null no processo de abertura
  • Campo priotity deve ser null no processo de abertura
  • Campo running_time deve ser null no processo de abertura
  • Campo cancellation_reason deve ser null no processo de abertura
  • Campo service_order deve ser null no processo de abertura
  • Campo satisfaction_survey deve ser null no processo de abertura
  • Campo employee deve ser null no processo de abertura

  O processo de abertura de Solicitação de serviço deve realizar um novo registro na tabela de followup_request com os seguintes dados:

  • Campo id é obrigatório e deve ser único
  • Campo branch é obrigatório e possui relacionamento com a tabela saas.branch, seu conteúdo deve existir na coluna id da tabela e ser a mesma do registro da service_request que gerou este registro
  • Campo service_request é obrigatório e possui relacionamento com a tabela mnt.service_request, seu conteúdo deve existir na coluna id da tabela de acordo com a branch do registro
  • Campo status é obrigatório e deve possuir o conteúdo como 'awaiting-analysis' quando gerado pelo processo de abertura
  • Campo update_date é obrigatório e deve possuir a data atual do sistema indicando a criação do registro no formato 'YYYY-MM-DD'
  • Campo update_hour é obrigatório e deve possuir a hora atual do sistema indicando a criação do registro no formato 'HH:mm'
  • Campo description é obrigatório com o seguinte formato 'Abertura da solicitação de serviço #'Número do Código' realizada pelo usuário 'Nome do Solicitante'.'
  • Campo type é obrigatório e deve possuir o seu conteúdo como 'event'
  • Campo uploaded_by é obrigatório e possui relacionamento com a tabela saas.user, seu conteúdo deve existir na coluna id da tabela de acordo com a branch do registro, e deve ser o mesmo informado da coluna requester da solicitação de serviço que gerou este registro

  O processo de abertura conta também com a possibilidade de anexos de imagens/ arquivos.

  Workflow: do processo de inclusão deve informar ao usuário solicitante que uma solicitação de serviço foi aberta e está pendente de mais ações. No e-mail deve apresentar os seguintes dados: código da SS, data e hora de abertura, equipamento (tag e descrição), nome do solicitante e a descrição da solicitação, além de um botão que permite acesso à direto à tela de edição.

  obs: O processo de abertura de Solicitação não gera quaisquer registros na tabela de satisfaction_survey ou service_order

• Alteração

  No processo de alteração segue as mesmas regras de validações do processo de abertura acima citado, com o diferencial de:

  • Campo equipment é alterável enquanto o status estiver como 'awaiting-analysis'
  • Campo description é alterável
  • Os demais campos não são alteráveis

  O processo de alteração da Solicitação de serviço deve realizar um novo registro na tabela de followup_request com os seguintes dados:

  • Campo id é obrigatório e deve ser único
  • Campo branch é obrigatório e possui relacionamento com a tabela saas.branch, seu conteúdo deve existir na coluna id da tabela e ser a mesma do registro da service_request que gerou este registro
  • Campo service_request é obrigatório e possui relacionamento com a tabela mnt.service_request, seu conteúdo deve existir na coluna id da tabela de acordo com a branch do registro
  • Campo status é obrigatório e deve possuir o conteúdo como 'update-service-request' quando gerado pelo processo de alteração
  • Campo update_date é obrigatório e deve possuir a data atual do sistema indicando a criação do registro no formato 'YYYY-MM-DD'
  • Campo update_hour é obrigatório e deve possuir a hora atual do sistema indicando a criação do registro no formato 'HH:mm'
  • Campo description é obrigatório e deve indicar as alterações contidas neste determinado processo como exemplo, o seguinte formato 'Usuário 'Nome do Usuário' alterou a descrição da ocorrência 'descrição anterior' por 'descrição nova.'
  • Campo type é obrigatório e deve possuir o seu conteúdo como 'event'
  • Campo uploaded_by é obrigatório e possui relacionamento com a tabela saas.user, seu conteúdo deve existir na coluna id da tabela de acordo com a branch do registro

  Ainda neste mesmo processo é possível a criação de comentários manuais na solicitação de serviço, que devem ser criados com a mesmas regras acima citadas com a diferença de:

  • Campo type é obrigatório e deve possuir o seu conteúdo como 'comment'
  • Campo description é obrigatório não podendo ser vazio e ser informado manualmente pelo usuário.

  No processo de abertura também é possível a inclusão/ alteração e remoção de anexos de imagens/ arquivos. ** (Hoje ainda não implementado em nenhuma entidade)

• Finalização

  Segue as mesmas regras nos demais campos, com o diferencial:

  • Campo status é obrigatório e deve possuir o conteúdo como 'satisfaction'
  • Só é possível a finalização de uma SS quando ela já estiver sido distribuída e já não estiver finalizada/ cancelada ou respondida

  O processo de finalização de Solicitação de serviço deve realizar um novo registro na tabela de followup_request com os seguintes dados:

  • Campo id é obrigatório e deve ser único
  • Campo branch é obrigatório e possui relacionamento com a tabela saas.branch, seu conteúdo deve existir na coluna id da tabela e ser a mesma do registro da service_request que gerou este registro
  • Campo service_request é obrigatório e possui relacionamento com a tabela mnt.service_request, seu conteúdo deve existir na coluna id da tabela de acordo com a branch do registro
  • Campo status é obrigatório e deve possuir o conteúdo como 'finished' quando gerado pelo processo de finalização
  • Campo update_date é obrigatório e deve possuir a data atual do sistema indicando a criação do registro no formato 'YYYY-MM-DD'
  • Campo update_hour é obrigatório e deve possuir a hora atual do sistema indicando a criação do registro no formato 'HH:mm'
  • Campo description é obrigatório com o seguinte formato 'Atendimento e finalização da SS #'Número do Código' realizada pelo usuário 'Nome do Executante'.'
  • Campo type é obrigatório e deve possuir o seu conteúdo como 'event'
  • Campo uploaded_by é obrigatório e possui relacionamento com a tabela saas.user, seu conteúdo deve existir na coluna id da tabela de acordo com a branch do registro

  Workflow: do processo de finalização, destinado a informar ao usuário solicitante e executante que a solicitação foi atendida. Deve apresentar as informações separadas em duas partes, a primeira referente ao processo de encerramento: data e hora de finalização, duração e descrição da solução; e a segunda com informações gerais sobre a SS: código da SS, data e hora de abertura, equipamento (tag e descrição), nome do solicitante e descrição da solicitação.

• Cancelamento

  Segue as mesmas regras de abertura nos campos, com o diferencial:

  • Campo cancellation_reason é obrigatório e possui relacionamento com a tabela mnt.reason, seu conteúdo deve existir na coluna id da tabela de acordo com a branch do registro
  • Campo observation não obrigatório mas pode ser preechido
  • Campo status é obrigatório e deve possuir o conteúdo como 'canceled'
  • Só é possível o cancelamento de uma SS quando ela não estiver sido finalizada ou respondida
  • Não é possível cancelar uma SS caso já exista uma ordem de serviço vinculada a mesma com a situação divergente de cancelada ou terminada

  O processo de cancelamento de Solicitação de serviço deve realizar um novo registro na tabela de followup_request com os seguintes dados:

  • Campo id é obrigatório e deve ser único
  • Campo branch é obrigatório e possui relacionamento com a tabela saas.branch, seu conteúdo deve existir na coluna id da tabela e ser a mesma do registro da service_request que gerou este registro
  • Campo service_request é obrigatório e possui relacionamento com a tabela mnt.service_request, seu conteúdo deve existir na coluna id da tabela de acordo com a branch do registro
  • Campo status é obrigatório e deve possuir o conteúdo como 'canceled' quando gerado pelo processo de cancelamento
  • Campo update_date é obrigatório e deve possuir a data atual do sistema indicando a criação do registro no formato 'YYYY-MM-DD'
  • Campo update_hour é obrigatório e deve possuir a hora atual do sistema indicando a criação do registro no formato 'HH:mm'
  • Campo description é obrigatório com o seguinte formato Cancelamento da solicitação de serviço #'Número do Código' realizada pelo usuário 'Nome do Usuário'.'
  • Campo type é obrigatório e deve possuir o seu conteúdo como 'event'
  • Campo uploaded_by é obrigatório e possui relacionamento com a tabela saas.user, seu conteúdo deve existir na coluna id da tabela de acordo com a branch do registro

  Workflow: do processo de cancelamento, utilizando o e-mail do usuário solicitante enviar workflow informando que a solicitação foi cancelada. Enviar o mesmo e-mail ao atendente, caso a solicitação de serviço já tiver um atendente alocado (no caso de ser o mesmo usuário, mandar apenas um e-mail).

• Distribuição

  Segue as mesmas regras de abertura nos campos, com o diferencial:

  • Campo equipment é obrigatório
  • Campo employee é obrigatório e possui relacionamento com a tabela mnt.employee, seu conteúdo deve existir na coluna id da tabela de acordo com a branch do registro
  • Campo priority é obrigatório e seu conteúdo deve conter 'low', 'medium' ou 'high'
  • Campo status é obrigatório e deve possuir o conteúdo como 'distributed'

  O processo de distribuição de Solicitação de serviço deve realizar um novo registro na tabela de followup_request com os seguintes dados:

  • Campo id é obrigatório e deve ser único
  • Campo branch é obrigatório e possui relacionamento com a tabela saas.branch, seu conteúdo deve existir na coluna id da tabela e ser a mesma do registro da service_request que gerou este registro
  • Campo service_request é obrigatório e possui relacionamento com a tabela mnt.service_request, seu conteúdo deve existir na coluna id da tabela de acordo com a branch do registro
  • Campo status é obrigatório e deve possuir o conteúdo como 'distributed' quando gerado pelo processo de distribuição
  • Campo update_date é obrigatório e deve possuir a data atual do sistema indicando a criação do registro no formato 'YYYY-MM-DD'
  • Campo update_hour é obrigatório e deve possuir a hora atual do sistema indicando a criação do registro no formato 'HH:mm'
  • Campo description é obrigatório com o seguinte formato 'Distribuição da solicitação de serviço #'Código da SS' realizada pelo usuário 'Nome do Usuário' para o funcionário Marcos Ferreira.'
  • Campo type é obrigatório e deve possuir o seu conteúdo como 'event'
  • Campo uploaded_by é obrigatório e possui relacionamento com a tabela saas.user, seu conteúdo deve existir na coluna id da tabela de acordo com a branch do registro

  Workflow: do processo de distribuição deve ser destinado ao usuário solicitante e ao executante para quem a SS foi distribuída, apresentando dados em duas seções, na primeira as informações relativas à distribuição: executante, data e hora da distribuição e prioridade; e na segunda informações relativas à SS: cóodigo da SS, data e hora de abertura, equipamento (tag e descrição), nome do solicitante e descrição da solicitação. Quando a Solicitação é redistribuída, o WF deve ser enviado ao executante anterior e atual.

• Geração de Ordem de Serviço

  Neste processo, é informado os campos da OS validando-os com a regra de negócio de abertura dela.

  Somente pode ser gerada uma OS para uma solicitação de serviço com status como 'distributed'

  • Campo service_order é obrigatório, contendo o id da ordem de serviço criada

  • Campo status é obrigatório e deve ser atualizado com o conteúdo como 'distributed-with-so'

  O processo de geração de OS na solicitação de serviço deve realizar um novo registro na tabela de followup_request com os seguintes dados:

  • Campo id é obrigatório e deve ser único
  • Campo branch é obrigatório e possui relacionamento com a tabela saas.branch, seu conteúdo deve existir na coluna id da tabela e ser a mesma do registro da service_request que gerou este registro
  • Campo service_request é obrigatório e possui relacionamento com a tabela mnt.service_request, seu conteúdo deve existir na coluna id da tabela de acordo com a branch do registro
  • Campo status é obrigatório e deve possuir o conteúdo como 'distributed-with-so' quando gerado pelo processo de distribuição
  • Campo update_date é obrigatório e deve possuir a data atual do sistema indicando a criação do registro no formato 'YYYY-MM-DD'
  • Campo update_hour é obrigatório e deve possuir a hora atual do sistema indicando a criação do registro no formato 'HH:mm'
  • Campo description é obrigatório com o seguinte formato 'Abertura da O.S. 'Código da OS' para a solicitação de serviço #'Código da SS' realizada pelo usuário 'Nome do Usuário'.'
  • Campo type é obrigatório e deve possuir o seu conteúdo como 'event'
  • Campo uploaded_by é obrigatório e possui relacionamento com a tabela saas.user, seu conteúdo deve existir na coluna id da tabela de acordo com a branch do registro

  Workflow: do processo de geração de OS deve ser destinado a informar ao usuário solicitante que uma ordem de serviço foi aberta para realizar o atendimento da demanda originada na solicitação de serviço. Apresentar os dados segmentados em duas partes, a primeira referente a OS gerada: código da OS, equipamento (tag e descrição), serviço, motivo e previsão de início; e na segunda dados referentes a SS: código da solicitação de serviço, data e hora de abertura, equipamento (tag e descrição), solicitante e descrição.

• Pesquisa de Satisfação

  Para realização deste processo é necessário que solicitação de serviço possua o campo status como 'satisfaction'

  Segue as mesmas regras de abertura nos campos, com o diferencial:

  • Campo status deve ser atualizado com o conteúdo como 'finished'
  • Campo observation pode ser preechido sem quaisquer validações

  O processo de pesquisa de satisfação da solicitação de serviço deve realizar um novo registro na tabela de followup_request com os seguintes dados:

  • Campo id é obrigatório e deve ser único
  • Campo branch é obrigatório e possui relacionamento com a tabela saas.branch, seu conteúdo deve existir na coluna id da tabela e ser a mesma do registro da service_request que gerou este registro
  • Campo service_request é obrigatório e possui relacionamento com a tabela mnt.service_request, seu conteúdo deve existir na coluna id da tabela de acordo com a branch do registro
  • Campo status é obrigatório e deve possuir o conteúdo como 'finished' quando gerado pelo processo de pesquisa de satisfação
  • Campo update_date é obrigatório e deve possuir a data atual do sistema indicando a criação do registro no formato 'YYYY-MM-DD'
  • Campo update_hour é obrigatório e deve possuir a hora atual do sistema indicando a criação do registro no formato 'HH:mm'
  • Campo description é obrigatório com o seguinte formato 'Pesquisa de satisfação da SS #'Código da SS' respondida pelo usuário 'Nome do Solicitante'.'
  • Campo type é obrigatório e deve possuir o seu conteúdo como 'event'
  • Campo uploaded_by é obrigatório e possui relacionamento com a tabela saas.user, seu conteúdo deve existir na coluna id da tabela de acordo com a branch do registro, e deve ser o mesmo informado da coluna requester da solicitação de serviço que gerou este registro

  O processo de pesquisa de satisfação da solicitação de serviço deve realizar um novo registro na tabela de satisfaction_survey com os seguintes dados:

  • Campo id é obrigatório e deve ser único
  • Campo branch é obrigatório e possui relacionamento com a tabela saas.branch, seu conteúdo deve existir na coluna id da tabela e ser a mesma do registro da service_request que gerou este registro
  • Campo deadline_evaluation é obrigatório e seu conteúdo deve conter 'great', 'good', 'satisfactory' ou 'bad'
  • Campo covering_evaluation é obrigatório e seu conteúdo deve conter 'great', 'good', 'satisfactory' ou 'bad'
  • Campo deadline_quality é opcional sem validações
  • Campo assistance_quality é opcional sem validações
  • Campo observation é opcional sem validações

  Workflow: do processo de pesquisa de satisfação deve ser destinado a enviar o link para a pesquisa de satisfação ao usuário solicitante. Como é enviado ao mesmo tempo do workflow de encerramento da SS, não é necessário incluir muitos detalhes, apenas data e hora de finalização, duração e a descrição da solução adotada.

• Exclusão

  • Não é possível realizar a exclusão de uma solicitação de serviço no sistema atualmente

---