search

awesomesjh / pe

0 stars 0 forks source link

Profit in multiple dp #7

Open awesomesjh opened 6 months ago

awesomesjh commented 6 months ago

Typically price should be in 2dp, as you have mostly done in the rest of your app, but why is profit multiple dp in this case? Perhaps it would be better to round off to 2dp and notify the user. This is because I previously added an item with multiple dp buy and sell price.

Screenshot 2024-04-19 164852.png

soc-pe-bot commented 6 months ago

Team's Response

No details provided by team.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Inconsistency in number of decimal points taken in for overall commands, and those displayed

For each command that involves numbers the UG does not say about the decimal points that can be input. There is a lack of consistency between features and as a user, I am confused on the accuracy of numbers that I can insert and will be displayed.

list_items command displays 2dp.

image.png

total_revenue command displays 1dp.

image.png

[original: nus-cs2113-AY2324S2/pe-interim#2547] [original labels: type.FunctionalityBug severity.Medium]

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

Does not impact if 2 decimal place is required for total_revenue

Items for the Tester to Verify

:question: Issue duplicate status

Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)

Reason for disagreement: The 'Original' bug only shows the inconsistency in dp for list and low_stock commands. The example that I gave shows the inconsistency in dp for profit command. Fixing the inconsistency in dp for list and low_stock commands does not necessarily fix the inconsistency in dp for profit command, which is shown to be more than 2dp. Hence, they cannot be considered as duplicates.

## :question: Issue response Team chose [`response.NotInScope`] - [x] I disagree **Reason for disagreement:** Price should be typically shown in 2dp, there is no reason for this inconsistency where the profit is shown to be more than 2dp.
## :question: Issue type Team chose [`type.FunctionalityBug`] Originally [`type.FeatureFlaw`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
## :question: Issue severity Team chose [`severity.VeryLow`] Originally [`severity.Low`] - [x] I disagree **Reason for disagreement:** This is not a purely cosmetic problem, as the extra decimal points represent money. How this extra money should be handled by the program should have been clearly specified in the user guide. Would the money still be in the system but hidden? Or would it be rounded off in the system as well? Hence, trying to solve this issue is not as simple as just rounding off the console output.