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 <[EMAIL PROTECTED]> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>

-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Reply via email to