[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 <..hidden..> 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
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?

Cheers,

--
John Locke
"Open Source Solutions for Small Business Problems"
published by Charles River Media, June 2004
http://www.freelock.com


-------------------------------------------------------------------------
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