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

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

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 - 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	___________________	___/___/_____	________________________

@@ Linha 12: / Linha 12: @@
 == Necessidade ==
-Ao finalizar o processo de inserção de pedidos, pelo vendedor, caso não haja nenhuma pendência de negócio (exemplos: tipo de frete não especificado, valor final do pedido ou de um determinado grupo está fora da política comercial de descontos, valor apresentado ao cliente era de uma campanha cuja vigência já encerrou, dentre outros), o pedido 'subirá' para integração na ERP. Caso haja pendências, será necessária aprovação de um gestor responsável. então seguirá o caminho normal, ir pra integração. O problema é que, após aprovar tal pedido, por algum motivo, ele não consegue 'subir' para o ERP, a fim de integrar a venda, mesmo depois de várias tentativas sucessivas. Nesta situação, é impossível fazer qualquer edição ou exclusão do pedido, depois que já foi aprovado. Na situação atual, o pedido fica vagando por um limbo de dados existencial, no qual não pode ser configurado, nem pode subir para integração. Por essa razão, faz-se necessária uma ação que permita que, em situações como essa, haja a possibilidade de cancelar ou editar o '''pedido 'perdido''''.
+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.
-<!--Durante o processo de formação de pedidos, é comum que possa ocorrer alguma pendência de processo. Essas pendências podem ocorrer pelos mas diversos motivos, tais como: tipo de frete não especificado, valor final do pedido ou de um determinado grupo está fora da política comercial de descontos, valor apresentado ao cliente era de uma campanha cuja vigência já encerrou, e muitas outras situações, para as quais o portal consegue identificar e listar quais pendências estão ativas após o envio do pedido pelo vendedor. Quando o pedido chega para aprovação do gestor, dependendo de sua alçada, é possível efetivar a aprovação do pedido, mesmo com tais pendências. O problema é que, após aprovar tal pedido, por algum motivo, ele não consegue 'subir' para o ERP, a fim de efetivar a venda, tampouco é possível fazer qualquer edição ou exclusão do pedido, uma vez que já foi aprovado. Na situação atual, o pedido fica vagando por um limbo de dados existencial, no qual não pode ser configurado, nem pode subir para integração.-->
+<!--Ao finalizar o processo de inserção de pedidos, pelo vendedor, caso não haja nenhuma pendência de negócio (exemplos: tipo de frete não especificado, valor final do pedido ou de um determinado grupo está fora da política comercial de descontos, valor apresentado ao cliente era de uma campanha cuja vigência já encerrou, dentre outros), o pedido 'subirá' para integração na ERP. Caso haja pendências, será necessária aprovação de um gestor responsável. Após a aprovação, então seguirá para integração. O problema é que, após aprovar tal pedido, por algum motivo, ele não consegue 'subir' para o ERP, a fim de integrar a venda. Nesta situação, é impossível fazer qualquer edição ou exclusão do pedido, depois que já foi aprovado. Na situação atual, o pedido fica vagando por um limbo de dados existencial, no qual não pode ser configurado, nem pode subir para integração. Por essa razão, faz-se necessária uma ação que permita que, em situações como essa, haja a possibilidade de cancelar ou editar o '''pedido 'perdido''''.-->
 == Solução ==
-Para atender à demanda solicitada, deve ser possível que este pedido, após ter tentado integrar por um determinado número de vezes à ERP, retornar para a edição no portal, sob o status de '''pendente''' e '''não efetivado'''. Assim, será possível que algumas modificações possam ser realizadas, a fim de tratar alguma pendência ou para tentar integrar novamente, ou para ser cancelado, caso o cliente deseje. No processo, deve existir uma rotina no meio do caminho da tramitação do pedido para que, quando o pedido for retornado ao portal, o vendedor/gestor deva ser informado que o seu pedido não foi integrado, e que necessita revisões.
+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 ==
-* Após a conclusão dos seguimentos das tramitações normais do pedido (efetivação e aprovação), o pedido estará disponível para integração.
-* Após 10 (dez) tentativas de integração, deverá ser acionado um gatilho de retorno (trigger) para que este pedido possa retornar ao portal, com status de não efetivado e pendente.
+* 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, as seguintes soluções deverão ser implementadas:
+* Feita as devidas alterações, o pedido estará habilitado para que seja possível:
-# Exclusão do pedido, caso o usuário escolha pelo cancelamento;
+# Re-aprovação do pedido para nova tentativa;
-# Nova efetivação e aprovação, caso o usuário tenha feito modificações no pedido.
+# Cancelamento do pedido, caso o usuário escolha pelo cancelamento;
-* 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.
+# Tramitação do pedido, para reenvio ao vendedor.
-* É necessária criar uma pendência dentro da tabela TIPO_BLOC_PEDIDO_SIT, para este tipo de situação.
 == Cenários ==
