Exibir código-fonte para Discussão:Bonificação com Saldo Fixo

== 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 [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]