Discussão:Cancelamento de Pedidos

Observações

• O documento não se destina a cancelamento de pedidos, mas sim adição de um ciclo para tratar pedidos no limbo em falha de importação.
• Eu deixaria a necessidade condizente com esse ponto, em vez de "haja a possibilidade de cancelar ou editar o pedido 'perdido'." por permitir que o usuário tenha acesso a esses pedidos no limbo.

• Sobre essa fala:

"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 retorne para a edição no portal, sob o status de pendente." Acredito que ele não fique imediatamente editável, somente se o supervisor retornar o pedido o mesmo ficará editável. No decorrer do texto isso é afirmado de diversas formas, mas esse não é o fluxo que acontecerá.

• Nesse ponto:

"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;" Caso o cliente não utilize tramitação isso será inefetivo. Que outras soluções podemos aplicar? Esse feedback é obrigatório?

• Sobre esse ponto:

"O pedido deverá estar disponível para edição e para cancelamento, caso seja a demanda do usuário." Ressaliento minha preocupação do fluxo final ser diferente desse ou ter um passo antes disso que não está claro. Que é a interferência do supervisor que pode cancelar ou retornar o pedido para edição.

• O cenário 1 apresenta algumas afirmações que não estão claras tipo:

"A falha criará a pendencia falha de integração, disparando o trigger que abrirá uma tramitação de pendência, retornando o pedido para o portal." (Aqui temos a questão da tramitação, e o retorno do pedido para o portal, o que é esse retorno?) "Será disparado uma notificação de pendência para o gestor;" (O que é essa notificação?) Aqui temos um erro textual em uma quebra de linha desnecessária e algumas vezes é citado volta/retornar. "O pedido voltará com o status de pendente, retornando ao gestor." & "O gestor poderá reenviar o pedido numa nova aprovação, ou cancelar o pedido, ou Enviar para tramitação, devolvendo o pedido ao vendedor." O que é enviar para tramitação e devolver o pedido ao vendedor, citar exemplos.

• O cenário 2 segue a risca os mesmos problemas e basicamente é a mesma coisa do cenário 1.

Novamente, os cenários voltar a ser descritivos e apresentam possibilidades em vez de eventos. Cenários não dever ser assim. Cenários devem ter dados & ações como foi feito nos documentos da mantiqueira.

• A RN1 não está correta. A trigger ficará na tabela de ACK e ela gerará uma pendência na tipo_bloc_pedido_rel. A trigger não é para retorno, ela vai inserir uma pendência. O retorno é um fluxo, mas não define o que vai acontecer. Tentar ser mais específico. Ex. A trigger deixará o pedido pendente para que possa ser analisado pelo supervisor responsável que tenha permissão de visualização da pendência.

• A RN2