GSOC ideas. Other ideas? Any mentors?

[Chris Travers <..hidden..>]

Hi everyone

I figured I would get the ball rolling regarding GSOC ideas,  These are ones I am willing to mentor.  Are there any others who are interested in mentoring?  Any other projects to list to this?

I Framework Changes

1.  Next Generation DB Interface

Difficulty:  Medium

Skills needed:  Medium Perl skills, basic PostgreSQL.

Complete the SODA.pm, and ensure that there is an interface for serializing objects into csv tuple notation for PostgreSQL (i.e.  a LedgerSMB::Entity object of {control_code => 'A1234', name => 'Test Co.', country_id => 232} becomes '(,"A1234","Test Co.", 232)').  Note that nested data structures must be supported, such as '(1234,"JE-12345","This is a test of the journal entry system.  Have fun.  See, it's not so hard", "{""(1234,23,1000,t,t,,,,)"",""(1234,43,-900,t,f,,,,)"",""(1234,56,-100,t,f,,,,)""}").  This should be relatively simple with a CSV generation module, with the typeutils PostgreSQL extension (on Google Code) and so forth.

II APPLICATION CODE CHANGES

1.  Rewrite payment processing code, refactoring and merging the code behind the two interfaces.  

Difficulty:  Moderate, requires good design sense

Skills:  SQL, PL/PGSQL,. Perl

The first step would involve refactoring the current db routines and unifying them.  If time allows the Perl logic would be unified as well.  The current db routines are both somewhat complicated and the overpayment logic should be broken out and made compatible with voucher/batch workflows.  If time allows, the Perl modules and user interface should be refactored to adhere to these changes.  These would be written to current database interface specs and current database design.

2. Financial Database and Stored Procedures, in line with next-gen db access spec.

Difficulty:  Easy to Moderate

Skills:  SQL, Relational design, PL/PGSQL

The database schema (currently used for template transactions) would be finalized and reviewed, stored procedures written for basic financial document operations (post transaction, search transactions, void transaction, reverse transaction).  If time allows reconciliation routines could be written.

3.  Invoice Pipeline Stored Procedures, in line with next-gen db access spec

Difficulty:  Moderate

Sills:  SQL, Relational design, PL/PGSQL

This will need to revise the existing db schema (used for template transactions) for production use of orders and invoices,  Will need to add to it as necessary.  Will also need to add inventory movements to it.  Will need to add stored procedures for basic inventory invoice/order routines including saving invoices, voiding invoices (marking voided, and posting a voided reversal), recording shipments, and generating related documents (invoice from part of a sales order).

III  USER INTERFACE CHANGES

1.  Better CRM interface

Difficulty:  Easy to moderate

Skills:  Perl, HTML, CSS, JS

The current customer management interface could use some usability and aesthetic improvements.  This will likely require some combination of _javascript_, HTML, and Perl.  Current functionality must be preserved.

2.  New AR/AP Interface

Difficulty:  Easier

Skills:  Perl, HTML, CSS, JS

We need to replace the current spaghetti code interface with a template, with AJAX for account numbers, adding new lines, and customer searches.

3:  New Invoice/Order Invoice

Difficulty:  Moderate

This will require reading through the spaghetti code, replacing it with a template, with AJAX for parts lookups, adding new lines, and customer searches.

Any others to add to this?  Any mentors willing to volunteer? (I can help of course)

Best Wishes,

Chris Travers