openledger-developer Mailing List for OpenLedger (Page 6)
Brought to you by:
klavs
Menu
▾
▴
openledger-developer — Developer list for discussing SL3 development
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(15) |
Mar
(83) |
Apr
(23) |
May
(10) |
Jun
(6) |
Jul
(14) |
Aug
(5) |
Sep
(1) |
Oct
(7) |
Nov
(6) |
Dec
(1) |
|---|
|
From: Klavs K. <kl...@vs...> - 2005-03-08 21:12:40
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys, I'm wondering why SL does not have invoicenumber as unique. Is it not required to be so in every country? (otherwise you'd have no way of uniquely identifying an invoice, based on a single "variable"). I'd like to use invoicenumber as the key for retrieving a single invoice (instead of the id as used by SL now) - but that ofcourse requires it to be unique (which it does not have to be in SL currently). What do you think? Should I: - - just mirror SL's "search for ID" - then retrive on ID? - - retrive on invoicenumber ? - -- Regards, Klavs Klavsen, GSEC - kl...@vs... - http://www.vsen.dk PGP: 7E063C62/2873 188C 968E 600D D8F8 B8DA 3D3A 0B79 7E06 3C62 "Those who do not understand Unix are condemned to reinvent it, poorly." ~ --Henry Spencer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCLhUkPToLeX4GPGIRAmFNAKCVNe5sy+P5boeBeOFJ6pJ9foCh9gCeId3L psyZVg2a0k9vphh2qrPy3Sk= =xZFF -----END PGP SIGNATURE----- |
|
From: Klavs K. <kl...@vs...> - 2005-03-08 19:33:15
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys, I've just committed the first steps of the API - totally without having tried running it ;) I've just "snagged" the audittrail function from SL/Form.pm - haven't yet rewritten it. I would be very happy if you'd have a look in the postTransaction function and see if you can see any problems. You can compare to the SL/GL.pm post_transaction function. I've removed the qq and other form-handling things (such as the code that figures out if the user gave a credit or debit amount for the transaction), as they do not belong in the API - it is up to what program who calls the API to deliver proper data. p.s. I don't check for valid data (like amount actually being a number) or if a db transaction failed. I'm not a 100% certain if the commit in the end will just fail, if any of the transactions before it did? I don't do any "obvious" input validation - as the ? in the prepare statements takes care of it for us - as to protect against SQL Injection :) - -- Regards, Klavs Klavsen, GSEC - kl...@vs... - http://www.vsen.dk PGP: 7E063C62/2873 188C 968E 600D D8F8 B8DA 3D3A 0B79 7E06 3C62 "Those who do not understand Unix are condemned to reinvent it, poorly." ~ --Henry Spencer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCLf31PToLeX4GPGIRAgbIAJ9q+3RN+gXc2hsuNa147SL8IXi3SgCfSILx BbJ3dA4jsPoSjCUIvTALd60= =6aLJ -----END PGP SIGNATURE----- |
|
From: Klavs K. <kl...@vs...> - 2005-03-08 17:30:20
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 on 03/08/05 01:37 Ang Tun Chek wrote: | hi all, | | just wonder why there is customer details in Invoice.pm since we already | have a customer class. | You are absolutely correct. I wrote the invoice class, before doing the customer object :) (bad exscuse, I know ;) Feel free to add a function to submit a customer-object instead. Then I'll rewrite my code to use that. | i hope to add a new field called "terms" so we can have a improve | duedate function | | duedate=current_date + terms Not a bad idea. I'm guessing you are adding this in the customer object (only place it makes sense AFAIK :) - -- Regards, Klavs Klavsen, GSEC - kl...@vs... - http://www.vsen.dk PGP: 7E063C62/2873 188C 968E 600D D8F8 B8DA 3D3A 0B79 7E06 3C62 "Those who do not understand Unix are condemned to reinvent it, poorly." ~ --Henry Spencer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCLeEmPToLeX4GPGIRAtF0AJ46LLUn1JC4SzvkLmQZoVb4dl/ZRQCgmLic ielXwf3HTu5LVl2Ej1svAxI= =Q6mN -----END PGP SIGNATURE----- |
|
From: Klavs K. <kl...@vs...> - 2005-03-08 17:28:09
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 on 03/04/05 21:26 Joseph wrote: [SNIP] | I'm assuming it will be compatible with SQL-Ledger; I'm still using | ver. 2.2.7 as ver.2.4 I couldn't use it for reason the way he | implemented exchange rate function. Yep. I'll simply reuse the sql from SL-2.4.9 - so it fits in that DB-structure (I still use the webinterface :) How about the rest of you - any plans for features you'd like to work on on OpenLedger - so we can get the Community Accounting program we're all dreaming off, off the ground? - -- Regards, Klavs Klavsen, GSEC - kl...@vs... - http://www.vsen.dk PGP: 7E063C62/2873 188C 968E 600D D8F8 B8DA 3D3A 0B79 7E06 3C62 "Those who do not understand Unix are condemned to reinvent it, poorly." ~ --Henry Spencer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCLeCgPToLeX4GPGIRAguqAKCL6fFZhS/8+n1VpbhB6x8PH1ARLQCgi4P8 4iuTP8aKDkfZyTmLCUcikEI= =IZ/1 -----END PGP SIGNATURE----- |
|
From: Ang T. C. <tc...@st...> - 2005-03-07 16:28:37
|
hi all, just wonder why there is customer details in Invoice.pm since we already have a customer class. i hope to add a new field called "terms" so we can have a improve duedate function duedate=current_date + terms |
|
From: Joseph <sy...@in...> - 2005-03-04 20:25:48
|
[snip] > Indeed it does. I hav already checked in the objects I use, incl. the > Transaction object. > I need to pull out the audittrail code - and figure out where to put > it :) - then I should be done with the (first) function > postTransaction in the OpenLedger.pm file I've written. > > I'll see if this audittrail should just be a private function of > OpenLedger.pm or a seperate class used by OpenLedger class.. I'm assuming it will be compatible with SQL-Ledger; I'm still using ver. 2.2.7 as ver.2.4 I couldn't use it for reason the way he implemented exchange rate function. -- #Joseph |
|
From: Klavs K. <kl...@vs...> - 2005-03-04 20:14:34
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 on 04-03-2005 21:07 Joseph wrote: | On Fri, 2005-03-04 at 20:37 +0100, Klavs Klavsen wrote: | |> I'm soon ready to check it into CVS :) busy saturday and sunday |> with other things - but I'll finish up in the evenings next week, |> and check it - and start using it :) | | Does it mean it will be ready for a test drive? :-) I would love to | try it. Indeed it does. I hav already checked in the objects I use, incl. the Transaction object. I need to pull out the audittrail code - and figure out where to put it :) - then I should be done with the (first) function postTransaction in the OpenLedger.pm file I've written. I'll see if this audittrail should just be a private function of OpenLedger.pm or a seperate class used by OpenLedger class.. - -- Regards, Klavs Klavsen, GSEC - kl...@vs... - http://www.vsen.dk PGP: 7E063C62/2873 188C 968E 600D D8F8 B8DA 3D3A 0B79 7E06 3C62 "Those who do not understand Unix are condemned to reinvent it, poorly." ~ --Henry Spencer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCKMG4PToLeX4GPGIRAphkAJ4niMcAJhom1IyPeB/Q+nykF9/xBQCeMhxs 0bG4Jbh2Bx7Uvr9RsE92Npw= =n3+L -----END PGP SIGNATURE----- |
|
From: Tony F. <to...@sy...> - 2005-03-04 19:58:49
|
On Fri, 2005-03-04 at 11:37, Klavs Klavsen wrote: > | While we're on the topic of placeholders, my preference is for > | positional placeholders. ie. > | > | INSERT INTO blah (foo, bar, baz) VALUES (:1, :2, :3) > > Cool - I didn't know you could to that too. do you give the number to > execute, or is it just the order, that decides their number? It's just the order you give them to execute. I'm not sure if DBD::mysql supports this form. I know that DBD::Pg does though. I use them exclusively in my Service Billing module. > hmm. Do I need to do some audit-trail stuff in my post_transaction > function(perhaps SL does it - and It's just hidden in some function or > the form)? Yup, at the end of post_transaction there is a call to $form->audittrail() you'll fing the DB stuff in SL/Form.pm sub audittrail. > |> If I can use it - then isn't that the correct way to do it? > | > | > | I'm not really a DB guy but the way SL does it is very common in my > | experience and I believe it is considered to be "the RDBMS > | independent way". > > I bet it is - but I thought we agreed on not wanting to make it DB > independant, to make use of some of postgresql's features? > > But I'll just do it the way SL does - then I don't have to change the > sql statements :) I don't see why we should go out of our way to make it non portable. If there is a PostgreSQL feature that is the right tool use it... But why not make it as easy as possible to port at a later date. -- Tony Fraser to...@sy... Sybaspace Internet Solutions System Administrator phone: (250) 246-5368 fax: (250) 246-5398 |
|
From: Klavs K. <kl...@vs...> - 2005-03-04 19:37:24
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
on 04-03-2005 19:52 Tony Fraser wrote:
[SNIP]
|
| Only when there's no harm in doing so. GL::post_transaction()
| doesn't use AutoCommit and only commits once it is finished all its
| statements.
|
| The transaction support in SL is actually quite robust IMHO. I
| think that is a big part of the reason why it is so popular and
| "Just Works". When is the last time you heard anything on
| sql-ledger-users about data corruption that wasn't caused by
| hardware failure or PostgreSQL misconfiguration?
post_transaction does not look right to me -but ofcourse he does not
call the db directly - but uses some object of his own. but no matter.
|> I'd suggest using commit/rollback - and (it was news to me) using
|> ? in the prepare statements, to replace values, which is then
|> given in the execute($var1,$var2,...) call when executing.
|
| Definitely, SL is a bit of a mixed bag on the placeholder front.
| There is newer code (audit trail, and POS for instance) that uses
| placeholders and there is older (like the stuff in GL.pm) that
| doesn't.
|
| While we're on the topic of placeholders, my preference is for
| positional placeholders. ie.
|
| INSERT INTO blah (foo, bar, baz) VALUES (:1, :2, :3)
Cool - I didn't know you could to that too. do you give the number to
execute, or is it just the order, that decides their number?
[SNIP]
|> I see SL (ie. Dieter) is generating it's own unique ID and then
|> replacing on that :(
|>
|> I'd prefer using sequences like this:
|>
|> ~ # first generate a unique id for this table ~ id =
|> dbh.select_one("SELECT nextval('"id"').first
|>
|> ~ # now insert row ~ dbh.do("INSERT INTO test (id, name,
|> phone) VALUES (?,?,?)", id, "foo", "42")
|>
|> The thing is, that currently the SL db has 3 sequences, id,
|> invoiceid and orderitemsid - and I'm not a 100% sure that I can
|> use id for the gl table?
|
|
| invoiceid and orderitemsid are strictly for audit trails. As far as
| I'm aware they are _NEVER_ used for referential integrity. Also
| they are only ever used in the table that their name corresponds
| to.
hmm. Do I need to do some audit-trail stuff in my post_transaction
function(perhaps SL does it - and It's just hidden in some function or
the form)?
|> If I can use it - then isn't that the correct way to do it?
|
|
| I'm not really a DB guy but the way SL does it is very common in my
| experience and I believe it is considered to be "the RDBMS
| independent way".
I bet it is - but I thought we agreed on not wanting to make it DB
independant, to make use of some of postgresql's features?
But I'll just do it the way SL does - then I don't have to change the
sql statements :)
I'm soon ready to check it into CVS :)
busy saturday and sunday with other things - but I'll finish up in the
evenings next week, and check it - and start using it :)
- --
Regards,
Klavs Klavsen, GSEC - kl...@vs... - http://www.vsen.dk
PGP: 7E063C62/2873 188C 968E 600D D8F8 B8DA 3D3A 0B79 7E06 3C62
"Those who do not understand Unix are condemned to reinvent it, poorly."
~ --Henry Spencer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFCKLkCPToLeX4GPGIRAn66AKCQb0vtxPwBRqpI3voBB4boexWlNwCbBSxa
LoaOdttYzQZv+bIHqizxLAg=
=Ri7W
-----END PGP SIGNATURE-----
|
|
From: Tony F. <to...@sy...> - 2005-03-04 18:53:03
|
On Fri, 2005-03-04 at 08:23, Klavs Klavsen wrote:
> I can see SL uses AutoCommit (not good when it's doing several
> transactions - as in post_transaction) :(
Only when there's no harm in doing so. GL::post_transaction() doesn't
use AutoCommit and only commits once it is finished all its statements.
The transaction support in SL is actually quite robust IMHO. I think
that is a big part of the reason why it is so popular and "Just Works".
When is the last time you heard anything on sql-ledger-users about data
corruption that wasn't caused by hardware failure or PostgreSQL
misconfiguration?
> I'd suggest using commit/rollback - and (it was news to me) using ? in
> the prepare statements, to replace values, which is then given in the
> execute($var1,$var2,...) call when executing.
Definitely, SL is a bit of a mixed bag on the placeholder front. There
is newer code (audit trail, and POS for instance) that uses placeholders
and there is older (like the stuff in GL.pm) that doesn't.
While we're on the topic of placeholders, my preference is for
positional placeholders. ie.
INSERT INTO blah (foo, bar, baz) VALUES (:1, :2, :3)
> Also - I'm used mysql being able to tell me the ID of the last_insert_id
> (ie. resulting ID of last INSERT), which is appearently a unique feature
> of MySQL :)
Yup, specifically added to cope with MySQL's lack of separate sequences
in combination with the lack of transaction support in MyISAM tables. To
the best of my knowledge, auto_increment fields are not part of the ANSI
SQL standard either. They are however a relatively common RDBMS specific
extension though.
> I see SL (ie. Dieter) is generating it's own unique ID and then
> replacing on that :(
>
> I'd prefer using sequences like this:
>
> ~ # first generate a unique id for this table
> ~ id = dbh.select_one("SELECT nextval('"id"').first
>
> ~ # now insert row
> ~ dbh.do("INSERT INTO test (id, name, phone) VALUES (?,?,?)", id,
> "foo", "42")
>
> The thing is, that currently the SL db has 3 sequences, id, invoiceid
> and orderitemsid - and I'm not a 100% sure that I can use id for the gl
> table?
invoiceid and orderitemsid are strictly for audit trails. As far as I'm
aware they are _NEVER_ used for referential integrity. Also they are
only ever used in the table that their name corresponds to.
> If I can use it - then isn't that the correct way to do it?
I'm not really a DB guy but the way SL does it is very common in my
experience and I believe it is considered to be "the RDBMS independent
way".
--
Tony Fraser
to...@sy...
Sybaspace Internet Solutions System Administrator
phone: (250) 246-5368 fax: (250) 246-5398
|
|
From: Klavs K. <kl...@vs...> - 2005-03-04 16:23:02
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi guys,
I can see SL uses AutoCommit (not good when it's doing several
transactions - as in post_transaction) :(
I suggest we agree on a way to do DB transactions :)
I'd suggest using commit/rollback - and (it was news to me) using ? in
the prepare statements, to replace values, which is then given in the
execute($var1,$var2,...) call when executing.
Also - I'm used mysql being able to tell me the ID of the last_insert_id
(ie. resulting ID of last INSERT), which is appearently a unique feature
of MySQL :)
I see SL (ie. Dieter) is generating it's own unique ID and then
replacing on that :(
I'd prefer using sequences like this:
~ # first generate a unique id for this table
~ id = dbh.select_one("SELECT nextval('"id"').first
~ # now insert row
~ dbh.do("INSERT INTO test (id, name, phone) VALUES (?,?,?)", id,
"foo", "42")
The thing is, that currently the SL db has 3 sequences, id, invoiceid
and orderitemsid - and I'm not a 100% sure that I can use id for the gl
table?
If I can use it - then isn't that the correct way to do it?
- --
Regards,
Klavs Klavsen, GSEC - kl...@vs... - http://www.vsen.dk
PGP: 7E063C62/2873 188C 968E 600D D8F8 B8DA 3D3A 0B79 7E06 3C62
"Those who do not understand Unix are condemned to reinvent it, poorly."
~ --Henry Spencer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFCKItuPToLeX4GPGIRAicZAJ9jtsi7qfoJiMreXQNkrex4oiQ+tQCfWLsA
DL7rA4tLphugcuY9lTH/kGs=
=64WY
-----END PGP SIGNATURE-----
|
|
From: Tony F. <to...@sy...> - 2005-03-03 20:25:11
|
On Thu, 2005-03-03 at 12:09, Klavs Klavsen wrote: > Any of you know how I can create a CVS-changes (ie. cvs-commits) > MailingList for openledger? I'd like to get notified when someone > commits, and I'm sure some of you would like it too :) I've never done it myself but I ran across this document a while ago and though it was worth bookmarking: http://sourceforge.net/docman/display_doc.php?docid=772&group_id=1 look at the instructions for the script syncmail. -- Tony Fraser to...@sy... Sybaspace Internet Solutions System Administrator phone: (250) 246-5368 fax: (250) 246-5398 |
|
From: Klavs K. <kl...@vs...> - 2005-03-03 20:09:18
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys, Any of you know how I can create a CVS-changes (ie. cvs-commits) MailingList for openledger? I'd like to get notified when someone commits, and I'm sure some of you would like it too :) - -- Regards, Klavs Klavsen, GSEC - kl...@vs... - http://www.vsen.dk PGP: 7E063C62/2873 188C 968E 600D D8F8 B8DA 3D3A 0B79 7E06 3C62 "Those who do not understand Unix are condemned to reinvent it, poorly." ~ --Henry Spencer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCJ27lPToLeX4GPGIRArN9AJwNxkeHzcuJfm4rvNU9s3eIja8RBQCeOeXb PtyXvpaGXf0yOCeuu9lM+r8= =iqUV -----END PGP SIGNATURE----- |
|
From: Tony F. <to...@sy...> - 2005-03-03 18:58:55
|
On Thu, 2005-03-03 at 01:20, Tony Fraser wrote: > Well I went ahead and created a possible API design that uses > LWP::UserAgent and HTML::Form anyway. It has taken the biggest part of a > day to get where I am now but it is working. I have code for creating, > posting and editing GL entries. The implementation consists of 2 helper > classes that will be reused by other types of transactions and 1 > transaction class for a total of 3 classes. > > I'll post the full code on the web tomorrow Well tomorrow's here now. I didn't want to check this into CVS yet. I'd like to get some comments on it first. I tar'd everything up and put the tarball on the project webspace. You can download it from: http://openledger.sf.net/SL-Api.tar.gz Once you've downloaded and untar'd it make sure you have LWP::UserAgent and HTML::Form installed from CPAN and have a look in test.pl. You'll need to change the constructor arguments and probably the account numbers in the add_(debit|credit) method calls. -- Tony Fraser to...@sy... Sybaspace Internet Solutions System Administrator phone: (250) 246-5368 fax: (250) 246-5398 |
|
From: Michael L. <ml...@da...> - 2005-03-03 17:41:52
|
> > It's fine reimplementing the GUI - except if you want to start doing > that BEFORE we the API is half-done - we need to agree on a list of > functions(and parameters) the API should have, so you can code against > that. > > Something like: > postTransaction($transactionobject,$employeeid) > postInvoice($invoiceobject,$employeeid) > > etc. ? I agree defining the API functions will go a long way to implementing a usable product. I am not using the SL interface and am only interested in exercising some of its function. I am also working on another project where I need to develop a cgi web interface. It is for these reasons that I am looking at how to implement the GUI. --mike |
|
From: Klavs K. <kl...@vs...> - 2005-03-03 16:16:16
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
on 03-03-2005 10:20 Tony Fraser wrote:
[SNIP]
| Well I went ahead and created a possible API design that uses
| LWP::UserAgent and HTML::Form anyway.
hehe. The freedom of choice ;) - glad it's a community thing -
otherwise I could dictate what got into OpenLedger :)
| It has taken the biggest part of a day to get where I am now but it
| is working. I have code for creating, posting and editing GL
| entries. The implementation consists of 2 helper classes that will
| be reused by other types of transactions and 1 transaction class
| for a total of 3 classes.
Looking forward to see it in CVS :)
|
| I'll post the full code on the web tomorrow but for now here's a
| driver program that uses the API to post a new GL transaction:
|
| #!/usr/bin/perl
|
| use strict; use warnings;
|
| use SL::Api;
hmm - I'm looking forward to seeing the Api you created here (or is it
the soap-api/Api.pm ?)
|
| our $SL_API = SL::Api->new( location => 'http://accounting/sl/dev',
| login => 'tony', password => 'password' ); our $TRANS =
| $SL_API->start_transaction('add', 'GL');
|
| $TRANS->reference("API TEST1"); $TRANS->description("First test of
| the SL API");
|
| $TRANS->add_debit('1060', 100); #$TRANS->transaction->dump;
| $TRANS->add_credit('3350', 100); #$TRANS->transaction->dump;
|
| $TRANS->post; __END__
|
| Right now it's about 1:30 in the morning and I need to get to bed.
sleep well :)
- --
Regards,
Klavs Klavsen, GSEC - kl...@vs... - http://www.vsen.dk
PGP: 7E063C62/2873 188C 968E 600D D8F8 B8DA 3D3A 0B79 7E06 3C62
"Those who do not understand Unix are condemned to reinvent it, poorly."
~ --Henry Spencer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFCJzhCPToLeX4GPGIRAk6JAJ4sIKud7D1joSVaobf23ksKmVxnMACfUK0a
I7Z0TpQI04tZlwg9oE0Sd1Q=
=0t1p
-----END PGP SIGNATURE-----
|
|
From: Tony F. <to...@sy...> - 2005-03-03 09:21:05
|
On Wed, 2005-03-02 at 08:26, Klavs Klavsen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > on 01-03-2005 22:43 Tony Fraser wrote: > [SNIP] > | What I'm thinking is that the API could sit on top of the GUI. In the > | past we've talked about something that could be used to re-implement the > | GUI but I really think that anything we do to that layer of SL would be > | best started as a re-write/re-implementation of SL that is DB schema > | compatible. > | > Which is exactly what we talked about - reimplementing the features the > GUI (and other programs/scripts) need in the API - and then make the GUI > use that instead of running SQL-ledger gui on the side, which will be > what I'll do until a new GUI, using the API is ready. > > | In the meantime I think the immediate thing to do is to create an API > | that interacts with SL through a combination of LWP::UserAgent and > | HTML::Form. We could make the API SL specific or we could generalize the > | API and make a backend for it that interacts with the current SL. > | > This is what I'm doing now - using lynx and posting what I need to do. > One could use WWW::Mechanize to great benefit, but it is hard work, and > because of the way the GUI works - you'll have to duplicate the data > (like internal partnumbers etc.) unless, you use WWW::Mechanize (which > acts as a browser). I hate this approach with my entire soul - which is > why I wanted to start the openledger project :) > > I currently post invoices this way - and am going to write the first 2 > functions for the API this/next week: > 1) a function for registering a simple transaction (I need to move money > around, when they've been charged from a credit card - I need to move > them to my bank account - to reflect what happens in real life :) > > 2) I need a "getInvoice" function, which will fill an Invoice object > (see CVS for how that object looks) - so I can give the API an > invoicenumber, and get the invoice, including the ordernumber, which is > what I need in this case. > > | I have some UML (created with Dia) of a possible generalized API. I > | wouldn't mind getting some comments on the API. I'll post the UML on the > | SF.net project webspace later today. > | > | So what do you people thing of interacting with SL through HTTP > | requests? I think it will be the most straight forward and probably the > | most SL-version-non-specific way I can come up with. > | > AFAIK the DB structure of SL has been more stable than the GUI design, > and I have done what you are talking about - it is a very tiresome > approach - and if Dieter gets tired of us - it wouldn't be hard to > change the GUI a little bit -which would mean a lot of updating on our > part. I use the same method (WWW::Mechanize) for updating modules in > PostNuke. > > I definetely prefer the path, which leads to a community-based > accounting system :) Well I went ahead and created a possible API design that uses LWP::UserAgent and HTML::Form anyway. It has taken the biggest part of a day to get where I am now but it is working. I have code for creating, posting and editing GL entries. The implementation consists of 2 helper classes that will be reused by other types of transactions and 1 transaction class for a total of 3 classes. I'll post the full code on the web tomorrow but for now here's a driver program that uses the API to post a new GL transaction: #!/usr/bin/perl use strict; use warnings; use SL::Api; our $SL_API = SL::Api->new( location => 'http://accounting/sl/dev', login => 'tony', password => 'password' ); our $TRANS = $SL_API->start_transaction('add', 'GL'); $TRANS->reference("API TEST1"); $TRANS->description("First test of the SL API"); $TRANS->add_debit('1060', 100); #$TRANS->transaction->dump; $TRANS->add_credit('3350', 100); #$TRANS->transaction->dump; $TRANS->post; __END__ Right now it's about 1:30 in the morning and I need to get to bed. -- Tony Fraser to...@sy... Sybaspace Internet Solutions System Administrator phone: (250) 246-5368 fax: (250) 246-5398 |
|
From: Klavs K. <kl...@vs...> - 2005-03-03 07:18:38
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 on 02-03-2005 20:02 Tony Fraser wrote: [SNIP] | | Well, the part I'm most interested in is creating a Module interface for | third party add-ons, but that goes right back to a complete re-write. | :-( | That's IMHO not that bad. If you list what functions you REALLY need for a given task - you can just implement those. That's what I'm doing now - one step at a time. Pretty soon we'll have a fullfledged API - and we can reuse from SL as we see fit - the beauty of GPL :) | Oh Well, maybe I'll get my service billing module finished up under the | current architecture. It's getting to the point of being _almost_ | useful. | hehe. I've written what I badly needed in the "lynx posting"-way too - but I badly need the GL transaction feature -but it seems small enough, so I'll implement it in the API - to get it rolling. Also - if you all like the way I propose to build the login structure, I'll start that - and see if I can find space in the DB (perhaps already there) to save the username+hash - for verifying a user is logged in(and to identify which user is asking :) - -- Regards, Klavs Klavsen, GSEC - kl...@vs... - http://www.vsen.dk PGP: 7E063C62/2873 188C 968E 600D D8F8 B8DA 3D3A 0B79 7E06 3C62 "Those who do not understand Unix are condemned to reinvent it, poorly." ~ --Henry Spencer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCJrpcPToLeX4GPGIRApyZAKCTvxa73xYZpYJbAw7NuqNerAD0qgCgiZe5 07fD5kXL6a40Z3TNCInK/TE= =ZW0P -----END PGP SIGNATURE----- |
|
From: Klavs K. <kl...@vs...> - 2005-03-03 07:13:36
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Joseph, I totally agree, that one of the biggest strength of creating this API, would be that we could easily integrate other packages with OpenLedger :) on 02-03-2005 21:57 Joseph wrote: |> I'd be happy to hear if any of you have any design ideas? or if |> you just like my idea :) | | | I would be a good idea to (at least think about) integrating | OpenLedger with other packages one of them could be an e-commerce | package most popular one, I know that is OSCommerce has a large | user base and there are not very many accounting packages that | integrate with it. I know there is some add-on for QuickBooks. | | Anyhow, this kind of integration would attract large user base. It | doesn't need to be any sophisticated package. What I was thinking, | to have a button in Admin function of OSCommerce, if an order | comes-IN clicking on it would check if the customer exist in | OpenLedger if not add it in or import the customer information | (Name, address, phone etc.). Not a bad idea.. so we need createDebitor and getDebitor functions AFAIK? | Another interesting package would be to integrate it with Kbarcode | package to print the (address label, item label with bar-code on it | etc). | | I think there more we will think about integrating other packages | the more attractive OpenLedger will become. Re-typing the same | information over and over from one package to another is not an | efficient way of doing business. As they say time is money. Agreed. I use OSCommerce myself, so I'd gladly do something here - all ideas are welcome. didn't someone propose to setup a wiki? or perhaps we could use the tasklist at SF? I'd like it, if you would slate the ideas for integration with each piece of software you'd like, with a rough idea of how it should be done (ilike you did with OSCommerce - and list the functions you think would be needed (with paramter description of some sort)). - -- Regards, Klavs Klavsen, GSEC - kl...@vs... - http://www.vsen.dk PGP: 7E063C62/2873 188C 968E 600D D8F8 B8DA 3D3A 0B79 7E06 3C62 "Those who do not understand Unix are condemned to reinvent it, poorly." ~ --Henry Spencer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCJrkrPToLeX4GPGIRAtM2AKCNlHm/Ed/q59jjLZN5aOOPwihpqwCfXV6P X2RBZXDLOQgmO/Z9V8yDfYY= =8WMF -----END PGP SIGNATURE----- |
|
From: Klavs K. <kl...@vs...> - 2005-03-03 07:06:54
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 on 02-03-2005 23:16 Tony Fraser wrote: [SNIP] | Umm... Am I missing somthing? post_transaction() only does 1 | SELECT. and subselects for employeeid - but no. don't mind little confused me :) |> I must be missing something. | | | Maybe you missed the start of the all_transactions() function. | There's lots of selects in there. The all_transactions, retrieves all transactions on a given account I guess? IMHO we'd ONLY have 1 function for that: getTransactions ($parameters) - but the paramter be an object here - or just plain info like startdate,enddate, etc. with NULL(ie. empty parameters) in the ones you don't want to search on? [SNIP] |> I'd be very happy if you could tell me what I'm missing? It does |> ofcourse save the employee ID of the user who posted it. |> |> What should we do with that - just let it be parameter to the |> postTransaction function? Or should we build a login scheme of |> some sort for the API (seems a bit hmm.. to me)? | | | For now I think you could ignore it but the API seems like the | right place for security to me. There's no sense reinventing the | wheel every time you integrate a new application or create a new | GUI. Hmm. The only "partly" secure way to do it - would be to make a login function, which takes user/pass as paramters and returns a hash of that(+salt saved by API itself) - after verifying it. then ALL functions would have to have a $hash paramter, to verify the caller was verified. Only problem, is that when you're dealing with local processes - You'd need to ensure other programs can't peak at the running scripts (ie. the caller) memory segment, as they'd be able to get the $hash and get access. Just like they could sneak into SL gui, if they sniffed the cookie ofcourse :) p.s. this could be reused - as it is the same way login's work - so the GUI would just save that $hash in the client cookie. Unless I'm just tired and there's a better way? What do you think? - -- Regards, Klavs Klavsen, GSEC - kl...@vs... - http://www.vsen.dk PGP: 7E063C62/2873 188C 968E 600D D8F8 B8DA 3D3A 0B79 7E06 3C62 "Those who do not understand Unix are condemned to reinvent it, poorly." ~ --Henry Spencer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCJreXPToLeX4GPGIRAnMLAJ0WF41XspU32O7fxX7SpYX9Oyp2vwCdE1YV gA4F+JpddT79rLBCyiYBJ3Y= =RWRb -----END PGP SIGNATURE----- |
|
From: Klavs K. <kl...@vs...> - 2005-03-03 06:58:50
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 on 02-03-2005 19:52 Michael Long wrote: [SNIP] | I believe I was the one that mentioned that. To configure you | server to log all SQL statements to the log file modify | postgres.conf. Look for the line: #log_statement = 'none' and | change it to: log_statement = 'all' Thanks - I'll do that. [SNIP] | After several months of distractions I have begun looking at the | CGI-Formbuilder and Template-Toolkit perl modules as possible | solutions to separating the API layer from presentation layer. Has | anyone had experience with these? I've used Template Toolkit for letters and other things needing templating, it works quite well. Haven't used CGI-Formbuilder. It's fine reimplementing the GUI - except if you want to start doing that BEFORE we the API is half-done - we need to agree on a list of functions(and parameters) the API should have, so you can code against that. Something like: postTransaction($transactionobject,$employeeid) postInvoice($invoiceobject,$employeeid) etc. ? - -- Regards, Klavs Klavsen, GSEC - kl...@vs... - http://www.vsen.dk PGP: 7E063C62/2873 188C 968E 600D D8F8 B8DA 3D3A 0B79 7E06 3C62 "Those who do not understand Unix are condemned to reinvent it, poorly." ~ --Henry Spencer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCJrWuPToLeX4GPGIRAjCQAJ4/m4nV0VpU+jKkTb724+TzMSS2xQCgoapu 6O+asEF9tWi23M2LTkhubMU= =OkLI -----END PGP SIGNATURE----- |
|
From: Tony F. <to...@sy...> - 2005-03-02 22:17:03
|
On Wed, 2005-03-02 at 10:48, Klavs Klavsen wrote: > Also I can't see why his post_transaction funtion does so many selects, > when posting a transaction (AFAIK) only touches two tables - gl and > acc_trans. Umm... Am I missing somthing? post_transaction() only does 1 SELECT. > I must be missing something. Maybe you missed the start of the all_transactions() function. There's lots of selects in there. > In my head, you'd just insert in the gl table - get the assigned ID, and > use that when posting the transactionlines (that'll be another object > just as InvoiceLines I guess ;) Yup, that's what post_transaction() does. > I'd be very happy if you could tell me what I'm missing? > It does ofcourse save the employee ID of the user who posted it. > > What should we do with that - just let it be parameter to the > postTransaction function? Or should we build a login scheme of some sort > for the API (seems a bit hmm.. to me)? For now I think you could ignore it but the API seems like the right place for security to me. There's no sense reinventing the wheel every time you integrate a new application or create a new GUI. -- Tony Fraser to...@sy... Sybaspace Internet Solutions System Administrator phone: (250) 246-5368 fax: (250) 246-5398 |
|
From: David P. <dp...@he...> - 2005-03-02 21:12:44
|
On Wed, 2005-03-02 at 12:57, Joseph wrote: > > I'd be happy to hear if any of you have any design ideas? or if you just > > like my idea :) > > It would be a good idea to (at least think about) integrating OpenLedger > with other packages I think this concept is the whole point to OpenLedger, creating a gui independent accounting package that can integrate with other packages. Your suggestion of OSCommerce is a good one, from what I've heard it's a popular package. In my own case, I work with a team that has just done a rewrite of SQL Clinic (we don't have a website for the project yet...). SC is a mental health center management package that could really use an integrated accounting package. That's the beauty of it, if we can develop a "generic" accounting package we can use it to turbo charge numerous existing open source packages. David |
|
From: Joseph <sy...@in...> - 2005-03-02 20:57:25
|
> I'd be happy to hear if any of you have any design ideas? or if you just > like my idea :) I would be a good idea to (at least think about) integrating OpenLedger with other packages one of them could be an e-commerce package most popular one, I know that is OSCommerce has a large user base and there are not very many accounting packages that integrate with it. I know there is some add-on for QuickBooks. Anyhow, this kind of integration would attract large user base. It doesn't need to be any sophisticated package. What I was thinking, to have a button in Admin function of OSCommerce, if an order comes-IN clicking on it would check if the customer exist in OpenLedger if not add it in or import the customer information (Name, address, phone etc.). Another interesting package would be to integrate it with Kbarcode package to print the (address label, item label with bar-code on it etc). I think there more we will think about integrating other packages the more attractive OpenLedger will become. Re-typing the same information over and over from one package to another is not an efficient way of doing business. As they say time is money. -- #Joseph |
|
From: Tony F. <to...@sy...> - 2005-03-02 19:14:28
|
On Wed, 2005-03-02 at 10:52, Michael Long wrote: > After several months of distractions I have begun looking at the > CGI-Formbuilder and Template-Toolkit perl modules as possible solutions > to separating the API layer from presentation layer. Has anyone had > experience with these? I've used Template-Toolkit a fair amount and quite like it. Haven't used CGI-Formbuilder though. The other package I suggest you look at is CGI-Application. It's more in the controller layer (a go between for the API/model layer and the presentation/view layer). Cees's CGI-Application-Plugin-TT plugin makes using Template-Toolkit quite painless too. -- Tony Fraser to...@sy... Sybaspace Internet Solutions System Administrator phone: (250) 246-5368 fax: (250) 246-5398 |
