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

De GeoSales
Ir para navegação Ir para pesquisar
 
(67 revisões intermediárias por 2 usuários não estão sendo mostradas)
Linha 12: Linha 12:
 
== Necessidade ==
 
== Necessidade ==
  
−
Ao finalizar o processo de formaçã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 efetivar a venda. mesmo depois de várias tentativas de schedule. 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 ==
 
== Solução ==
  
−
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.
+
 
 +
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 ==
 
== 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 ==
 
== 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 ===
 +
 
 +
{|class="wikitable"
 +
! <code>CD_TIPO_BLOC</code>
 +
! <code>DS_TIPO_BLOC</code>
 +
! <code>CD_TIPO_PEDENCIA</code>
 +
|-
 +
| XX || Falha de integração || NULL
 +
|-
 +
|}
 +
 
 +
=== Cenário 1 - Pedido retornado para cancelamento ===
  
−
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').
+
[[arquivo:fluxovollo1.png|frame|Fluxo de processos de gatilho de retorno]]
  
−
* O portal, nesta fase, ainda permite alterações por parte do usuário;
+
# 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''' procede com o cancelamento do pedido, excluindo o pedido de forma permanente.
  
−
=== Cenário 2 (Pedido não efetivado e Pendente) ===
+
=== Cenário 2 - Pedido retornado para reenvio ===
  
−
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''' faz uma nova aprovação no pedido, enviando-o novamente para integração.
  
−
* O portal, nesta fase, ainda permite alterações por parte do usuário;
+
=== Cenário 3 - Pedido retornado e devolvido ao vendedor ===
−
* 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 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.
  
−
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.
+
== Regras de Negócio ==
  
−
* 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;
+
'''[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.
−
* O pedido '''não será enviado''' para ERP caso esteja nesta situação.
 
  
−
=== Cenário 4  (Pedido Efetivado e Aprovado) - com Integração 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.
  
−
Neste cenário, o pedido foi efetivado e já aprovado pelo supervisor.  
+
'''[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 portal, nesta fase, não permitirá mais qualquer edição ou correção por parte do usuário;
+
'''[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.
−
* O pedido '''será enviado''' para ERP caso esteja nesta situação.
 
  
 +
'''[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 ==
  
−
=== Cenário 5  (Pedido Efetivado e Aprovado) - sem Integração ERP ===
 
  
 +
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.
  
−
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''':
+
=== GeoSales ===
  
−
* O pedido não será integrado, pois a falha apresentada é perene, ou seja, as schedules não farão subir o pedido.
+
{| class="wikitable"
−
* O pedido, por já estar aprovado na plataforma, não pode retornar para o usuário para edição, para ser corrigido/cancelado.
+
! Setor
 +
! Aprovado Por
 +
! Data
  
−
== Regras de Negócio ==
+
|-
 +
| 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 ===  
  
−
== Aprovação ==
+
{| class="wikitable"
 +
! Setor
 +
! Aprovado Por
 +
! Data
 +
! Assinatura
 +
|-
 +
| Gerente TI - Cliente || ___________________ || ___/___/_____ || ________________________
 +
|-
 +
| Gerente de Projeto - Cliente || ___________________ || ___/___/_____ || ________________________
 +
|-
 +
| Gerente Comercial - Cliente || ___________________ || ___/___/_____ || ________________________
 +
|-
 +
|}

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 ___________________ ___/___/_____ ________________________
Disponível em “http://wiki.geosales.com.br:8000/index.php?title=Cancelamento_de_Pedidos&oldid=15333”