PROJECT: Inventarie Pro


Overview

Inventarie PRO is for self employed business owners who prefer to use a desktop app for managing inventory. More importantly, Inventarie Pro is optimized for those who prefer to work with a Command Line Interface (CLI) while still having the benefits of a Graphical User Interface (GUI). If you can type fast, Inventarie Pro can get your inventory management tasks done faster, simpler and easier than traditional GUI apps.

Summary of contributions

  • Major enhancement: added Sales History feature

    • What it does: This feature allow each users to store their respective transaction histories, and also to set reminders for themselves to help manage the day-to-day affairs of the provision shop.

    • Justification: This feature provides life to the application by allowing the user to actively keep track of the affairs of the provision shop. This helps the product achieve 'real-time' status as it reflects the state of the shop, providing the provision shop owner the ability to use the data provided by the app to plan for and manage the inventory.

    • Highlights: This enhancement required a careful analysis of both user requirements and the existing code base. Code base modifications included significant changes to Model, Storage, and the creation of SalesHistory class with other associated classes.

  • Minor enhancement:

  • Code contributed: [Code Dashboard]

  • Other contributions:

    • Project management:

      • Managed releases v1.1 - v1.4 on GitHub

      • Enforced GitHub standards and helped team follow them.

    • Enhancements to existing features:

      • Updated storage to accommodate unique individual sales histories for each user and file storage for the same (pull request #106)

      • Improved test coverage for the added features (pull requests #109, #159, #202)

    • Documentation:

      • Made updates to user and developer guides (pull requests) #60, #120, #159

    • Community:

Contributions to the User Guide

Given below is my major contribution to the User Guide

Sales History

Add a transaction: transaction

Format: transaction pr/PRODUCT_NAME pr/PRODUCT_NAME …​ pr/PRODUCT_NAME

Adds a transaction to the record for the given day. The time of the transaction, names of the products, and individual product quantities will be stored.

Examples:

  • transaction pr/Apple pr/Banana pr/Cherries

View the latest transaction: latest

Format: latest

Displays the details of the latest transaction.

View all the transactions for a given day: alltransactions

Format: alltransactions time/<yyyy/MM/dd>

Displays the timings for all the transactions made on a specified day.

View the details for a given transaction: viewtransaction

Format: viewtransaction time/<yyyy/MM/dd HH:mm:ss>

Displays the details of a transaction made on a given date and time.

  • It is important to note that there must be a single space between 'dd' and 'HH' in the command format.

Add a reminder: setreminder

Format: addreminder time/ <yyyy/MM/dd HH:mm:ss> message/<The reminder message>

Sets and stores a reminder. The reminder notification will appear once the reminder time has elapsed.

  • All reminders must have unique times.

  • There must only be a single space between "dd" and "HH" in the command format.

Examples:

  • addreminder time/ 2018/07/30 18:20:31 message/Throw rubbish

  • addreminder time/ 2019/11/22 21:31:11 message/Milk delivery

View due reminder notifcations: duereminders

Format: duereminders Displays all reminders that are still due.

View all reminders: allreminders

Format: allreminders

Shows all reminders that are in the system.

Remove a Reminder

Format: removereminder time/<yyyy/MM/dd HH:mm:ss>

Removes a reminder in the system. There must only be a single space between "dd" and "HH" in the command format.

Examples:

  • removereminder time/ 2018/10/26 12:30:00

Contributions to the Developer Guide

_Given below are sections I contributed to the Developer Guide

Storing Transactions Feature

Current Implementation

  • The storage of transactions is facilitated by the SalesHistory and Transactions classes.

  • When AddressBook is loaded, it creates an object of the SalesHistory class using the SalesHistory default constructor, which uses data read from that specific user’s saleshistory .xml file. When the file is not found/not in the correct format, the user will begin with an empty saleshistory.

  • When the user inputs transaction pr/<product name> pr/<product name> …​ pr/product name> into the CLI, the AddTransactionCommandParser processes this command and creates an object of type AddTransactionCommand.

  • LogicManager receives this command object and executes it. In its execution, the saleshistory is updated with the required transaction and raises an event for the user’s saleshistory file on the hard disk to be updated.

TransactionSequenceDiagram
It is important to note that the SalesHistory class stores each Transaction on a TreeMap, where each Transaction has its transactionTime as its key. This is to facilitate quick access to any transaction on a given day for large number of transactions, and to maintain the Transaction objects in order of their creation times within memory.

Alternative Implementations

Currently, the Transaction objects are stored on a TreeMap to maintain their chronological order in memory. However, should this prove non-essential, this will be redone on a HashMap to facilitate quicker access and easier handling in the code. Alternatively, using the ObservableList may be sufficient if it turns out the sales volumes are small.

Storing Reminders Feature

  • The storage of reminders is facilitated by the SalesHistory and the Reminders classes.

  • When AddressBook is loaded, it creates an object of the SalesHistory class using the SalesHistory default constructor, which uses data read from that specific user’s saleshistory .xml file. When the file is not found/not in the correct format, the user will begin with an empty saleshistory

  • When the user stores a reminder, the reminderTime is used as the key. Hence, Reminder is a TimeIdentifiedClass

  • Each reminder is marked as not yet due for completion at the time of their creation.

  • Every second, threadduereminders command is sent from CommandBox. This compares the current time against the stored reminder times to determine which reminders have reached their deadlines. If there are any reminders due, the user receives a message for the same, and the reminder is marked as viewed by the thread.

remindersequencediagram
The Reminders are stored on a TreeMap, similar to the Transaction, in SalesHistory