Neo Kai Jun - Project Portfolio

Records the sales volume of an item within a specific day into the record list.
Format: record-sales d/DATE n/ITEM_NAME q/QUANTITY_SOLD p/ITEM_PRICE or rs d/DATE n/ITEM_NAME q/QUANTITY_SOLD p/ITEM_PRICE

Examples:

Auto-ingredient update mechanism

record-sales also determines all the ingredients you used and automatically deducts them from the ingredient list, subjected to the following conditions:
1) The item exists in the menu.
See Section 5.4.1, “Adding an item to the menu" for more information.
2) The required ingredients to make one unit of ITEM_NAME is specified.
See Section 5.4.14, “Add required ingredients" for more information.
3) All required ingredients exist in the ingredient list.
See Section 5.3.1, “Adding an ingredient" for more information.
4) There are sufficient ingredients to make QUANTITY_SOLD units of ITEM_NAME.
See Section 5.3.6, “Stocking up an ingredient" for more information.

Generate and display the sales report for a specific day.
Format: display-sales DATE or dis DATE

Examples:

The following (Figure 5.6.2.1) is an example of what you will see if the sales report is generated and displayed correctly:

Figure 5.6.2.1: Sales Report

Deletes the sales record identified by the index.
Format: delete-sales INDEX or des INDEX

Examples:

Edits the sales record identified by the index.
Format: edit-sales INDEX [d/DATE] [n/ITEM_NAME] [q/QUANTITY_SOLD] [p/ITEM_PRICE] or es INDEX [d/DATE] [n/ITEM_NAME] [q/QUANTITY_SOLD] [p/ITEM_PRICE]

Examples:

Ranks and displays all existing dates in the record list based on the total revenue.
Format: rank-date or rad

The following (Figure 5.6.6.1) is an example of what you will see if the ranking is generated and displayed correctly:

Figure 5.6.6.1: Ranking of dates by revenue

A SalesRecord is associated with 6 attributes - Date, ItemName, QuantitySold, Price, Revenue and IngredientUsed.
The success of the auto-ingredient update mechanism is subjected to the following conditions:

1) ItemName exists in the Menu.
2) The required ingredients to make one unit of ItemName is specified in the Menu.
3) The required ingredients exist in the Ingredient list.
4) There are sufficient ingredients to make QuantitySold units of ItemName in the Ingredient list.

This mechanism is aided by methods from the Menu and Ingredient components, all of which are exposed in the Model interface. Given below is an example scenario and how the auto-ingredient update mechanism behaves at each step.

Step 1. The user executes record-sales d/11-01-2018 n/Fried Rice q/35 p/5.50 command to record the sales volume of Fried Rice on 11-01-2018. A SalesRecord would be instantiated based on the command arguments given.

Step 2. RecordSalesCommand will request for the item Fried Rice from Menu. This is done through the Item findItem (Name) method given in Menu component. This also checks if condition 1 is satisfied.

Step 3. RecordSalesCommand then proceeds to request for the required ingredients to make a unit of Fried Rice from Menu. This is done through the Map<IngredientName, Integer> getRequiredIngredients(Item) method given in Menu. This also checks if condition 2 is satisfied.

Step 4. With the required ingredients per unit data now at hand, RecordSalesCommand will compute the total ingredients used in making 35 units of Fried Rice. The IngredientUsed attribute in SalesRecord will then be updated.

Step 5. RecordSalesCommand will then pass the computed IngredientUsed to Ingredient component to request for an update of ingredients. This is done through the void consumeIngredients(Map<IngredientName, Integer>) method given in Ingredient component. This checks for condition 3 & 4.

Step 6. The SalesRecord is then finally added into UniqueRecordList via the void addRecord(SalesRecord) method given in Sales component of Model.

The following activity diagram (Figure 4.4.1.1) summarizes what happens when a user executes record-sales command:

Figure 4.4.1.1: Activity Diagram for record-sales command

The display sales report mechanism is facilitated by the Model, UI and Event components of the App. A SalesReport class encapsulates the attributes of a sales report to be displayed. The sales report is internally generated by generateSalesReport(Date) in UniqueRecordList. It then propagates up the Model call hierarchy to getSalesReport(Date) in ModelManager, which is exposed in the Model interface.

The following sequence diagram (Figure 4.5.1.1) illustrates how the display sales report operation works when the user enters display-sales 25-12-2017:

Figure 4.5.1.1: Sequence Diagram for display-sales command

The sequence diagram for the "Parse Command" reference frame above is shown below in Figure 4.5.1.2:

Figure 4.5.1.2: Sequence Diagram for "Parse Command" reference frame

Given below is an example usage scenario and how the display sales report operation behaves at each step.

Step 1. The user executes display-sales 25-12-2017 command to request for the sales report dated 25-12-2017. The display-sales command calls Model#getSalesReport(Date), passing in the date "25-12-2017", and gets the generated SalesReport in return.

Step 2. The display-sales command then raises the DisplaySalesReportEvent event, which also encapsulates the generated SalesReport in step 1.

Step 3. The EventsCenter reacts to the above event, which results in handleDisplaySalesReportEvent(Event) in UI’s MainWindow being called. This method instantiates a SalesReportWindow object by passing in the SalesReport to its constructor. This SalesReportWindow acts as the controller for the sales report window.

Step 4. The SalesReportWindow is then initialized and displayed on user’s screen.