Open nus-se-script opened 1 week ago
We initially planned to allow users to keep track of orders separately, also because merging orders may lead to complications in terms of implementation and different orders (of the same details) may not always have the same circumstances (more details below).
Under the addorder
command in the UG, the constraints state that a warning will be given if a pending order with a similar item and identical quantity and date already exists in the order list.
This implies that the app inherently accepts multiple separate orders of the same item with identical details.
Further, this app is considered from the perspective of a Carousell seller who may receive multiple orders from a single customer requesting for the same item, to be delivered by the same day. In this case, it is not necessary for the seller who may face limitations in delivering all of the orders in a single delivery, and may consider delivering them separately. Forcing the app to merge all of such orders may complicate order management for said partial deliveries.
However, we acknowledge that this can be better as we could have provided users with the option to merge orders, which can perhaps be in future implementations.
--
Summary
Same orders with the same name and same delivery date does not add on to one another
Since the order have the same name and same delivery date, perhaps merge them together to make it more convienent for the user, as a customer might buy the same item repeatedly and might flood the entire addressbook
Steps to Reproduce
addorder 1 i/Lamp d/20-12-2024 q/2 Execute repeatedly
Screenshots
Reasoning for Severity
With so much redudant details, it can cause a minor/occasional inconvenience for a user to continue using the addressbook
[original: nus-cs2103-AY2425S1/pe-interim#518] [original labels: type.FeatureFlaw severity.Low]