Mudanças entre as edições de "Cancelamento de Pedidos"
(10 revisões intermediárias por 2 usuários não estão sendo mostradas) | |||
Linha 34: | Linha 34: | ||
− | * Todos os pedidos realizados na plataforma | + | * 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 | + | * 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, | + | * 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; | ||
− | # | + | # 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: | ||
|} | |} | ||
− | === Cenário 1 | + | === Cenário 1 - Pedido retornado para cancelamento === |
− | [[arquivo: | + | [[arquivo:fluxovollo1.png|frame|Fluxo de processos de gatilho de retorno]] |
− | + | # 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''' procede com o cancelamento do pedido, excluindo o pedido de forma permanente. | |
− | |||
− | |||
− | === Cenário 2 | + | === 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 == | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | '''[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 == | == Aprovação == | ||
Linha 118: | Linha 113: | ||
|- | |- | ||
− | | Desenvolvimento - GeoSales || | + | | 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:
- Criação de uma pendência relacionada à Falha de Integração na tabela relacionada;
- Criação de um trigger que faça o pedido retornar ao status de pendente;
- 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;
- 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:
- Re-aprovação do pedido para nova tentativa;
- Cancelamento do pedido, caso o usuário escolha pelo cancelamento;
- 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
- 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 procede com o cancelamento do pedido, excluindo o pedido de forma permanente.
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
[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 | ___________________ | ___/___/_____ | ________________________ |