headers
John Locke | 4 Mar 2007 03:53
Favicon

Generating an invoice

On the users list, Chris Travers wrote:
> I am working on an extensible authentication system for 1.3.  It will
> use PostgreSQL's authentication framework and so could eventually use
> LDAP, Kerberos, or PAM for authentication.  Kerberos will not likely
> be supported in 1.3 though.
This brings up a question I had about the best way to show an invoice.
I'm building a separate web application for time/task/project tracking
and scheduling. As part of this, I've got a few screens I allow
customers to log into, to view reports about their projects. Some time
ago I set this up with a screen to show outstanding invoices from the SL
ar table, and provide a mechanism to pay them via Paypal.

I would like to expand this to actually show them the contents of each
invoice. I haven't yet dug into the invoice generation code. My question
is about best practices for outside interaction with Ledger-SMB, and the
API to use.

My application is in PHP, and in my current environment, is being
written to not require running on the same box as Ledger-SMB. Currently
I'm reading from the LSMB database directly to show my invoices, and I'm
using the Cash->Receipt screen to manually confirm payment.

What would be the best way to interface with Ledger-SMB in this case?
I'm thinking of setting up a Ledger-SMB user account with authorization
to only perform certain tasks--create invoices, mark payment received,
create and update accounts, and look up parts/services, and then using
either the regular web interface via https, or a web-enabled API to
handle these transactions. What's the state of the API that was
discussed early on? Is this the best approach, or should I be
interacting with stored functions or directly on tables in the DB?
(Continue reading)

Permalink | Reply | 752 comments |
headers
Chris Travers | 4 Mar 2007 06:56
Picon

Re: Generating an invoice

I would start by looking through the bin/is.pl (in 1.2) or
bin/mozilla/is.pl in 1.1 to see how Dieter retrieved the invoices.
Then use the Form.pm's parse_template() function to generate the
invoice for the customer.  I haven't done this yet, but it shouldn't
be too hard.  THe hardest part is deciding how you want to enforce
customer security, etc. since the SQL-Ledger codebase doesn't give you
any of that.

Best wishes,
Chris Travers

On 3/3/07, John Locke <mail@...> wrote:
> On the users list, Chris Travers wrote:
> > I am working on an extensible authentication system for 1.3.  It will
> > use PostgreSQL's authentication framework and so could eventually use
> > LDAP, Kerberos, or PAM for authentication.  Kerberos will not likely
> > be supported in 1.3 though.
> This brings up a question I had about the best way to show an invoice.
> I'm building a separate web application for time/task/project tracking
> and scheduling. As part of this, I've got a few screens I allow
> customers to log into, to view reports about their projects. Some time
> ago I set this up with a screen to show outstanding invoices from the SL
> ar table, and provide a mechanism to pay them via Paypal.
>
> I would like to expand this to actually show them the contents of each
> invoice. I haven't yet dug into the invoice generation code. My question
> is about best practices for outside interaction with Ledger-SMB, and the
> API to use.
>
> My application is in PHP, and in my current environment, is being
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Travers | 4 Mar 2007 06:59
Picon

Re: Generating an invoice

Also note:  The financial and invoice API's are scheduled for
refactoring, redesign, and such in 1.4.  Until then, use should be
seen to be temporary.  Note that the new API will be far simpler and
language-independant.

Best Wishes,
Chris Travers

-------------------------------------------------------------------------
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
Permalink | Reply | 751 comments |
headers
Chris Travers | 4 Mar 2007 07:22
Picon

Checklist for 1.3

Since the 1.2 development has been frozen for some time and we are
rolling toward release, I figured I would list the checklist of
minimal things we should try to accomplish in 1.3.  Some of these have
already been done.  These include:

1)  Web services interface (Jason has already contributed this)
2)  Redesigned customer, vendor, and contact tracking
3)  Redesigned COA handling.  Legacy chart view may be kept around as
a depricated interface.
4)  Redesigned user management, security, and rights management
5)  New dataset management interface and setup wizard.
6)  Basic MVC structure (no framework used, though-- see below) for
redesigned parts.

Overview of the MVC structure:
We will not be using an MVC framework like Catalyst because after
reviewing them, we have decided that the goals of the project are not
well served by this specific technology.  It is true that the
framework is far more useful than we initially gave it credit for, but
we have chosen to structure the application in different ways in order
to provide some additional benefits including:

1)  Cross-development-environment data model.  The same data model can
be accessed from Java, Groovy, Python, Perl, PHP, VB6, .Net, or
whatever you want to use.  It will be entirely encapsulated in the
database (rather than having the data model encapsulate the database).
 We will use some basic glue to re-encapsulate in Perl but this will
be thin.  Other envelopes could be implemented easily without too much
work in other languages.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Jeff Kowalczyk | 4 Mar 2007 07:42
Picon
Favicon

Re: Checklist for 1.3

--- Chris Travers <chris.travers@...> wrote:
> 2)  Full data integrity controls managed by the database. In short
> the ORM works almost in reverse.

Can you elaborate on the planned implementation of the integrity controls? I'd
like to read up on the parts of Postgresql involved (and deemed most
appropriate by the core developers): Declaritive Referential Integrity (DRI),
triggers, functions or stored procedures instead of triggers, etc.

 
____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/

-------------------------------------------------------------------------
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
Permalink | Reply | 2 comments |
headers
Jeff Kowalczyk | 4 Mar 2007 08:20
Picon
Favicon

Re: Checklist for 1.3

--- Chris Travers <chris.travers@...> wrote:
> 1)  Cross-development-environment data model.  The same data model can
> be accessed from Java, Groovy, Python, Perl, PHP, VB6, .Net, or
> whatever you want to use.  It will be entirely encapsulated in the
> database (rather than having the data model encapsulate the database).
>  We will use some basic glue to re-encapsulate in Perl but this will
> be thin.  Other envelopes could be implemented easily without too much
> work in other languages. (... 2.) the ORM works almost in reverse.

Are there any postgresql features that would allow a connection to the same
database but without the in-database (but non-DRI) integrity/model features?
E.g. if you were crazy enough, you could take on all SP responsibility/control
back in your language's ORM. I don't know enough about postgresql schemas to
guess whether they can offer per-schema trigger and function/SP definitions for
the same underlying table instances.

My thinking is that someday, presupposing a complete test suite has built up
around the data model, someone might like to work with their favorite ORM on a
100% compatible implementation of some particular module or the entire
LedgerSMB backend. Pass the same tests, but with pure language+ORM code.

It would be great to see a detailed unit/functional/integration test suite
eventually become the real 'product' of LedgerSMB, and LedgerSMB the
application as we know it, was simply the reference implementation, with the
vast majority of the community using and maintaining it.

Given the background of the core developers, we can be quite comfortable with
the stated direction of LedgerSMB's refactoring (90% stored procedures, 10%
perl UI as the reference implementation).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Chris Travers | 4 Mar 2007 08:45
Picon

Re: Checklist for 1.3

Jeff wrote:
>Can you elaborate on the planned implementation of the integrity controls? I'd
>like to read up on the parts of Postgresql involved (and deemed most
>appropriate by the core developers): Declaritive Referential Integrity (DRI),
>triggers, functions or stored procedures instead of triggers, etc.

Data integrity controls include declared foreign keys, check
constraints, and triggers where these are not sufficient.  Stored
procedures are used as an additional API layer to simplify add-on
module development.  I don't foresee many custom triggers but they
could be added as necessary.

On 3/3/07, Jeff Kowalczyk <jtk@...> wrote:

> Are there any postgresql features that would allow a connection to the same
> database but without the in-database (but non-DRI) integrity/model features?

Not sure I understand what you are including and what you are not.

> E.g. if you were crazy enough, you could take on all SP responsibility/control
> back in your language's ORM. I don't know enough about postgresql schemas to
> guess whether they can offer per-schema trigger and function/SP definitions for
> the same underlying table instances.

Not sure why you would want to do it that way, but it is possible.  I
think we expect a stable physical schema at some point.

A more likely scenario is that you could add triggers to a stable
schema in order to replicate data between LSMB  and another
application running off the same database but in a different schema.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joshua D. Drake | 4 Mar 2007 19:41
Favicon

Re: Checklist for 1.3

Jeff Kowalczyk wrote:
> --- Chris Travers <chris.travers@...> wrote:
>   
>> 2)  Full data integrity controls managed by the database. In short
>> the ORM works almost in reverse.
>>     
>
> Can you elaborate on the planned implementation of the integrity controls? I'd
> like to read up on the parts of Postgresql involved (and deemed most
> appropriate by the core developers): Declaritive Referential Integrity (DRI),
> triggers, functions or stored procedures instead of triggers, etc.
>   
The long and short of it is this. Core believes that data integrity 
belongs with your data, which means we will be
implementing data type constraints, custom domains, RI, triggers, rules 
and any other method required (including functional check constraints)
to insure that the data of ledgersmb is impeccable.

Joshua D. Drake

-------------------------------------------------------------------------
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
Permalink | Reply | 1 comment |
headers
Josh Berkus | 5 Mar 2007 18:53

Re: Checklist for 1.3

JD, Chris,

> The long and short of it is this. Core believes that data integrity
> belongs with your data,

Or, in less abstract terms, we expect that people will want to create plug-ins 
and interoperability modules for LedgerSMB with other software.  The best way 
to make sure that extensions of LedgerSMB cannot mess up the base financial 
data is to create a bulletproof data API for them to plug into instead of the 
base tables.

While such an API could be created in middleware, creating a middleware API 
which would be programming-language agnostic and sufficiently robust and 
secure would be significantly greater effort (as in 3x to 10x) than doing it 
inside the database.  Especially given our pool of expertise, which includes 
several PostgreSQL experts.

> which means we will be 
> implementing data type constraints, custom domains, RI, triggers, rules
> and any other method required (including functional check constraints)
> to insure that the data of ledgersmb is impeccable.

I've done this with other financial databases.   Generally I end up 
implementing a full abstraction layer in the database, consisting of numerous 
views and functions replacing direct table access.  I would tend to lean 
against triggers/rules on base tables, except for data auditing, as they are 
difficult to manage from a development perspective and can easily have 
unintended effects.  Views and data-push functions, or pseudo-tables, allow 
front-loading of business rules in a way which can be easily isolated to 
specific data regions.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Travers | 6 Mar 2007 08:08
Picon

Plan for refactoring user information

Hi all;

I am looking at reactoring user information in 1.3.  Here is my basic proposal:

1)  Users are connected to three other tables:  employee (for HR
information), preferences (for their own preferences), and locations
(for business location).

The basic user table looks like:
create table db_users (
  id serial primary key,
  username text unique not null,
  active bool default true not null,
  employee_id int references employee (id),
  location_id int references location (id)
);

On login, the application checks db_users (not users so we avoid
conflicts with setups with Pg-central in the main db) to see that the
user exists and is active.  If not, it aborts.

The employee table remains unchanged for now.

The preferneces table looks like:

create table preferences(
                      id integer primary key references db_users(id)
deferrable initially deferred,
                      countrycode text,
                      currency text,
(Continue reading)

Permalink | Reply | 2 comments |

Gmane