The project evolves around an online publication application. Readers are either undergoing a trial, or paid subscribers.
**Currently** all trial and paid members can print anything, as many times as they want, using a print article button, which effectively pops up a windows with a printer friendly version.
Additionally, readers can email an article to one nominated friend.
**With this modification,** all articles will be locked from printing or emailing to friend(s). Effectively, the print and email buttons will be removed, until the member unlocks them individually (using some 'unlock' link/button).
Contact jobs (at) [url removed, login to view] with any questions prior to bidding!
Once unlocked, the article can be printed as many times as wanted, however unlocking an article will trigger a fee, charged only once per article. All articles carry the same fee.
In order for members to agree to this new fee schema, the first time they try to unlock an article, they will be displayed some message asking them to agree with the new terms. This information will be saved as a timestamp on the members record.
**Once a month,** the editor will manually trigger a process which will send an email to every member with an account balance above X$ (set in global config file), keeping in mind that the first X unlocks are free (again, set in config file).
Once the email is sent, a new 'billing cycle' is started and counts articles being unlocked by members from 0 again. Also, a report of invoices sent has to be displayed and includes Invoice number, Invoice date, Amount owing, GST, Individual invoiced (name), Organisation name, Due date (-> X days from invoice date, set in global config). Additionally, this information can be exported to a CSV file.
The email sent will notify the member of the outstanding balance and provide a link to a page showing an account history with previous invoices, paid and outstanding (and a payment date for those paid). Those outstanding invoices will provide a 'pay through paypal' link, which will be fully integrated (going to paypal, and back from it, setting the member's invoice as paid).
**From an admin point of view,** we also require the capability of searching/viewing invoices as well as a 'process payment' option, which will simply mark the invoice as paid, total paid, payment confirmation number (could be a cheque number).
* a new page has to be added to dispatch an email once a month;
* a new page has to be added to display a member's purchase history (effectively a list of articles, it + title, and a total, invoice number and 'email sent' date if generated, payment date and a paypal confirmation number if paid);
* finally, a 3rd new page has to be added to give the admin the capability of marking an invoice as paid hence recording the amount paid, payment method, date and confirmation number manually
**From a design/front end point of view:**
* article display will have to be modified to have an 'unlock' button, or a 'print this article' and 'send to friends' buttons displayed if the article was unlocked before.
* a new 'copyright invoices' page will have to be created,
* a return page from paypal will have to be created to handle the 'payment processed' return call from paypal, saving some information then redirecting to the previous 'copyright invoices' page which will display some 'thank you' notice.
* an 'invoice' page will have to be created, with the company logo and address as well as details of the unlocked articles (title) and dates - this will all be printable by the member.
* a articles_unlocked table has to be added
* an articles_unlocked_invoice table has to be added
* the members table will have to be modified.
**Good to know before you bid:**
* We are a development/consultancy company, and can help if you are stuck with something, however we have no time to help out every hours of the day, every day of the week!
* This application lifecycle is approaching an end, hence code matters, but we're not fuss about it;
* We did not write the application, and for we have maintained it a fair bit in the past months, we know it has some crap in it, we'll do everything we can so that this doesn't get in your way (we know where to be careful!);
* It might be worth knowing that whoever helps out with this is likely to have valuable application knowledge to help out with the rebuild of the application scheduled for September;
**Will be provided:**
* all graphics/buttons required;
* the full structure / truncated database;
* the entire application files, to replicate the running app locally in your environment;
* a bit of help with the current application, structure and code to get you running, for instance, you will know precisely what files have to be modified;
* Any copy needing to be written will also be provided (eg. the 'new printing agreement' for members to agree on)
**To be delivered:**
1. The current article rendering has to be modified to display a unlock button instead of print and email to a friend. Once unlocked, this page as to display the standard/existing print and email buttons;
2. When clicked, the unlock button has to open a new popup window, displaying the new printing agreement; a timestamp will be saved to the database with 'OK', or 'I Agree' is clicked.
4. a new invoices pages has to display to the current user a list of previous invoices and their appropriate details. The user then has two choices: view and pay (if not paid already).
5. Then when clicking to view an invoice, the user is displayed a properly formatted invoice (canvas provided) with a details of unlocked articles for this invoice, and information like paid date (if any), etc.
6. When clicking the 'pay now' link, the user is sent to paypal for a fully integrated transaction (the user will be sent back from paypal, and the payment amount, trx number and other details saved. The paid invoice will also be considered paid from this point forward. **There will be no *pay multiple invoices* option** (sample code provided for paypal integration)
7. the Administrator needs a search + search results pages. The search will offer search options such as 'outstanding invoices', 'paid invoices', 'all invoices', 'user invoices (searches through user names, emails for matches)
8. The result page will feature a 'export to CSV' link, exporting results to a Excel-compatible CSV file (sample code provided).
9. The result page will also feature a 'mark as paid' button (for unpaid invoices) which sends to a new page, recording a payment date, and reference number. No multiple/partial payment will be required.
10. Finally, all invoices will feature a 'view' link which (new window) redirects the administrator to the same 'view this invoice' as the user (as described previously)
11. a last page will have to be created in order to dispatch the email to subscribers. the email content will be provided. This page could quite simply be integrated with the search page (one option would be to find users with a current balance above X$, with a send invoice button) a method to send email already exists.
the **code to make the above work** will be your responsibility. Additionally, the database will have to be modified, by you or us depending on your terms and bid). Any modification to existing tables has to be recorded (tablename, added field, fields details such as datatype, length), any added tables also has to be recorded (new tablename). This is solely because these will have to be replicated on the production application.
You will not have to **update the current application** however you will have to submit your changes to a SVN server so that we know **what files was modified / has to be updated** and be available to help if your code doesn't work on the server for some reason.
**Required:** 1) Complete / fully-functional working program(s) as well as complete source code of all work done. 2) Deliverables must be in ready-to-run condition, 3) Buyer will receive exclusive and complete copyrights to all work purchased. (No GPL, GNU, 3rd party components)
Win 2003 Server is the production platform, however there is no reason why this shouldn't work on a Development Windows XP machine.
The application is classic ASP/MsAccess, so any development machine will have to be capable of dealing with those.
You will have to submit your final changes to a SVN server.