Discussão:Bonificação com Saldo Fixo - Histórico de revisão

Jeffque: /* Uso de estruturas já previamente existentes */ nova seção

2016-09-22T13:00:56Z

Uso de estruturas já previamente existentes: nova seção

Jeffque: /* Paralelismo não concorrente */ nova seção

2016-09-22T12:53:35Z

Paralelismo não concorrente: nova seção

Jeffque: /* ¿Regras de negócio? */

2016-09-22T12:43:24Z

¿Regras de negócio?

Jeffque: /* ¿Regras de negócio? */ nova seção

2016-09-22T12:39:57Z

¿Regras de negócio?: nova seção

Jeffque: /* Cenário exclusão de pedidos de bonificação */

2016-09-22T12:29:20Z

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

Jeffque: /* Cenário edição de pedidos de bonificação */

2016-09-22T12:26:01Z

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

Jeffque: /* Cenário exclusão de pedidos de bonificação */ nova seção

2016-09-22T12:23:32Z

Cenário exclusão de pedidos de bonificação: nova seção

Jeffque: /* Cenário edição de pedidos de bonificação */ nova seção

2016-09-22T12:22:32Z

Cenário edição de pedidos de bonificação: nova seção

Página nova

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

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

← Edição anterior		Edição das 13h00min de 22 de setembro de 2016
Linha 30:		Linha 30:

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

← Edição anterior		Edição das 12h53min de 22 de setembro de 2016
Linha 24:		Linha 24:

	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		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

← Edição anterior		Edição das 12h43min de 22 de setembro de 2016
Linha 22:		Linha 22:
	** '''SA''' saldo disponível para o cliente antes da tirado do pedido		** '''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		** '''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

← Edição anterior		Edição das 12h39min de 22 de setembro de 2016
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		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

← Edição anterior		Edição das 12h29min de 22 de setembro de 2016
Linha 8:		Linha 8:

	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		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

@@ Linha 2: / Linha 2: @@
 Se é edição de pedido, por que o pedido editado não é algo dado?
 == 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

← Edição anterior		Edição das 12h23min de 22 de setembro de 2016
Linha 2:		Linha 2:

	Se é edição de pedido, por que o pedido editado não é algo dado?		Se é edição de pedido, por que o pedido editado não é algo dado?
		+
		+	== 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