Campaign Finance Report

Team Name

Team-404

Timeline

Summer 2021 – Fall 2021

Students

  • Nirmal Badal
  • Sunny Chochchhe Shrestha
  • Hamza Alwani
  • Hunter J Flory
  • Meghana Guntaka

Sponsor

Dr. Christopher McMurrough

Abstract

The Campaign Finance Report Generation is a web application, which will allow the end-users to keep track of the donation records, automate the generation of reports and fill out the finance report manually or automatically when applicable. ​

The users will be able to fill the Campaign finance report manually or generate the report by uploading their documents. Users of this application will be able to create an account, upload files, create new projects, generate and track donation reports. The report generated by using the uploaded documents will be available to the user in pdf format.​

Background

Election campaigners face a lot of difficulty during an election campaign, which includes manually creating and tracking the donation reports and itemizing the donations. Physically entering the data, keeping track of all campaign donors and donations, and manually filling out various campaign forms add more work and pressure to the campaigners and their management committees. ​

So, to try to solve the problem of generating and keeping track of the donation records, and manual filling of campaign forms, we developed a web application that will track the donation information and automate the generation of reports with the help of the uploaded files by the users. The system would also act as a platform where users would be able to fill out each schedule of the finance report, manually or automatically.​

Project Requirements

  1. Account Creation
    • Users must be able to create an account associated with the project database.
  2. Login
    • Users must be able to log in to the server using the account credentials they create. This will allow them to access previous work and keep track of account-specific progress.
  3. Account Authentication
    • User login should be authenticated using an authentication API like Google or Facebook. 
  4. Account Progress Saving / Updating
    • Users should be able to access work on schedules they have previously completed and view / edit schedule data they have worked on in the past. This requirement dictates that edits to schedules and uploaded files need to be saved to ensure continuity between use sessions. 
  5. Spreadsheet As User Input
    • The application must accept as input common spreadsheet data types such as .xls, .csv, etc. The development team will expand the scope of what files are supported later. 
  6. Independent Completion of Schedules
    • Users may work on any schedule in the finance report they like. They do not have to be completed in any certain order, or at all. This requirement includes all schedules and the cover sheet of the Texas campaign finance report.
  7. Exporting of Schedules as .PDF
    • Users may export a collection of any independent schedules including cover page or a complete report AS .PDF file. 
  8. Conversion of Spreadsheet Data to JSON Data Type
    • A module must exist that converts data parsed from spreadsheet user input into JSON data that can be passed to each schedule generator. This is extremely important as JSON is the data type that will be ‘passed around’ to each module of the system.
  9. Conversion of JSON Data to .PDF
    • A module must exist that converts JSON data elements to a completed schedule PDF. This module will be used across each ‘schedule generator’ module to simplify development. For example, data from a spreadsheet is parsed and converted to JSON. The JSON data is sent to each relevant ‘schedule generator’ and passed through this requirement module to reassemble the data and export it as a PDF in the form of a finance report schedule (or cover page).
  10. Document Merger
    • This module assembles all completed PDFs and exports the completed finance report / cover page / schedules. 

System Overview

The application begins the implementation of three different layers: User Layer, Conversion Layer, and Output Layer.​​

  • The first layer is the User Layer. This layer consists of three subsystems which then pass the data they collect from the user or the Database into the Conversion Layer. This layer consists of five different subsystems with different functions assigned to them. ​
  • The user input data is converted  into json format by the Conversion Layer and is transmitted to the Output layer. ​
  • The Output Layer consists of one subsystem which is responsible for converting the json output from the Conversion layer into required PDF format output.  The figure below shows how data flows into different subsystems and each layer interacts with each other within the application.​

Results

Campaign Finance Report Generation was a  CSE Senior Design project sponsored by Dr. Christopher McMurrough. We were successfully able to automate a tedious task into a simple file upload task. We had some setbacks during our project development because of which we were unable to fulfill some of the requirements. Overall, we were able to complete the most critical tasks. Team-404 would like to thank our Professor, Chris Conly, and our sponsor,  Dr. Christopher McMurrough,  for their guidance throughout the project. ​

https://drive.google.com/file/d/1buED_eEVZXTQzgGEX0vHBJ-pGNHWD-II/view?usp=sharing

Updated: https://drive.google.com/file/d/1oOFp4RNvtrrEhiXcmH1jO9m9sFRfSDr7/view?usp=sharinghttps://drive.google.com/file/d/1oOFp4RNvtrrEhiXcmH1jO9m9sFRfSDr7/view?usp=sharing

Future Work

Future work on this project will most likely be in the form of graphical and user interface development. As it stands, the project is purely functional and needs a lot of work in order to commercialize. A more robust user interface might include a more feature-complete login system that allows users the ability to change their password, a visually pleasing web interface that is not barebones, and some form of user guidance that helps in the process of selecting and uploading the required files. Another planned feature that was scrapped is the Error-Checking feature: a protocol that might be offered at a premium that guarantees users are not uploading erroneous data in their spreadsheets to avoid incurring a fine when submitting the completed reports.

Project Files

Project Charter: https://drive.google.com/file/d/1KJMG0OpNQPY946SkQQt5Vy01f8tQdjEa/view?usp=sharing

System Requirements Specification: https://drive.google.com/file/d/1V3Qs0wqi28kbUMdImIZGIVYTh_cZGmz3/view?usp=sharing

Architectural Design Specification: https://drive.google.com/file/d/1ZzcCJ62tWeK6h4KLVJLbFn9iBEE3y4PI/view?usp=sharing

Detailed Design Specification: https://drive.google.com/file/d/1j0CWMbetptZXrp4xLsCVpXSIB_dW2r1T/view?usp=sharing

Poster: https://drive.google.com/file/d/1csTwvI7QIHU0S4x_EJqBeeNI2G1Ep3mX/view?usp=sharing

References

Liu, S., and Bobrow, J.E., “An Analysis of a Pneumatic Servo System and Its Application to a Computer-Controlled Robot,” ASME Journal of Dynamic Systems, Measurement, and Control, 1988, Vol 110 pp 228-235.

nxb9374