Confusing way of how credits and points work

[nus-se-bot]

Reproduce:

1. edit -txn/ -id/00002000002 -b/0.00, such that the edited transaction amount is less than the actual amount.
2. The credits is now less than points

Expected:

1. The points should decrease as well since if the transaction was not correct in the first place, the points awarded should be edited together with the credits. Although it is stated in the documentation: "On the contrary, point will not be affected and will stay the same when billing amount is lesser than the billing amount added in last time.", it makes no sense to not update the points.
2. Let's say I accidentally billed a person as 9999.99 when it should be 99.99, this means that even though I edited the transaction, that user would gain free 9000 points just by this mistake which is a big flaw.

Actual: The number of points given to the user remains unchanged

---

_{[original: nus-cs2103-AY2122S1/pe-interim#5102] [original labels: type.FeatureFlaw severity.Medium]}

[zzybluebell]

Team's Response

Thanks for your time and effort!

Thanks for your explanation on your logic. We have already carefully considered the situation you described before our public release, and the described behaviour of ezFoodie on Point and Credit is indeed expected and desired.

Take an example:

• Point is 0 originally.
• Staff accidentally adds 1000.00 for a bill of actual amount 100.00.
• Point becomes 1000, which should be 100 instead.
• Customer decides to redeem 500 Point immediately.
• Point becomes 500.
• Sometime later, Staff spots the billing error and edits that particular transaction amount from 1000.00 back to 100.00.

1. In the example introduced above, Customer now has only 500 Point left. If we allow Point to decrease accordingly, Point will become negative, which is obviously undesirable and may lead to potential bugs.

2. To prevent this kind of issue from happening, we purposely set the rule that "Point will not be affected and will stay the same when billing amount is less than the billing amount added in last time", which is clearly stated in our UG. This approach is inspired by how restaurant Point system works in reality.

3. Moreover, we believe that it is Staff's responsibility in this situation. Similar to how most restaurants handle this kind of Point conflicts, ezFoodie is designed in the way that Customer will not be penalised for wrongly awarded Point, while Staff may be penalised for their false operations(It is up to the restaurant management office and not in the scope of this discussion).

4. Despite ezFoodie being set that Point will not de deducted in this situation by default, we has provided flexibility to restaurants to handle the conflict in the way they want. In the case that a restaurant insists on correcting Customer's Point, ezFoodie provides the option to use Redeem feature to deduct the amount that the restaurant wants to retrieve. In reality, restaurants usually only retrieve a percentage of Point and leave the remaining Point as a compensation to Customer.

In conclusion, we would like the readers of this response to know that our team did a careful consideration on how we should handle this kind of situation, with our own research on how the industry works in reality. We developers only equip ezFoodie with flexible features for our users, with its default behaviour set to the most commonly and widely used practice in food service industry. At the end of the day, it is ultimately up to users, which are restaurant staff and managers, to decide the exact way they want to use our product. We offer flexibilities.

Hope this clarify your doubt.

Duplicate status (if any):

--