Mudanças entre as edições de "Discussão:Bonificação com Saldo Fixo"

Edição atual tal como às 13h00min de 22 de setembro de 2016

Cenário edição de pedidos de bonificação

Se é edição de pedido, por que o pedido editado não é algo dado?

Na verdade, estou vendo aqui a cópia do cenário anterior

Cenário exclusão de pedidos de bonificação

Só frescura, acho que simplesmente falar que vai excluir o pedido Y é suficiente, não precisa repetir na operação que ele tem o valor de R$500

A frase O sistema deve, após a remoção do pedido, incrementar o saldo do cliente Sousa pelo valor igual ao valor do pedido excluído não é aferível. Entretanto, a frase O saldo de bonificação de Sousa deve ficar igual a R$1000 já reflete o comportamento e permite que se afira

¿Regras de negócio?

A RN1 definitivamente não é regra de negócio. Como forma de incentivar a compra por parte de novos clientes é dado ao cliente um valor para ser usado como bonificação é motivação para a customização, então o conteúdo deveria entrar na necessidade do cliente.

RN2 é de fato regra de negócio, entretanto ela se explicaria melhor seguida de alguma espécie de notação matemática, mais ou menos, quiçá assim...

RN2: o saldo da bonificação deverá ser validado para cada cliente ao se tirar pedido de bonificação. Se V > SA, o sistema não deve permitir que o pedido seja salvo; caso contrário, deve-se atualizar o saldo do cliente SN = SA - V
- V valor do pedido de bonificação
- SA saldo disponível para o cliente antes da tirado do pedido
- SA saldo novo disponível para o cliente, logo depois da tirado do pedido

Do jeito que eu descrevi, misturei um pouco movimentação e validação (ou seja, RN2 e RN3). Eu sei que é difícil dissociar esses 2, mas creio que seja possível. Possivelmente ficaria mais fácil se primeiro se descrevesse a movimentação para depois se descrever a validação

Paralelismo não concorrente

Temos casos de clientes compartilhado por vendedores, e cliente que pode ser atendido no portal e no dispositivo do mesmo vendedor. Assim sendo, o valor de saldo não pode ser trafegado, ofendendo assim a modelagem da tabela SALDO_BONI_CLIENTE.SALDO.

Outro ponto também é a parte de validação real do saldo. Você tem a mesma encrenca com o saldo da bonificação que o Arielton tem para estoque. Acho bom falar com ele para ver como resolver isso. Na hipótese do algoritmo do avestruz, se o cliente é atendido por N vendedores e tem saldo inicial S, o pior cenário ele fará (N+1)*S reais em bonificação

Uso de estruturas já previamente existentes

Bem, como se sabe, temos o limite de crédito por meio de pagamento. É possível modelar essa necessidade do cliente através disso tranquilamente. Tem a vantagem também de, além do limite de crédito por meio de pagamento sanar todas as dificuldades, também prevê o caso de cancelamento de pedido (um cenário válido que acabou que não entrou nos cenários).

Entretanto, essa alternativa segue o algoritmo do avestruz

@@ Linha 11: / Linha 11: @@
 A frase '' O sistema deve, após a remoção do pedido, incrementar o saldo do cliente Sousa pelo valor igual ao valor do pedido excluído'' não é aferível. Entretanto, a frase ''O saldo de bonificação de Sousa deve ficar igual a R$1000'' já reflete o comportamento e permite que se afira
+== ¿Regras de negócio? ==
+A RN1 definitivamente não é regra de negócio. ''Como forma de incentivar a compra por parte de novos clientes é dado ao cliente um valor para ser usado como bonificação'' é motivação para a customização, então o conteúdo deveria entrar na necessidade do cliente.
+RN2 é de fato regra de negócio, entretanto ela se explicaria melhor seguida de alguma espécie de notação matemática, mais ou menos, quiçá assim...
+* RN2: o saldo da bonificação deverá ser validado para cada cliente ao se tirar pedido de bonificação. Se '''V''' > '''SA''', o sistema não deve permitir que o pedido seja salvo; caso contrário, deve-se atualizar o saldo do cliente '''SN''' = '''SA''' - '''V'''
+** '''V''' valor do pedido de bonificação
+** '''SA''' saldo disponível para o cliente antes da tirado do pedido
+** '''SA''' saldo novo disponível para o cliente, logo depois da tirado do pedido
+Do jeito que eu descrevi, misturei um pouco movimentação e validação (ou seja, RN2 e RN3). Eu sei que é difícil dissociar esses 2, mas creio que seja possível. Possivelmente ficaria mais fácil se primeiro se descrevesse a movimentação para depois se descrever a validação
+== Paralelismo não concorrente ==
+Temos casos de clientes compartilhado por vendedores, e cliente que pode ser atendido no portal e no dispositivo do mesmo vendedor. Assim sendo, o valor de saldo não pode ser trafegado, ofendendo assim a modelagem da tabela '''SALDO_BONI_CLIENTE.SALDO'''.
+Outro ponto também é a parte de validação real do saldo. Você tem a mesma encrenca com o saldo da bonificação que o Arielton tem para estoque. Acho bom falar com ele para ver como resolver isso. Na hipótese do algoritmo do avestruz, se o cliente é atendido por '''N''' vendedores e tem saldo inicial '''S''', o pior cenário ele fará ('''N'''+1)*'''S''' reais em bonificação
+== Uso de estruturas já previamente existentes ==
+Bem, como se sabe, temos o limite de crédito por meio de pagamento. É possível modelar essa necessidade do cliente através disso tranquilamente. Tem a vantagem também de, além do limite de crédito por meio de pagamento sanar todas as dificuldades, também prevê o caso de cancelamento de pedido (um cenário válido que acabou que não entrou nos cenários).
+Entretanto, essa alternativa segue o [http://10.0.0.32/wiki/index.php/Discuss%C3%A3o:Bonifica%C3%A7%C3%A3o_com_Saldo_Fixo#Paralelismo_n.C3.A3o_concorrente| algoritmo do avestruz]