-<!--=== Cenário 1 (Pedido não efetivado e Aprovado - Sem Pendências) ===
+=== Criação de Pendência na Tabela TIPO_BLOC_PEDIDO_SIT ===
-Neste cenário, o pedido não possui nenhuma pendência de configuração ou de políticas comerciais (e, portanto, na situação de 'aprovado').
+{|class="wikitable"
+! <code>CD_TIPO_BLOC</code>
+! <code>DS_TIPO_BLOC</code>
+! <code>CD_TIPO_PEDENCIA</code>
+|-
+| XX || Falha de integração || NULL
+|-
+|}
-* O portal, nesta fase, ainda permite alterações por parte do usuário;
+=== Cenário 1 - Pedido retornado para cancelamento ===
-* O pedido '''não será enviado''' para ERP caso esteja nesta situação.
-=== Cenário 2 (Pedido não efetivado e Pendente) ===
+[[arquivo:fluxovollo1.png|frame|Fluxo de processos de gatilho de retorno]]
-Neste cenário, o pedido possui alguma pendência.
+# 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.
-* O portal, nesta fase, ainda permite alterações por parte do usuário;
+=== Cenário 2 - Pedido retornado para reenvio ===
-* O pedido '''não será enviado''' para ERP caso esteja nesta situação.
-=== Cenário 3 (Pedido efetivado e Pendente) ===
+# 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.
-Aqui, o pedido já foi efetivado. No entanto, foram encontradas situações no registro que gerara pendências. Portanto, o pedido estará no status de pendente.
+=== Cenário 3 - Pedido retornado e devolvido ao vendedor ===
-* O portal, nesta fase, ainda permitirá alterações por parte do usuário (caso o gestor não aprove o pedido e devolva ao vendedor para edição). Também será possível cancelar o pedido nesta situação;
+# O pedido, após aprovado, será submetido para integração.
-* O pedido '''não será enviado''' para ERP caso esteja nesta situaçã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.
-=== Cenário 4  (Pedido Efetivado e Aprovado) - com Integração ERP ===
+== Regras de Negócio ==
-Neste cenário, o pedido foi efetivado e já aprovado pelo supervisor.
-* O portal, nesta fase, não permitirá mais qualquer edição ou correção por parte do usuário;
-* O pedido '''será enviado''' para ERP caso esteja nesta situação.
--->
-=== Cenário 5  (Pedido Efetivado e Aprovado) - sem Integração ERP ===
+'''[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.
-Neste cenário, o pedido foi efetivado e já aprovado pelo supervisor, similar ao '''cenário 4''', discutido anteriormente. A diferença é que, para este cenário, contemplamos uma '''falha ao integrar o pedido à ERP''':
+'''[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.
-* O pedido não será integrado, pois a falha apresentada é perene, ou seja, as schedules não farão subir o pedido.
+'''[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).
-* O pedido, por já estar aprovado na plataforma, não pode retornar para o usuário para edição, para ser corrigido/cancelado.
-Nesta situação, os passos que deverão ser seguidos para o cenário desejado serão:
-# O pedido deverá registrar a pendência (Falha na Importação) na décima tentativa do schedule;
-# Caso o pedido esteja com a pendência (Falha na Importação), deverá disparar um gatilho (trigger) para que ele cesse de tentar integrar.
-# Esta pendência irá retirar o pedido da fila de integração e alocará de volta ao portal, com o status de não efetivado e pendente.
-# Com este status, o usuário poderá fazer edições no pedido, para verificar eventuais ajustes, ou cancelar o mesmo.
-# Caso opte por cancelar, o pedido será excluído.
-# Caso opte por editar, será novamente efetivado e, se estiver sem pendências, será novamente submetido à integração. Caso haja alguma pendência, deverá ter a aprovação de um gestor, e subirá para integração após aprovação.
-== Regras de Negócio ==
-'''[RN1] -''' A pendência que ira disparar o trigger para retorno deverá ser criado na tabela TIPO_BLOC_PEDIDO_SIT.
+'''[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.
-'''[RN2] -''' 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).
+'''[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 ==
@@ Linha 103: / 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