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:
-
Documentation:
-
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 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.
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
andTransactions
classes. -
When
AddressBook
is loaded, it creates an object of theSalesHistory
class using theSalesHistory
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, theAddTransactionCommandParser
processes this command and creates an object of typeAddTransactionCommand
. -
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.
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 theReminders
classes. -
When
AddressBook
is loaded, it creates an object of theSalesHistory
class using theSalesHistory
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 aTimeIdentifiedClass
-
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.
The Reminders are stored on a TreeMap , similar to the Transaction , in SalesHistory
|