MySunBuddy is a peer-to-peer platform to facilitate the purchase and selling of solar net metering credits.

The scope of this challenge is to build MySunBuddy platform frontend/backend with basic UI bootstrap theme.

Challenge Requirements

You will address the following in this challenge :

UI Requirements

We don’t have a UI prototype or a design, you will build simple website UI :

• - Use default bootstrap UI theme for the look and feel.

• - The UI should look good.

• - Use AngularJS or JQuery as frontend JS library.

Database Schema

This is a proposed schema, you can make any suggestion that is needed :

• - Users table

  • - username

  • - password

  • - email address

  • - zip code

  • - phone number

  • - tou (termsOfUse) : true.

  • - role : seller or buyer

  • - credit

• - file

  • - file_location

  • - user_id

• - Deals table

  • - seller_user_id

  • - buyer_user_id

  • - price

  • - quantity

  • - demand_date : represents the month the deal is covering

  • - transaction_date

  • - status (Pending Seller, Pending Buyer, Deny by Seller, Deny by Buyer, Approved, Completed)

Pages and Functionality Requirements

1. You will build REST API backend that communicates with frontend AngularJS code.

2. Signup Page

   1. - Information to be collected are :

      1. - Type (Seller, Buyer) : user must select a type, and this type will be stored as a field in User table.

      2. - username

      3. - password

      4. - zip code

      5. - e-mail address

      6. - phone number (optional)

      7. - communication preferences (email or sms)

      8. - If user picked “Seller” type then the following additional fields get displayed:

         1. - Utility Bill upload form - to upload file

         2. - Panel Type drop down - possible values should be taken from module_type

         3. - System Capacity input field  - possible range : 0.05 to 500000

         4. - Using the the Panel Type, System Capacity and Address :

            1. - Use PVWatts V5 API to calculate the seller solar production.

            2. - Panel Type corresponds to module_type in the api.

            3. - System capacity corresponds to system_capacity input parameter in the api.

            4. - Address corresponds to address input parameter.

            5. - We need “ac_annual” response field which is in kWh.

         5. - Calculate “Credits to Sell” using the following formula:

            1. - (ac_annual - ExpectedNetDemand*SafetyFactor)

            2. - ExpectedNetDemand should be read from configurations, the value should be 8000kWh in this challenge, we will replace it with a value when integrating with GreenButton in future.

            3. - SafetyFactor should be a configurable value, i.e. “1.1”

         6. - Once we determine the “Credits to Sell”, the user should be prompted to agree to the amount, and a warning message that “It may sell more than they use, causing them to have to pay an electricity bill.”

         7. - Give user a range field to change that value where max value is credits to sell and lowest value is 1%.

         8. - The credits to sell should be stored in database.

      9. - If user picked “Buyer” then we assume the annual usage is 8000 kWh, we will display following for the user :

         1. - Display a range option with four ranges, 25%, 50%, 75%, and 100% of buyer net monthly demand which she will seek to offset using net metering credits.

         2. - This “credits to buy” information should be stored in database.

   2. - Form should include ‘agree to terms of use’ and this check should be added to backend and user model.

   3. - Proper validation and error handling must be addressed in frontend js and backend code.

   4. - Send verification email to user, user should not be allowed to login until they verify their account.

3. - Login

   1. - Login should be either by email or username. The same endpoint should accept email or username.

   2. - On successful login user is redirected to Seller page if user is seller or Buyer page if user is Buyer.

   3. - Add links to forgot password and sign up in this page.

4. - Forgot and Reset Password

   1. - The Forgot password logic should be as follow :

      1. - User provides username or email to ask kor reset password email.

         1. - If user with email exists or not exists, send an email :

            1. - if user exists then reset password email should be sent.

            2. - If user with email does not exist then send email to user that no user associated with the email and give them a signup form.

         2. - If user with username exists then send reset email password.

         3. - There should be expiration date for the reset password.

         4. - Add validation for email in frontend and backend.

      2. - Email templates and email options should be configurable.

   2. - The reset password email

      1. - Validate that reset password for that user has not expired yet, if expired then display friendly message that it was expired.

      2. - The reset password form should have two password input fields, one for new password, and the other one to re-type the new password.

      3. - On successful reset redirect user to login page.

      4. - Add proper validation for emails in both frontend and backend.

5. - Logout functionality

   1. - For logged in user there should be logout button always in header.

