Re: Draft 2 of Direction Statement

[Alejandro Imass <..hidden..>]

Hi I sent this at about 10:20 EST but never got a mail back from the
list. Perhaps it never went through:

Sounds good. Just a few thoughts that we have discussed in the P2EE and
SOLVE ERP projects:

On Mon, 2006-09-25 at 17:51 -0700, Chris Travers wrote:
> Goal 1:  LedgerSMB as Business Infrastructure
> In order to meet changing needs of a diverse market it is important
> that as LedgerSMB grows, that it becomes an easily extensible (and
> even in some cases invisible) part of the data infrastructure of a
> business.  In essence, it must eventually be possible to separate the
> web user interface from the software as a whole.  Important
> requirements we should strive towars are:
>     1)  Separation of mechanism from interface

In fact, IMHO the UI should be split in two layers. One generic UI layer
that defines "what" needs to be done, in XUL, UIML or similar and a
presentation layer that transforms the generic UI into a GUI for the
web, a handheld, text interface, or whatever. The advantage is that the
generic UI can be directly influenced by the business process, so you
can contextualize the "screen" for the given business process that the
user will be executing. This eliminates completely the old paradigm of
all screens being the same or similar, a paradigm that was already
weakened by web apps in general, but for some reason FOSS ERP developers
can't seem to get off their heads. One of the things I liked initially
of SL was the dynamic placement of buttons regarding context, I though
it was quite cool; most "ERPs" still depend on CRUD and BREAD bars at
the top of the screen.

You can download a presentation I gave on this for the SOLVE "ERP"
project. Look especially at slide 14 (in the English version all slides
are commented):

http://erp.solve.net.ve/download.php?list.2


>     2)  Generic, reusable components wherever possible

When we sat down to define P2EE goals we thought that extending,
complementing or creating a new business namespace in CPAN and package
each of the generalized components into CPAN modules. In this sense, we
thought of POE-based application components that could run distributed,
stand-alone or connected to other apps (offering a wide range of
inter-operabillity mechanism offered by POE and POE Components). In the
end, I don't know how practical or feasible this is, but it would
definitively 1) break a lot of paradigms around ERP applications, and 2)
is more consistent with the greatness of Perl, CPAN and it's philosophy
in general.

>     3)  Scriptability from local and remote programs
>     4)  Extensibility of the core logic in forward-compatible ways
> 




On Tue, 2006-09-26 at 12:21 -0700, Chris Travers wrote:
> Hi-- anybody have anything to add or points to bring up?
> 
> Best Wishes,
> Chris Tavers
> 
> Statement of Direction for LedgerSMB
> 
> Background:
> LedgerSMB began as a fork of the popular open source SQL-Ledger
> accounting software.  The initial aims of the project were to offer
> better security and data integrity controls.  However, very quickly
> the projects began to diverge.  This document spells out the basic
> long-range goals of LedgerSMB as a community project.
> 
> Goal 1:  LedgerSMB as Business Infrastructure
> In order to meet changing needs of a diverse market it is important
> that as LedgerSMB grows, that it becomes an easily extensible (and
> even in some cases invisible) part of the data infrastructure of a
> business.  In essence, it must eventually be possible to separate the
> web user interface from the software as a whole.  Important
> requirements we should strive towards are:
>    1)  Separation of mechanism from interface
>    2)  Generic, reusable components wherever possible
>    3)  Scriptability from local and remote programs
>    4)  Extensibility of the core logic in forward-compatible ways
>    5)  Security should be a top priority both in architecture and code
> 
> Goal 2:  LedgerSMB as Web Application
> The LedgerSMB web interface must be extremely easy to use, but more
> important, it must always do the right thing accounting-wise.  At the
> same time, the workflow should be as streamlined as possible.  If
> people want a mechanism to do something that is not generally accepted
> in accounting circles, then that button must map to an automation of
> the accepted way of doing it.  For example, a delete button might map
> to a function which posts a reversing transaction.  Important
> requirements we should strive for here include:
>   1)  User-friendly naming of things.
>   2)  When given a choice of two potentially problematic solutions,
> the solution taken must try to detect the problem and warn the user.
>   3)  The software should be sufficiently easy to use that it can
> compete with Quickbooks and similar software in their home markets.
>   4)  A strong user support structure including contextual help,
> mailing list support, and commercial support options available from a
> variety of sources.
>   5)  Support from the CPA community.
> 
> Goal 3:  Universal Adaptability
> LedgerSMB should strive to be able to meet the needs of all businesses
> whether large or small anywhere in the world.  While it is necessary
> that some markets will initially require more more attention than
> others, the general application should be designed so that it can be
> extended to other environments.  Requirements here but not mentioned
> above include:
>   1)  Using localization frameworks wherever appropriate.
>   2)  Providing hooks more advanced transformations (including
> writing in various directions).
>   3)  Providing the ability to plug in rules for local regulatory requirements.
>   4)  Support from consultants in a variety of locales.
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Ledger-smb-devel mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel