Mudanças entre as edições de "Cancelamento de Pedidos"

De GeoSales
Ir para navegação Ir para pesquisar
 
(9 revisões intermediárias por 2 usuários não estão sendo mostradas)
Linha 34: Linha 34:
  
  
* Todos os pedidos realizados na plataforma são registrados na tabela ACK_LOG_TABLE. Nesta tabela, todas as especificações de pendências são mostradas em vinculação com as chaves de pedidos. A tabela de registro dos bloqueios existentes é a TIPO_BLOC_PEDIDO_SIT.
+
* Todos os pedidos realizados na plataforma que integram com o modelo TJ tem o resultado do processo de integração registrados na tabela ACK_LOG_TABLE. Para as pendências de pedido, elas são vinculadas na tabela TIPO_BLOC_PEDIDO_REL. As pendência inseridas são descritas na tabela TIPO_BLOC_PEDIDO_SIT.
 
* É necessária criar uma pendência dentro da tabela TIPO_BLOC_PEDIDO_SIT, contemplando a situação deste cenário (Falha de Integração);
 
* É necessária criar uma pendência dentro da tabela TIPO_BLOC_PEDIDO_SIT, contemplando a situação deste cenário (Falha de Integração);
 
* Após a conclusão das tramitações normais do pedido (efetivação e aprovação), ele estará disponível para integração.  
 
* Após a conclusão das tramitações normais do pedido (efetivação e aprovação), ele estará disponível para integração.  
* Se a integração não ocorrer, deverá ser acionado um gatilho de retorno (trigger) para que este pedido fique com status de pendente, utilizando o bloqueio de situação criado na tabela TIPO_BLOC_PEDIDO_SIT.   
+
* Se a integração não ocorrer, deverá ser acionado um gatilho para que este pedido fique com status de pendente, utilizando a situação de bloqueio criada na tabela TIPO_BLOC_PEDIDO_SIT.   
 
* Além disso, deverá haver um retorno (feedback) para o usuário, informando que o seu pedido não foi integrado, e está novamente disponível no portal para revisão.  
 
* Além disso, deverá haver um retorno (feedback) para o usuário, informando que o seu pedido não foi integrado, e está novamente disponível no portal para revisão.  
 
* O pedido deverá estar disponível para edição e para cancelamento, caso seja a demanda do usuário.
 
* O pedido deverá estar disponível para edição e para cancelamento, caso seja a demanda do usuário.
* Feita as devidas alterações, as seguintes soluções deverão ser implementadas:
+
* Feita as devidas alterações, o pedido estará habilitado para que seja possível:
 
# Re-aprovação do pedido para nova tentativa;
 
# Re-aprovação do pedido para nova tentativa;
# Exclusão do pedido, caso o usuário escolha pelo cancelamento;
+
# Cancelamento do pedido, caso o usuário escolha pelo cancelamento;
 
# Tramitação do pedido, para reenvio ao vendedor.
 
# Tramitação do pedido, para reenvio ao vendedor.
  
Linha 58: Linha 58:
 
|}
 
|}
  
=== Pedido Efetivado e Aprovado, mas sem Integração ERP ===
+
=== Cenário 1 - Pedido retornado para cancelamento ===
  
[[arquivo:fluxograma1.png|frame|Fluxo de processos de gatilho de retorno]]
+
[[arquivo:fluxovollo1.png|frame|Fluxo de processos de gatilho de retorno]]
  
* O pedido, após aprovado, será submetido para integração.  
+
# O pedido, após aprovado, será submetido para integração.  
* O processo de integração apresentou uma falha de integração, registrando na tabela ACK_LOG_TABLE.
+
# O processo de integração apresentou uma falha de integração, registrando na tabela ACK_LOG_TABLE.
* A falha criará a pendencia falha de integração, disparando o trigger que abrirá uma tramitação de pendência, tornando o pedido ao status de pendente.
+
# A inserção de uma falha na tabela de aceite disparará um evento que inserirá a pendência de falha de importação de pedido, tornando o pedido pendente.
* Será disparado uma notificação de pendência para o '''vendedor''';
+
# Será disparado uma notificação de pendência para o '''vendedor''';
* O pedido voltará com o status de pendente, retornando ao '''gestor'''.  
+
# O pedido voltará com o status de pendente, retornando ao '''gestor'''.
* O '''gestor''' poderá reenviar o pedido para nova aprovação, ou
+
# O '''gestor''' procede com o cancelamento do pedido, excluindo o pedido de forma permanente.
* cancelar o pedido, ou
+
 
* Enviar para tramitação, devolvendo o pedido ao vendedor.
+
=== Cenário 2 - Pedido retornado para reenvio ===
 +
 
 +
# O pedido, após aprovado, será submetido para integração.
 +
# O processo de integração apresentou uma falha de integração, registrando na tabela ACK_LOG_TABLE.
 +
# A inserção de uma falha na tabela de aceite disparará um evento que inserirá a pendência de falha de importação de pedido, tornando o pedido pendente.
 +
# Será disparado uma notificação de pendência para o '''vendedor''';
 +
# O pedido voltará com o status de pendente, retornando ao '''gestor'''.  
 +
# O '''gestor''' faz uma nova aprovação no pedido, enviando-o novamente para integração.
 +
 
 +
=== Cenário 3 - Pedido retornado e devolvido ao vendedor ===
 +
 
 +
# O pedido, após aprovado, será submetido para integração.
 +
# O processo de integração apresentou uma falha de integração, registrando na tabela ACK_LOG_TABLE.
 +
# A inserção de uma falha na tabela de aceite disparará um evento que inserirá a pendência de falha de importação de pedido, tornando o pedido pendente.
 +
# Será disparado uma notificação de pendência para o '''vendedor''';
 +
# O pedido voltará com o status de pendente, retornando ao '''gestor'''.
 +
# O '''gestor''' faz seleciona a função "tramitação do pedido", devolvendo o assunto ao '''vendedor''' para eventuais modificações.
 +
# Feitas as modificações, o pedido será novamente inserido no fluxo de aprovações para integração.
  
 
== Regras de Negócio ==
 
== Regras de Negócio ==
  
'''[RN1] -''' A pendência que ira disparar o trigger para retorno deverá ser criado na tabela TIPO_BLOC_PEDIDO_SIT.
+
'''[RN1] -''' Quando houver uma inserção de falha de importação para um pedido, a ação de inserir a pendência será executada caso a base tenha configurado esse comportamento.
 +
 
 +
'''[RN2] -''' A inserção da pendência será feita após a marcação da falha na integração. A descrição da pendência deve deixar claro que houve falha de importação.
  
'''[RN2] -''' O retorno do pedido será feito imediatamente após a falha na integração, e retorno da pendência 'falha na integração'.
+
'''[RN3] -''' Após a ação ser acionada, deve ser disparado um mecanismo de feedback para o usuário (ex. disparo de e-mail, informando que o pedido está pendente por falha de integração caso seja configurado esse comportamento).
  
'''[RN3] -''' Após o trigger ser acionado, deve ser disparado um mecanismo de feedback para o usuário (ex. disparo de e-mail, informando que o pedido retornou).
+
'''[RN4] -''' Pode ocorrer, ainda que muito remotamente, o risco do pedido ser integrado '''no momento entre o processo de inserção de pendência'''. No caso de ocorrência deste processo, o pedido ficará pendente, mesmo sendo integrado.
  
'''[RN4] -''' Pode ocorrer, ainda de muito remotamente, o risco de o pedido ser integrado '''no momento entre o processo de retorno'''. No caso de ocorrência deste processo, o processo de retorno deverá ser cancelado.
+
'''[RN5] -''' Deve ser configurável a ativação desse processo de tratativa de falha de importação. Também deve ser possível habilitar ou desabilitar o informativo ao usuário sobre a situação em que o pedido se encontra.
  
 
== Aprovação ==
 
== Aprovação ==
Linha 94: Linha 113:
  
 
|-  
 
|-  
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
+
| Desenvolvimento - GeoSales || Anderson Gomes || 20/04/2021
 
|-  
 
|-  
 
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
 
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000

Edição atual tal como às 21h00min de 20 de abril de 2021

Histórico de Alterações

Data Quem Comentários
13/04/2021 João Ramon Criação do documento

Necessidade

Após a elaboração de um pedido, o vendedor enviará para efetivação. Se não houver pendências, ele será enviado diretamente para integração. Caso contrário, será encaminhado a um gestor para aprovação. A partir daí, será feito o envio à ERP. Nas duas situações, há a possibilidade deste pedido não ser integrado, por conta de alguma falha e, neste caso, não poderá ser mais editado, por já estar efetivado e aprovado. Dessa forma, o pedido não pode ser editado, nem cancelado, apenas existindo. Faz-se necessário, portanto, criar um meio para que este pedido possa ser novamente disponibilizado para edições pelos usuários.


Solução

Para atender à demanda solicitada, após o pedido ser finalizado no portal, ele vai para integração. Se o pedido não conseguir ser integrado, deverá ser possível que este pedido seja novamente tornado pendente. O processo deverá ser realizado por meio de um gatilho (trigger), sendo acionado logo após o registro da falha. Após este disparo, o pedido será disponibilizado para o gestor com o status de pendente, possibilitando que ele possa reenviar para aprovação, cancelar o pedido ou reenviar ao vendedor para eventuais ajustes. No processo, ainda deve existir um recurso que, quando o pedido for retornado ao portal, o vendedor deva ser informado que o pedido não foi integrado, e que necessita de intervenção.

Ressaltamos ainda, que, no momento do retorno do pedido ao portal, possa existir a possibilidade, ainda que remota, de o pedido ser integrado na tentativa seguinte.

Em resumo, a solução consiste nos seguintes passos:

  1. Criação de uma pendência relacionada à Falha de Integração na tabela relacionada;
  2. Criação de um trigger que faça o pedido retornar ao status de pendente;
  3. Criação de dispositivo de comunicação ao usuário, informando que o pedido não foi integrado, e aguarda configurações, inserindo este passo na tramitação do pedido ao vendedor;
  4. Após as modificações do usuário, o pedido será novamente submetido à integração para o gestor. Se integrar, o pedido estará encerrado; caso contrário, deverá retornar ao ponto 1 para novo procedimento.

Implementação

  • Todos os pedidos realizados na plataforma que integram com o modelo TJ tem o resultado do processo de integração registrados na tabela ACK_LOG_TABLE. Para as pendências de pedido, elas são vinculadas na tabela TIPO_BLOC_PEDIDO_REL. As pendência inseridas são descritas na tabela TIPO_BLOC_PEDIDO_SIT.
  • É necessária criar uma pendência dentro da tabela TIPO_BLOC_PEDIDO_SIT, contemplando a situação deste cenário (Falha de Integração);
  • Após a conclusão das tramitações normais do pedido (efetivação e aprovação), ele estará disponível para integração.
  • Se a integração não ocorrer, deverá ser acionado um gatilho para que este pedido fique com status de pendente, utilizando a situação de bloqueio criada na tabela TIPO_BLOC_PEDIDO_SIT.
  • Além disso, deverá haver um retorno (feedback) para o usuário, informando que o seu pedido não foi integrado, e está novamente disponível no portal para revisão.
  • O pedido deverá estar disponível para edição e para cancelamento, caso seja a demanda do usuário.
  • Feita as devidas alterações, o pedido estará habilitado para que seja possível:
  1. Re-aprovação do pedido para nova tentativa;
  2. Cancelamento do pedido, caso o usuário escolha pelo cancelamento;
  3. Tramitação do pedido, para reenvio ao vendedor.

Cenários

Criação de Pendência na Tabela TIPO_BLOC_PEDIDO_SIT

CD_TIPO_BLOC DS_TIPO_BLOC CD_TIPO_PEDENCIA
XX Falha de integração NULL

Cenário 1 - Pedido retornado para cancelamento

Fluxo de processos de gatilho de retorno
  1. O pedido, após aprovado, será submetido para integração.
  2. O processo de integração apresentou uma falha de integração, registrando na tabela ACK_LOG_TABLE.
  3. A inserção de uma falha na tabela de aceite disparará um evento que inserirá a pendência de falha de importação de pedido, tornando o pedido pendente.
  4. Será disparado uma notificação de pendência para o vendedor;
  5. O pedido voltará com o status de pendente, retornando ao gestor.
  6. O gestor procede com o cancelamento do pedido, excluindo o pedido de forma permanente.

Cenário 2 - Pedido retornado para reenvio

  1. O pedido, após aprovado, será submetido para integração.
  2. O processo de integração apresentou uma falha de integração, registrando na tabela ACK_LOG_TABLE.
  3. A inserção de uma falha na tabela de aceite disparará um evento que inserirá a pendência de falha de importação de pedido, tornando o pedido pendente.
  4. Será disparado uma notificação de pendência para o vendedor;
  5. O pedido voltará com o status de pendente, retornando ao gestor.
  6. O gestor faz uma nova aprovação no pedido, enviando-o novamente para integração.

Cenário 3 - Pedido retornado e devolvido ao vendedor

  1. O pedido, após aprovado, será submetido para integração.
  2. O processo de integração apresentou uma falha de integração, registrando na tabela ACK_LOG_TABLE.
  3. A inserção de uma falha na tabela de aceite disparará um evento que inserirá a pendência de falha de importação de pedido, tornando o pedido pendente.
  4. Será disparado uma notificação de pendência para o vendedor;
  5. O pedido voltará com o status de pendente, retornando ao gestor.
  6. O gestor faz seleciona a função "tramitação do pedido", devolvendo o assunto ao vendedor para eventuais modificações.
  7. Feitas as modificações, o pedido será novamente inserido no fluxo de aprovações para integração.

Regras de Negócio

[RN1] - Quando houver uma inserção de falha de importação para um pedido, a ação de inserir a pendência será executada caso a base tenha configurado esse comportamento.

[RN2] - A inserção da pendência será feita após a marcação da falha na integração. A descrição da pendência deve deixar claro que houve falha de importação.

[RN3] - Após a ação ser acionada, deve ser disparado um mecanismo de feedback para o usuário (ex. disparo de e-mail, informando que o pedido está pendente por falha de integração caso seja configurado esse comportamento).

[RN4] - Pode ocorrer, ainda que muito remotamente, o risco do pedido ser integrado no momento entre o processo de inserção de pendência. No caso de ocorrência deste processo, o pedido ficará pendente, mesmo sendo integrado.

[RN5] - Deve ser configurável a ativação desse processo de tratativa de falha de importação. Também deve ser possível habilitar ou desabilitar o informativo ao usuário sobre a situação em que o pedido se encontra.

Aprovação

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

GeoSales

Setor Aprovado Por Data
Desenvolvimento - GeoSales Anderson Gomes 20/04/2021
Integração - GeoSales Pessoa que aprovou 00/00/0000
Configurações - GeoSales Pessoa que aprovou 00/00/0000

Empresa solicitante

Setor Aprovado Por Data Assinatura
Gerente TI - Cliente ___________________ ___/___/_____ ________________________
Gerente de Projeto - Cliente ___________________ ___/___/_____ ________________________
Gerente Comercial - Cliente ___________________ ___/___/_____ ________________________