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
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