6. - Account Settings Page

   1. - There should be a link to Account Settings page from header.

   2. - User should be able to update the following information :

      1. - All User Table information.

      2. - For Buyers they will get percentage of net metering they want to buy. This will be the range field same as in registration.

      3. - For Sellers they will get percentage of net metering they want to sell. This will be a range field same as in registration.

7. - Seller Page

   1. - This is landing page for Sellers.

   2. - It will show two tables, one for pending sales and the other for past transactions.

   3. - Pending deals table :

      1. - Read from deals table where the sales_user_id = to seller id and status “Pending Seller”.

      2. - There should be an action column with two options : Approve/Deny.

         1. - If Deny then update the deals table to “Cancelled By Seller”.

         2. - If Approve is clicked then

            1. - Send email to buyer about the deal

            2. - Update status to “Pending Buyer”

   4. - Past transactions table :

      1. - This should load all deals where status is not Pending Seller or Pending Buyer status, and sales_user_id = the user id.

8. - Buyer Page

   1. - This is the landing page for Buyers

   2. - It will show tables, one for pending purchases, and the other for past transactions.

   3. - It will also show historical dollar amounts, savings, GHG impact.

   4. - Pending deals

      1. - Read from deals table where the buyer_user_id = to user id and status “Pending Buyer”.

      2. - There should be an action column with two options : Approve/Deny.

         1. - If deny then

            1. - update the deals table to “Cancelled By Buyer”

            2. - send email to seller notifying about cancellation of the deal.

         2. - If “Approve” is clicked then

            1. - Send email to seller about the deal.

            2. - Update status to “Approved”.

            3. - Send email to both seller and buyer about the success of the transaction.

   5. - If user has past purchases we will display a google map with pins indicating where the energy are coming from.

9. - Buyer/Seller matching job scheduler

   1. - The job scheduler will match qualifying partners based on location and quantitative constraints :

      1. - Algorithm to match partners - We will implement a first in first out algorithm to do matching between seller and buyers, the matching will work like this :

         1. - Exclude buyer/seller that already have matching/deals for current month that cover the buyer/seller buy/sell credits.

         2. - Group sellers and buyers by ISO-load Zone and utility provider using buyer/seller address. So for each user (buyer/seller) retrieve the zip code and find the ISO-load Zone and utility provider

            1. - You are provided with sample sheet for ISO-zones utility provider and zip codes, create a lookup table in database that contains same information, and use it to retrieve load zone and utility provider of the provided zip code, you can generate more test data if you want to.

         3. - Sort buyers by create date (represents the registration date)

         4. - Sort sellers by create date (represents registration date)

         5. - For each buyer :

            1. - Get required remaining buying credit to cover.

            2. - Based on remained selling credits from all sellers, calculate number of sellers needed to cover the buyer remaining buy credits.

            3. - For each matching we create a deal record in database with following information :

               1. - seller_id

               2. - buyer_id

               3. - quantity

               4. - price

               5. - demand_date (represents current month date)

               6. - transaction_date

               7. - status  : “Pending Seller”

            4. - Remove seller that covered all selling credits from array.

General Note

• - Logging, validation, error handling must be properly implemented.

• - All sensitive information, and environment specific information should be configurable.

Hosting

It is preferred if you host your solution in Heroku.

Python Framework

• - Use Django REST Framework to build the REST API backend.

• - Use ORM module for database, either django rest one or sqlalchemy.

Technology

• - Python version 3.x running on Ubuntu

• - Postgres 9.4

• - Django 1.8.x

• - AngularJS

• - Bootstrap

Abstracting and Design Patterns

Please make sure to create helper/interface to include the common code/functionality.

Also please make sure your design is flexible, use facade design pattern and adapter design pattern (and any other proper design pattern) to enable future extensibility of the solution.

Coding Standard

Follow python coding best practices : PEP 8 for the main text, and PEP 257 for docstring conventions

Documentation

Your solution must be well documented.

Readme

Provide a detailed readme file using Markdown language with following information :

• - Overview

• - Setup Prerequisites

• - Configurations

• - Deployment

• - Any details about any limitations of your solution.

Please note, we're judging this competition not just on the code, but also on the quality of the documentation, and ease of use.

Final Submission Guidelines

Submission Deliverables

Below is an overview of the deliverables:

• - All source code and files that implement above requirements.
• - README file.
• - Detailed Verification steps document.

Final Submission

For each member, the final submission should be uploaded via the challenge detail page on topcoder.com.