Confusing way of how credits and points work

[Superbestron]

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

[nus-pe-bot]

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.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: There are a few reasons why I disagree, even after considering the team's arguments.

1. This still does not change the fact that it's still confusing to the user. Why does a user need to know credit then when all he needs to know is how many points he has? Having both of these terms in each user's profile which have both potentially very similar meanings seeks to mislead users. Credits should only be visible to the manager because these stats might be important to the manager in planning sales.
2. Based on point 1 of the team's argument, there are many simple ways around this, one is to do a check and ensure the decrease of the points do not become 0, by making the minimum point value 0. A "compensation" could be given then by adding a certain number of points to the user's balance.
3. Based on point 3, the customer is not penalised in any way since he was not supposed to be given the points in the first place. Similar to my point above, the remaining points that he is not supposed to have can be deducted till his points reaches 0. Of course there might be other possible ways but my point is that this reason does not make any sense.
4. Based on point 4, providing users flexibility in using the app cannot be an excuse for "a lack of guidance for users on how to use the app". There are certainly many ways one can mistakenly or intentionally game the system and it seems like the team has not adequately provided defense mechanisms against this.

---

:question: Issue severity

Team chose [severity.VeryLow] Originally [severity.Medium]

• [x] I disagree

Reason for disagreement: This is similar to my reasons above.

---