Readme Update

We should update the readme for the receipt scanner repository.

Features

The readme should have documentation for the entire repository and project.

• Motivation
• Course
• Project Description
• Contributors
• Version History
• Release Notes
• Installation and Building
• Quick Start

We should show a listing of the most recent receipts to the home page. This will fill the screen space and provide useful quick access to this information.

In some cases this means we will need to pop the current screen as we navigate, preventing navigation back to the drawer or to the custom report selector.

Harvey Siy wants us to email a set of deliverables to him for our upcoming class meeting. He's asked for our team composition, our team ideas, and our shared project folder. The shared folder has been shared with him already. We may want to consider sharing our Github with him as well.

Information for the deliverable:

Shared Project Folder: Google Drive - Seal Team 6

Team Composition:

1. Project Manager - Joey
2. Scribe - Luke, Chandler, Joey (Weekly rotation)
3. Architect - Luke
4. QA - Chandler
5. Tech Support - Savon
6. Software Development - All

Project Ideas:
Catalog receipts within a database.
Parse receipts from a picture.
Create an integrated mobile application to use a phone camera to scan and parse receipts.
Use a cloud approach to offload processing requirements from the client device.
Provide a populated receipt form from the receipt scan.
Allow for manual entry.
Parse for totals and vendors.
Parse itemized expenses from receipts.
Generate visual reports of receipt-based expenditures.
Integrate receipt data with larger context financial data.
Create financial app integrating receipt parsing, expenditure tracking, budgeting, and planning.

Let's investigate and compare GitHub's project management tools with Trello.

We'll need a view for the user to select whether to upload, scan, or enter the receipt data. This might just be an overlay on the page it was selected from or it may be a dedicated page of its own.

Will be selected from menu that shows up on the bottom of the screen when the add button is hit

Complete the UI for reports page and functionality (getters from database)

We should add unit tests to validate each of the database API methods.

Something we should probably decide at our next Sunday meeting. I've done a bit of looking into Flutter and it's difficult to tell if it would really be harder or easier to learn its respective language, Dart, over Kotlin for Android Studio. I think we will learn a lot either way, and perhaps not having the app on iOS isn't a big deal. I will do some more digging on the Flutter side before Sunday!

Just get it put into our app with maybe some example usage

When the scanner reads a DateTime from the receipt that is out of range, it is able to populate the date field but it cannot be edited. This is due to the constraints set in the manual entry's showDatePicker function. We should either expand these values by default or set up a handling system for this scenario.

This should pull a receipt from the database and display it to the user. It might be a good idea to look at the manual entry page and borrow / abstract some of the functionality.

Separate tickets for implementing these screens

If we're going to use GItHub pages like what Siy describes in the submission requirements document, we should add a /docs folder for GitHub to use. Thankfully the docdart will do this automatically. What we will need to do is run the doc tool on the final product and commit it into our master branch for the pages to pick up on.

We'll need to create a process for creating reports within our application. Reports will need to reference several receipts from the database, perhaps by using sql queries, to aggregate total and other information by date or by other information. This case will need to add logic to our database api and processing for generating a lightweight report to display on the reports page and, possibly, on the home page.

Stylize & add a logo

There might've been a fourth option but can't remember. I figure these pages can be done together as I assume it's just calling the database in different ways to get the data that populates the page.

For milestone 1 we didn't worry about documenting code as we added it. We should update the documentation to make future development and integration easier.

Our application will need to interact with our database. For this we should create an API with simple methods for adding records, retrieving records, updating records, and deleting records. These will need to be prepared statements to avoid potential SQL injections or other attacks against our users.

Not sure about where/how we'll go about doing this. We'll need to research what database to use and where to put it.

There could be a few different ways of doing it. For date, there would need to be a lot of different case handling. For total, maybe it's just the biggest decimal separated number it finds. Afterwards, an API call to the database is made.

We need a home page to display quick links and data to the user.

Will just include field for total and date initially, perhaps retailer later. This page will then hit database API in the same way as scanning would

Probably very similar to the scanning functionality, just that it cuts out the first part of actually scanning the receipt, will hit API at end.

We just need an object to represent the receipt within our system. This will be used to store the form data generated by parsing receipts, accept manual input, and to save to our database. This will also be used to view data when we pull from the database, eventually.

We need a page to view/edit the receipt data generated by scanning a receipt image. This should display the receipt's data, allow editing either directly or by opening an edit mode, and allow the user to save the entry.