sql-ledger-users — SQL-Ledger users

Re: [SL] automatically posting recurring transactions

[Walter Z. <wvz...@co...>]

Thank you Andreas

It does seem too complicated for me, but I might give it a try.

regards

Walter

Andreas Stern wrote:
> hi,
>
> using SL 2.6.21-2 (debian), I am using SQL Scripts.
> One to generate "recurring" transactions - they are not automatically 
> posted:
>
> -- change Sales Invoice/AR number - so every time I generate invoices I 
> can set the starting number
>
> -- change default AR account so I can determine which account theese 
> invoices go to and
>
> -- select all transaction under recurring transactions and press "process 
> transactions"
>
> Afer that I use the second script to delete these "recurring" 
> transactions.
>
> Prerequisites are a view based on special 
> customers.notes, business.description and invoice.description which shows 
> the customers that got invoices during the last three Years
> and another one based on that that gives the first year the customer has 
> to get an invoice and some functions to fill parts_id, description, 
> fxsellprice and sellprice in invoice.
>
> Determined by customer type and last invoice for each specific 
> customer
> reduction and parts are selected:
>
> -- first the customers are selected into tmp_customer, then invoices into 
> tmp_invoice, third Accounts receivable ( ar ) into tmp_ar, then the last 
> invoice number + 1 into tmp_firstinvoice.
>
> from these tmp_ tables I fill ar, update the invoice number there, fill 
> invoice, fill acc_trans (two times), fill recurring and recurringemail.
>
> done.
>
> all the comments are in german, and the code is neither elegant nor error 
> free, but it works for me.
> If you are familiar with sql and all the above does not sound too 
> complicated to you, it might be an inspiration, and you could possibly use 
> it for your purposes.
>
> If that is to complicated for you, you have to generate all invoices you 
> need, press schedule and select the proper options.
>
> regards
>
> A.
>
> On Thu, 12 Jun 2008, Walter V. Zamora wrote:
>
>   
>> Hi:
>>
>> Is there anyway that recurring transactions can be automatically posted
>> when they are originally created?
>>
>> Will appreciate very much any input.
>>
>> regards
>>
>> Walter
>>
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> sql-ledger-users mailing list
>> sql...@li...
>> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
>>
>>     
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
>
>   

Re: [SL] Trend analysis - additional development

[Bernd P. <bp...@ch...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>Date: Sun, 8 Jun 2008 07:21:19 +0500
>From: "Armaghan Saqib" <sa...@le...>
>Subject: Re: [SL] Trend analysis - additional development
>To: sql...@li...
>Message-ID:
>	<30d...@ma...>
>Content-Type: text/plain; charset=ISO-8859-1

>I think things are not as simple. If someone is going to put $20k-40k
>in some software he also needs to consider (among other things):

>1. Which project is open to criticism and critical discussions.
>2. Number of core developers behind it.
>3. Core architecture.
>4. Community and number of other contributors.
>and so on.


Allow me to disagree.

$20k-40k is not a vast amount of money in commercial development.
Companies around the world a paying contractors a lot of money to
develop whatever software they need.
This is controlled by specifications, quality tests and sign-off of
the work.
The ordering party gets the source code, test protocols, documentation
- - whatever has been agreed upon and that's it.

I don't see any relation to your points 1. - 4. at all.

If we are talking about SQL-Ledger you may want to feed that
development into the main system because this would make it available
for other people and for future versions but that is not a requirement.

Regards,
Bernd

- -- 
プラゲ ベェアント - Bernd Plagge
ファースト・チョイス・インターネット(有)
First Choice Internet Ltd., Tokyo
Tel. 03-4500-7799
Fax. 03-4400-3723
mail: bp...@ch...
url: http://www.choicenet.ne.jp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIUa+DpYU8M8PbPV4RAm+gAKDDyBcOtEG+G4wVdeeJaJAlndzkawCgoctP
CPmrnxR2h1KMXCc+qyzRkuw=
=AAfe
-----END PGP SIGNATURE-----

Re: [SL] automatically posting recurring transactions

[Andreas S. <as...@ac...>]

hi,

using SL 2.6.21-2 (debian), I am using SQL Scripts.
One to generate "recurring" transactions - they are not automatically 
posted:

-- change Sales Invoice/AR number - so every time I generate invoices I 
can set the starting number

-- change default AR account so I can determine which account theese 
invoices go to and

-- select all transaction under recurring transactions and press "process 
transactions"

Afer that I use the second script to delete these "recurring" 
transactions.

Prerequisites are a view based on special 
customers.notes, business.description and invoice.description which shows 
the customers that got invoices during the last three Years
and another one based on that that gives the first year the customer has 
to get an invoice and some functions to fill parts_id, description, 
fxsellprice and sellprice in invoice.

Determined by customer type and last invoice for each specific 
customer
reduction and parts are selected:

-- first the customers are selected into tmp_customer, then invoices into 
tmp_invoice, third Accounts receivable ( ar ) into tmp_ar, then the last 
invoice number + 1 into tmp_firstinvoice.

from these tmp_ tables I fill ar, update the invoice number there, fill 
invoice, fill acc_trans (two times), fill recurring and recurringemail.

done.

all the comments are in german, and the code is neither elegant nor error 
free, but it works for me.
If you are familiar with sql and all the above does not sound too 
complicated to you, it might be an inspiration, and you could possibly use 
it for your purposes.

If that is to complicated for you, you have to generate all invoices you 
need, press schedule and select the proper options.

regards

A.

On Thu, 12 Jun 2008, Walter V. Zamora wrote:

> Hi:
>
> Is there anyway that recurring transactions can be automatically posted
> when they are originally created?
>
> Will appreciate very much any input.
>
> regards
>
> Walter
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
>

Re: [SL] automatically posting recurring transactions

[Walter V. Z. <wvz...@co...>]

Thanks Michael.

Walter

On Thu, 2008-06-12 at 10:43 -0700, Michael Hasse wrote:
> Ah, sorry, misunderstood the question.
>     The short answer would be "I doubt it".  SL is basically  a bunch  
> of scripts and a very simple back end database structure, (no stored  
> procedures).  This is a great design for portability, but since there  
> is no real "process" running all the time to execute things on  
> demand, you'd probably have to script a cron job or something like  
> that yourself.
>     Hopefully somebody else will weigh in with a better solution!
> 
> 
> Thanks,
> 
> Michael
> 
> 
> On Jun 12, 2008, at 10:26 AM, Walter V. Zamora wrote:
> 
> > Thank Michael for the answer. By clicking the schedule button, it
> > schedules the transactions and show up in later dates in order to post
> > them as these dates come up, but they have to be posted  
> > individually for
> > every date.  Is there a way that they get posted for the future.  I am
> > trying to use this feature for lease payments.
> > regards
> >
> > Walter
> >
> >
> > On Thu, 2008-06-12 at 09:57 -0700, Michael Hasse wrote:
> >> Just click the Schedule button...
> >>
> >>
> >> Thanks,
> >>
> >> Michael
> >>
> >>
> >>
> >> On Jun 12, 2008, at 8:17 AM, Walter V. Zamora wrote:
> >>
> >>> Hi:
> >>>
> >>> Is there anyway that recurring transactions can be automatically
> >>> posted
> >>> when they are originally created?
> >>>
> >>> Will appreciate very much any input.
> >>>
> >>> regards
> >>>
> >>> Walter
> >>>
> >>>
> >>> -------------------------------------------------------------------- 
> >>> --
> >>> ---
> >>> Check out the new SourceForge.net Marketplace.
> >>> It's the best place to buy or sell services for
> >>> just about anything Open Source.
> >>> http://sourceforge.net/services/buy/index.php
> >>> _______________________________________________
> >>> sql-ledger-users mailing list
> >>> sql...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
> >>
> >>
> >> --------------------------------------------------------------------- 
> >> ----
> >> Check out the new SourceForge.net Marketplace.
> >> It's the best place to buy or sell services for
> >> just about anything Open Source.
> >> http://sourceforge.net/services/buy/index.php
> >> _______________________________________________
> >> sql-ledger-users mailing list
> >> sql...@li...
> >> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
> >
> >
> > ---------------------------------------------------------------------- 
> > ---
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://sourceforge.net/services/buy/index.php
> > _______________________________________________
> > sql-ledger-users mailing list
> > sql...@li...
> > https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
> 
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users

Re: [SL] automatically posting recurring transactions

[Michael H. <mh...@it...>]

Ah, sorry, misunderstood the question.
    The short answer would be "I doubt it".  SL is basically  a bunch  
of scripts and a very simple back end database structure, (no stored  
procedures).  This is a great design for portability, but since there  
is no real "process" running all the time to execute things on  
demand, you'd probably have to script a cron job or something like  
that yourself.
    Hopefully somebody else will weigh in with a better solution!


Thanks,

Michael


On Jun 12, 2008, at 10:26 AM, Walter V. Zamora wrote:

> Thank Michael for the answer. By clicking the schedule button, it
> schedules the transactions and show up in later dates in order to post
> them as these dates come up, but they have to be posted  
> individually for
> every date.  Is there a way that they get posted for the future.  I am
> trying to use this feature for lease payments.
> regards
>
> Walter
>
>
> On Thu, 2008-06-12 at 09:57 -0700, Michael Hasse wrote:
>> Just click the Schedule button...
>>
>>
>> Thanks,
>>
>> Michael
>>
>>
>>
>> On Jun 12, 2008, at 8:17 AM, Walter V. Zamora wrote:
>>
>>> Hi:
>>>
>>> Is there anyway that recurring transactions can be automatically
>>> posted
>>> when they are originally created?
>>>
>>> Will appreciate very much any input.
>>>
>>> regards
>>>
>>> Walter
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> --
>>> ---
>>> Check out the new SourceForge.net Marketplace.
>>> It's the best place to buy or sell services for
>>> just about anything Open Source.
>>> http://sourceforge.net/services/buy/index.php
>>> _______________________________________________
>>> sql-ledger-users mailing list
>>> sql...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
>>
>>
>> --------------------------------------------------------------------- 
>> ----
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> sql-ledger-users mailing list
>> sql...@li...
>> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
>
>
> ---------------------------------------------------------------------- 
> ---
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users

Re: [SL] automatically posting recurring transactions

[Walter V. Z. <wvz...@co...>]

Thank Michael for the answer. By clicking the schedule button, it
schedules the transactions and show up in later dates in order to post
them as these dates come up, but they have to be posted individually for
every date.  Is there a way that they get posted for the future.  I am
trying to use this feature for lease payments.
regards

Walter


On Thu, 2008-06-12 at 09:57 -0700, Michael Hasse wrote:
> Just click the Schedule button...
> 
> 
> Thanks,
> 
> Michael
> 
> 
> 
> On Jun 12, 2008, at 8:17 AM, Walter V. Zamora wrote:
> 
> > Hi:
> >
> > Is there anyway that recurring transactions can be automatically  
> > posted
> > when they are originally created?
> >
> > Will appreciate very much any input.
> >
> > regards
> >
> > Walter
> >
> >
> > ---------------------------------------------------------------------- 
> > ---
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://sourceforge.net/services/buy/index.php
> > _______________________________________________
> > sql-ledger-users mailing list
> > sql...@li...
> > https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
> 
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users

Re: [SL] automatically posting recurring transactions

[Michael H. <mh...@it...>]

Just click the Schedule button...


Thanks,

Michael



On Jun 12, 2008, at 8:17 AM, Walter V. Zamora wrote:

> Hi:
>
> Is there anyway that recurring transactions can be automatically  
> posted
> when they are originally created?
>
> Will appreciate very much any input.
>
> regards
>
> Walter
>
>
> ---------------------------------------------------------------------- 
> ---
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users

[SL] automatically posting recurring transactions

[Walter V. Z. <wvz...@co...>]

Hi:

Is there anyway that recurring transactions can be automatically posted
when they are originally created?

Will appreciate very much any input.

regards

Walter

Re: [SL] Trend analysis - additional development

[Luke <sl...@li...>]

On Mon, 9 Jun 2008, la...@cl... wrote:

> I don't think I was trying to define what the role of a DBA or business
> anaylst should be as I do believe in cross training. I think I named a
> legitimate reason why going to a postgres only solution isn't the greatest

It is a "legitimate reason"--I was not claiming otherwise.  However, imo 
it is a legitimate reason for the minority of potential users, not the 
majority.

Look at Quickbooks, for example: their database is completely proprietary 
from a user prospective.  Any organization using that, has *no* outside 
access to the database, DBA or no DBA, and how many substantial 
organizations are using it?  Enough to keep Intuit in business, bad 
practices and all.

> idea for the open source except for Commad Prompt. Hey, it's their open
> source and they are free to take LSMB to Command Prompt Financial. I stand
> netural between SL an LSMB but I sure hope that no one is buying
> statements that SL is terrible because it does not use relationships or
> referential integrity constraints

Although....

> million dollor financial system that is just that and works very well for
> its clients. Nonetheless, you know the bottom line is that the software
> has to work--and that's SL for now.

I don't think that this point is particularly in dispute.

What is, is that LSMB, with its deep integration and exclusivity with 
PostGreSQL, is either a potentially good, or potentially bad, option for 
the future, if they get it to a widely usable and stable setup.

I maintain, taking QuickBooks as an example, that as long as the financial 
side is properly functional, and the UI suits the needs of the 
organization, the backend database is not something that the vast (and I 
do mean vast) majority of potential users is going to care about.  Keep in 
mind its intended market--it's right there in the name: small to medium 
businesses.  We aren't talking about huge companies with seas of financial 
analysts, DBAs, reports departments, and the like.  We are probably 
talking about companies with one to a thousand employees.

Luke

Re: [SL] Deleting Services

[Rich S. <rsh...@ap...>]

On Mon, 9 Jun 2008, Michael Hasse wrote:

> We've run into this before - they are associated with a transaction
> somewhere in the system.  Keep searching...  :) Once you find/ correct it,
> then the Delete button will appear.

Michael,

   OK. I'll make time to hunt it down and correct the entry.

Thanks,

Rich

-- 
Richard B. Shepard, Ph.D.               |  Integrity            Credibility
Applied Ecosystem Services, Inc.        |            Innovation
<http://www.appl-ecosys.com>     Voice: 503-667-4517      Fax: 503-667-8863

Re: [SL] Deleting Services

[Michael H. <mh...@it...>]

We've run into this before - they are associated with a transaction  
somewhere in the system.  Keep searching...  :)  Once you find/ 
correct it, then the Delete button will appear.


Thanks,

Michael

On Jun 9, 2008, at 11:02 AM, Rich Shepard wrote:

> On Mon, 9 Jun 2008, Sean Ervin wrote:
>
>> If I am correct, you can not delete them because they have been  
>> used or sold
>> somewhere.
>
>    They have not been used or sold. They are errors.
>
> Rich
>
> -- 
> Richard B. Shepard, Ph.D.               |  Integrity             
> Credibility
> Applied Ecosystem Services, Inc.        |            Innovation
> <http://www.appl-ecosys.com>     Voice: 503-667-4517      Fax:  
> 503-667-8863
>
> ---------------------------------------------------------------------- 
> ---
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users

Re: [SL] Deleting Services

[Rich S. <rsh...@ap...>]

On Mon, 9 Jun 2008, Sean Ervin wrote:

> If I am correct, you can not delete them because they have been used or sold
> somewhere.

   They have not been used or sold. They are errors.

Rich

-- 
Richard B. Shepard, Ph.D.               |  Integrity            Credibility
Applied Ecosystem Services, Inc.        |            Innovation
<http://www.appl-ecosys.com>     Voice: 503-667-4517      Fax: 503-667-8863

Re: [SL] Deleting Services

[Sean E. <sea...@gm...>]

If I am correct, you can not delete them because they have been used or sold
somewhere. This holds true for parts anyway. When you sell something, you
can only mark it obsolete after you have adjusted the inventory to zero.
However, I am not sure this is true for Services. I would assume the same
principles apply.

I hope this helps.

Best regards,
Sean

On Mon, Jun 9, 2008 at 1:14 PM, Rich Shepard <rsh...@ap...>
wrote:

>   There are a few services that are errors. That is, they were entered
> incorrectly and assigned a number by the system. Because they do not
> represent used or useful information in the system I would like to delete
> them. However, I cannot find a 'delete' button when I list all services.
>
>   How can I clean up these digital dust bunnies?
>
> Rich
>
> --
> Richard B. Shepard, Ph.D.               |  Integrity            Credibility
> Applied Ecosystem Services, Inc.        |            Innovation
> <http://www.appl-ecosys.com>     Voice: 503-667-4517      Fax:
> 503-667-8863
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
>

[SL] Deleting Services

[Rich S. <rsh...@ap...>]

   There are a few services that are errors. That is, they were entered
incorrectly and assigned a number by the system. Because they do not
represent used or useful information in the system I would like to delete
them. However, I cannot find a 'delete' button when I list all services.

   How can I clean up these digital dust bunnies?

Rich

-- 
Richard B. Shepard, Ph.D.               |  Integrity            Credibility
Applied Ecosystem Services, Inc.        |            Innovation
<http://www.appl-ecosys.com>     Voice: 503-667-4517      Fax: 503-667-8863

Re: [SL] Trend analysis - additional development

[<la...@cl...>]

I don't think I was trying to define what the role of a DBA or business
anaylst should be as I do believe in cross training. I think I named a
legitimate reason why going to a postgres only solution isn't the greatest
idea for the open source except for Commad Prompt. Hey, it's their open
source and they are free to take LSMB to Command Prompt Financial. I stand
netural between SL an LSMB but I sure hope that no one is buying
statements that SL is terrible because it does not use relationships or
referential integrity constraints or its flat file tables or its tables
violate the normal forms. These statments are simply false. I know of a
million dollor financial system that is just that and works very well for
its clients. Nonetheless, you know the bottom line is that the software
has to work--and that's SL for now.

I again rest my case...

Regards,

Tim



> For what it's worth, in reference to DBAs working on accounting
> systems, we have several clients who do a lot of data mining and
> trend analysis on their own data.  They'll have a whole team doing
> nothing but generating arbitrary reports and correlating seemingly
> arbitrary data from other systems.  So the DBA isn't necessarily
> maintaining the accounting system's database per se, but they are
> working with it at all levels, so I could see where having a back-end
> that was familiar to the dev team would make sense.  However, as
> detailed below and from my own experience, I would say this does tend
> to be the exception rather than the rule.
>
>
> Thanks,
>
> Michael
>
>
> On Jun 8, 2008, at 2:14 PM, Luke wrote:
>
>> On Sun, 8 Jun 2008, la...@cl... wrote:
>>
>>> I beg to differ and based on the technical and development
>>> direction of
>>> LSMB I think having such corporation's sponsorship could be a
>>> conflict of
>>> interest. LSMB has now forces users to use only Postgres when it had
>>> decided to build all of its logics in the database layer. While it
>>> may
>>
>> This is to enable alternative interface development, and other things
>> requiring a real API instead of the CGI based back end interface as
>> SL and
>> currently LSMB have now.
>>
>> Standardizing on a single database is not particularly good from a
>> coverage prospective, but it does enable optimizations not currently
>> possible.  PostGreSQL is a well recognized, well supported, widely
>> deployed DBM with a good reputation.
>>
>> If they had standardized on MySQL or something, I would probably agree
>> with you to an extent.
>>
>>> sounds nice that it adheres to software development theories but my
>>> experience tells me that theories aren't always practical. I think
>>> a lot
>>
>> Who's talking about theories?
>>
>>> of companies do wish to have the flexibility to choose (say a
>>> company that
>>> already has a MS SQL corporate licence probably wouldn't want to
>>> install
>>> postgress because one it wants to run its mission critial app on a
>>> MS SQL
>>> server and two it doesn't want to train or hire a Postgres DBA).
>>> SL may be
>>
>> (1) Such a company is not likely to be using an open source
>> accounting app
>> in the first place (seriously, how common is that configuration
>> likely to
>> be?); and (2) why should they need to employ someone to work at the
>> database level?  If they trust the app, database level work should
>> never
>> be necessary.  If they don't trust the app, then they shouldn't be
>> using
>> it.  For the rare problem, they can find a third party support
>> company.
>>
>> Most important to your argument is comment number 1, and I just
>> don't see
>> it.  If you're not willing to use an open source DBM, you're
>> certainly not
>> going to trust an open source accounting package.
>>
>>>> I had one of those, in fact, who we did have using SL.  Everyone
>>>> but the
>>>> President hated it, because it was not more Quickbooks-like (it
>>>> forced
>>>> them to be aware of the riggers of the accounting process, and
>>>> most of
>>>> these people had a sales background).  However, for what we did,
>>>> it was
>>>> mostly usable (we had to customize various things, and do a lot
>>>> of back
>>>> end database work because of the lack of import features in 2.6),
>>>> and
>>>> completely stable.
>>>
>>> Could the problem lies in your statement that you had sales probably
>>> touching accounting fuctions such as AR/AP? In the same token a
>>> business
>>> anaylsts/DBA should probably do a data import and not a sales person.
>>
>> You appear to have a very different business structure than most
>> people I
>> know.  No company I know of, no matter what the accounting app or
>> database
>> back end, employs a DBA for this purpose.
>>
>> They weren't touching import issues--but their objection was that,
>> unlike
>> in QuickBooks with which they were familiar, they could not import CSV
>> data for the thousands of products and tens of vendors and such, which
>> they had to get into the app.  Their complaint was that they had to
>> pay
>> us, and pay us they did, to do the database work of getting the
>> data into
>> SL for them, by developing custom import scripts for every job.
>>
>> For a company which is not the size of your average international
>> megacorp, it is quite likely that you will have sales people
>> generating
>> both orders and invoices, and some times even working with vendor side
>> (AP) activities.  This is common in almost every company I can
>> remember
>> doing business with which had a dedicated sales staff, with one
>> exception
>> which worked as you suggest.  Still, that's one exception out of
>> hundreds--at least in the US, sales people are often responsible for
>> generating AR transactions of various forms.
>>
>> As I said, an international megacorp with vast accounting staff,
>> invoices
>> transacted via EDI and such, may work more as you describe, but not
>> the smaller, less than a thousand employee, types with which I deal.
>>
>>> SL does provide a layer and we have only our accounting folks using
>>> functions (like AR/AP) that are accounting specific? Our customer
>>> service
>>> often input sales orders, but only accounting/those who are
>>> trained are
>>> allowed to generate invoices. I would be interested in a specific
>>> example
>>> from you if it is possible?
>>
>> Not quite sure what it is of which you desire an example.
>>
>> Regards,
>>
>> Luke
>>
>> ----------------------------------------------------------------------
>> ---
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> sql-ledger-users mailing list
>> sql...@li...
>> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
>

Re: [SL] Trend analysis - additional development

[<la...@cl...>]

thank you and i think i rest my case...tim

> On Sun, 8 Jun 2008, la...@cl... wrote:
>
>> I beg to differ and based on the technical and development direction of
>> LSMB I think having such corporation's sponsorship could be a conflict
>> of
>> interest. LSMB has now forces users to use only Postgres when it had
>> decided to build all of its logics in the database layer. While it may
>
> This is to enable alternative interface development, and other things
> requiring a real API instead of the CGI based back end interface as SL and
> currently LSMB have now.
>
> Standardizing on a single database is not particularly good from a
> coverage prospective, but it does enable optimizations not currently
> possible.  PostGreSQL is a well recognized, well supported, widely
> deployed DBM with a good reputation.
>
> If they had standardized on MySQL or something, I would probably agree
> with you to an extent.
>
>  > sounds nice that it adheres to software development theories but my
>> experience tells me that theories aren't always practical. I think a lot
>
> Who's talking about theories?
>
>> of companies do wish to have the flexibility to choose (say a company
>> that
>> already has a MS SQL corporate licence probably wouldn't want to install
>> postgress because one it wants to run its mission critial app on a MS
>> SQL
>> server and two it doesn't want to train or hire a Postgres DBA). SL may
>> be
>
> (1) Such a company is not likely to be using an open source accounting app
> in the first place (seriously, how common is that configuration likely to
> be?); and (2) why should they need to employ someone to work at the
> database level?  If they trust the app, database level work should never
> be necessary.  If they don't trust the app, then they shouldn't be using
> it.  For the rare problem, they can find a third party support company.
>
> Most important to your argument is comment number 1, and I just don't see
> it.  If you're not willing to use an open source DBM, you're certainly not
> going to trust an open source accounting package.
>
>> > I had one of those, in fact, who we did have using SL.  Everyone but
>> the
>> > President hated it, because it was not more Quickbooks-like (it forced
>> > them to be aware of the riggers of the accounting process, and most of
>> > these people had a sales background).  However, for what we did, it
>> was
>> > mostly usable (we had to customize various things, and do a lot of
>> back
>> > end database work because of the lack of import features in 2.6), and
>> > completely stable.
>>
>> Could the problem lies in your statement that you had sales probably
>> touching accounting fuctions such as AR/AP? In the same token a business
>> anaylsts/DBA should probably do a data import and not a sales person.
>
> You appear to have a very different business structure than most people I
> know.  No company I know of, no matter what the accounting app or database
> back end, employs a DBA for this purpose.
>
> They weren't touching import issues--but their objection was that, unlike
> in QuickBooks with which they were familiar, they could not import CSV
> data for the thousands of products and tens of vendors and such, which
> they had to get into the app.  Their complaint was that they had to pay
> us, and pay us they did, to do the database work of getting the data into
> SL for them, by developing custom import scripts for every job.
>
> For a company which is not the size of your average international
> megacorp, it is quite likely that you will have sales people generating
> both orders and invoices, and some times even working with vendor side
> (AP) activities.  This is common in almost every company I can remember
> doing business with which had a dedicated sales staff, with one exception
> which worked as you suggest.  Still, that's one exception out of
> hundreds--at least in the US, sales people are often responsible for
> generating AR transactions of various forms.
>
> As I said, an international megacorp with vast accounting staff, invoices
> transacted via EDI and such, may work more as you describe, but not
> the smaller, less than a thousand employee, types with which I deal.
>
>  > SL does provide a layer and we have only our accounting folks using
>> functions (like AR/AP) that are accounting specific? Our customer
>> service
>> often input sales orders, but only accounting/those who are trained are
>> allowed to generate invoices. I would be interested in a specific
>> example
>> from you if it is possible?
>
> Not quite sure what it is of which you desire an example.
>
> Regards,
>
> Luke
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
>

Re: [SL] Trend analysis - additional development

[Michael H. <mh...@it...>]

For what it's worth, in reference to DBAs working on accounting  
systems, we have several clients who do a lot of data mining and  
trend analysis on their own data.  They'll have a whole team doing  
nothing but generating arbitrary reports and correlating seemingly  
arbitrary data from other systems.  So the DBA isn't necessarily  
maintaining the accounting system's database per se, but they are  
working with it at all levels, so I could see where having a back-end  
that was familiar to the dev team would make sense.  However, as  
detailed below and from my own experience, I would say this does tend  
to be the exception rather than the rule.


Thanks,

Michael


On Jun 8, 2008, at 2:14 PM, Luke wrote:

> On Sun, 8 Jun 2008, la...@cl... wrote:
>
>> I beg to differ and based on the technical and development  
>> direction of
>> LSMB I think having such corporation's sponsorship could be a  
>> conflict of
>> interest. LSMB has now forces users to use only Postgres when it had
>> decided to build all of its logics in the database layer. While it  
>> may
>
> This is to enable alternative interface development, and other things
> requiring a real API instead of the CGI based back end interface as  
> SL and
> currently LSMB have now.
>
> Standardizing on a single database is not particularly good from a
> coverage prospective, but it does enable optimizations not currently
> possible.  PostGreSQL is a well recognized, well supported, widely
> deployed DBM with a good reputation.
>
> If they had standardized on MySQL or something, I would probably agree
> with you to an extent.
>
>> sounds nice that it adheres to software development theories but my
>> experience tells me that theories aren't always practical. I think  
>> a lot
>
> Who's talking about theories?
>
>> of companies do wish to have the flexibility to choose (say a  
>> company that
>> already has a MS SQL corporate licence probably wouldn't want to  
>> install
>> postgress because one it wants to run its mission critial app on a  
>> MS SQL
>> server and two it doesn't want to train or hire a Postgres DBA).  
>> SL may be
>
> (1) Such a company is not likely to be using an open source  
> accounting app
> in the first place (seriously, how common is that configuration  
> likely to
> be?); and (2) why should they need to employ someone to work at the
> database level?  If they trust the app, database level work should  
> never
> be necessary.  If they don't trust the app, then they shouldn't be  
> using
> it.  For the rare problem, they can find a third party support  
> company.
>
> Most important to your argument is comment number 1, and I just  
> don't see
> it.  If you're not willing to use an open source DBM, you're  
> certainly not
> going to trust an open source accounting package.
>
>>> I had one of those, in fact, who we did have using SL.  Everyone  
>>> but the
>>> President hated it, because it was not more Quickbooks-like (it  
>>> forced
>>> them to be aware of the riggers of the accounting process, and  
>>> most of
>>> these people had a sales background).  However, for what we did,  
>>> it was
>>> mostly usable (we had to customize various things, and do a lot  
>>> of back
>>> end database work because of the lack of import features in 2.6),  
>>> and
>>> completely stable.
>>
>> Could the problem lies in your statement that you had sales probably
>> touching accounting fuctions such as AR/AP? In the same token a  
>> business
>> anaylsts/DBA should probably do a data import and not a sales person.
>
> You appear to have a very different business structure than most  
> people I
> know.  No company I know of, no matter what the accounting app or  
> database
> back end, employs a DBA for this purpose.
>
> They weren't touching import issues--but their objection was that,  
> unlike
> in QuickBooks with which they were familiar, they could not import CSV
> data for the thousands of products and tens of vendors and such, which
> they had to get into the app.  Their complaint was that they had to  
> pay
> us, and pay us they did, to do the database work of getting the  
> data into
> SL for them, by developing custom import scripts for every job.
>
> For a company which is not the size of your average international
> megacorp, it is quite likely that you will have sales people  
> generating
> both orders and invoices, and some times even working with vendor side
> (AP) activities.  This is common in almost every company I can  
> remember
> doing business with which had a dedicated sales staff, with one  
> exception
> which worked as you suggest.  Still, that's one exception out of
> hundreds--at least in the US, sales people are often responsible for
> generating AR transactions of various forms.
>
> As I said, an international megacorp with vast accounting staff,  
> invoices
> transacted via EDI and such, may work more as you describe, but not
> the smaller, less than a thousand employee, types with which I deal.
>
>> SL does provide a layer and we have only our accounting folks using
>> functions (like AR/AP) that are accounting specific? Our customer  
>> service
>> often input sales orders, but only accounting/those who are  
>> trained are
>> allowed to generate invoices. I would be interested in a specific  
>> example
>> from you if it is possible?
>
> Not quite sure what it is of which you desire an example.
>
> Regards,
>
> Luke
>
> ---------------------------------------------------------------------- 
> ---
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users

Re: [SL] Trend analysis - additional development

[Luke <acc...@li...>]

On Sun, 8 Jun 2008, la...@cl... wrote:

> I beg to differ and based on the technical and development direction of
> LSMB I think having such corporation's sponsorship could be a conflict of
> interest. LSMB has now forces users to use only Postgres when it had
> decided to build all of its logics in the database layer. While it may

This is to enable alternative interface development, and other things 
requiring a real API instead of the CGI based back end interface as SL and 
currently LSMB have now.

Standardizing on a single database is not particularly good from a 
coverage prospective, but it does enable optimizations not currently 
possible.  PostGreSQL is a well recognized, well supported, widely 
deployed DBM with a good reputation.

If they had standardized on MySQL or something, I would probably agree 
with you to an extent.

 > sounds nice that it adheres to software development theories but my
> experience tells me that theories aren't always practical. I think a lot

Who's talking about theories?

> of companies do wish to have the flexibility to choose (say a company that
> already has a MS SQL corporate licence probably wouldn't want to install
> postgress because one it wants to run its mission critial app on a MS SQL
> server and two it doesn't want to train or hire a Postgres DBA). SL may be

(1) Such a company is not likely to be using an open source accounting app 
in the first place (seriously, how common is that configuration likely to 
be?); and (2) why should they need to employ someone to work at the 
database level?  If they trust the app, database level work should never 
be necessary.  If they don't trust the app, then they shouldn't be using 
it.  For the rare problem, they can find a third party support company.

Most important to your argument is comment number 1, and I just don't see 
it.  If you're not willing to use an open source DBM, you're certainly not 
going to trust an open source accounting package.

> > I had one of those, in fact, who we did have using SL.  Everyone but the
> > President hated it, because it was not more Quickbooks-like (it forced
> > them to be aware of the riggers of the accounting process, and most of
> > these people had a sales background).  However, for what we did, it was
> > mostly usable (we had to customize various things, and do a lot of back
> > end database work because of the lack of import features in 2.6), and
> > completely stable.
> 
> Could the problem lies in your statement that you had sales probably
> touching accounting fuctions such as AR/AP? In the same token a business
> anaylsts/DBA should probably do a data import and not a sales person.

You appear to have a very different business structure than most people I 
know.  No company I know of, no matter what the accounting app or database 
back end, employs a DBA for this purpose.

They weren't touching import issues--but their objection was that, unlike 
in QuickBooks with which they were familiar, they could not import CSV 
data for the thousands of products and tens of vendors and such, which 
they had to get into the app.  Their complaint was that they had to pay 
us, and pay us they did, to do the database work of getting the data into 
SL for them, by developing custom import scripts for every job.

For a company which is not the size of your average international 
megacorp, it is quite likely that you will have sales people generating 
both orders and invoices, and some times even working with vendor side 
(AP) activities.  This is common in almost every company I can remember 
doing business with which had a dedicated sales staff, with one exception 
which worked as you suggest.  Still, that's one exception out of 
hundreds--at least in the US, sales people are often responsible for 
generating AR transactions of various forms.

As I said, an international megacorp with vast accounting staff, invoices 
transacted via EDI and such, may work more as you describe, but not 
the smaller, less than a thousand employee, types with which I deal.

 > SL does provide a layer and we have only our accounting folks using
> functions (like AR/AP) that are accounting specific? Our customer service
> often input sales orders, but only accounting/those who are trained are
> allowed to generate invoices. I would be interested in a specific example
> from you if it is possible?

Not quite sure what it is of which you desire an example.

Regards,

Luke

Re: [SL] Trend analysis - additional development

[Ed W <li...@wi...>]

Luke wrote:
> I had one of those, in fact, who we did have using SL.  Everyone but the 
> President hated it, because it was not more Quickbooks-like (it forced 
> them to be aware of the riggers of the accounting process, and most of 
> these people had a sales background). 


I'm curious because I haven't used QB, but personally I actually quite 
like the SL interface and would rate it as one of the simplest order 
systems I have seen in a system for use by small businesses.  I wonder 
what it was that they didn't like?

Actually interface is what has put me off most alternatives, only ones 
that I felt I could live with were TinyERP and Opentaps (which I just 
found yesterday).  SL/LSMB are nice because you can just enter a few 
details and have it autocomplete and just work.  That said I would have 
thought the interface will not work well for an enterprise level 
customer with too many products/customers for a single level search 
screen? (not me though!)

Ed W

P.S.  Everyone has a favourite database - I personally know Mysql (or MS 
SQL) best, but I don't think that the DB choice is going to be a 
sticking point for more than a smallish percentage of people.

Re: [SL] Trend analysis - additional development

[Matt B. <ma...@li...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


Refactoring the code is very desirable, but yes, making these operations
postgresql procedures is not how I would have proceeded.  Targeting some
sort of middleware (perhaps even SOAP) would be a more flexible and
attractive (and more modern) approach.

la...@cl... wrote:
| Hmm...

- --

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFITCg/JiSUUSaRdSURCFEIAJ4mDV5I6iU9udIB94dGxuT/vjbogQCdEJAV
fGo2+vfakOFD+y4xsaf67uw=
=NSQ5
-----END PGP SIGNATURE-----

Re: [SL] Trend analysis - additional development

[<la...@cl...>]

Hmm...

>> LedgerSMB team hasn't been around that long yet.  It's a similar
>
> As a team, no.  However, some of these guys have been in the accounting
> and database software, and open source software, arena for quite a while.
> Keep in mind, that its main corporate sponsor at the moment seems to be
> the PostGreSQL company, and that is no shabby association of hackers.

I beg to differ and based on the technical and development direction of
LSMB I think having such corporation's sponsorship could be a conflict of
interest. LSMB has now forces users to use only Postgres when it had
decided to build all of its logics in the database layer. While it may
sounds nice that it adheres to software development theories but my
experience tells me that theories aren't always practical. I think a lot
of companies do wish to have the flexibility to choose (say a company that
already has a MS SQL corporate licence probably wouldn't want to install
postgress because one it wants to run its mission critial app on a MS SQL
server and two it doesn't want to train or hire a Postgres DBA). SL may be
a one-man-band but it does offer the option to choose and to me it is a
lot better in that prespective...

> I had one of those, in fact, who we did have using SL.  Everyone but the
> President hated it, because it was not more Quickbooks-like (it forced
> them to be aware of the riggers of the accounting process, and most of
> these people had a sales background).  However, for what we did, it was
> mostly usable (we had to customize various things, and do a lot of back
> end database work because of the lack of import features in 2.6), and
> completely stable.

Could the problem lies in your statement that you had sales probably
touching accounting fuctions such as AR/AP? In the same token a business
anaylsts/DBA should probably do a data import and not a sales person.

SL does provide a layer and we have only our accounting folks using
functions (like AR/AP) that are accounting specific? Our customer service
often input sales orders, but only accounting/those who are trained are
allowed to generate invoices. I would be interested in a specific example
from you if it is possible?

Regards,

Tim

Re: [SL] Trend analysis - additional development

[Luke <sl...@li...>]

On Sat, 7 Jun 2008, Michael Hasse wrote:

>     As things stand currently we believe LedgerSMB has a good team  
> but it will likely be a couple of years before we're willing to even  
> look at it due not only to switching cost but also because the  

At the moment at least, there is an extant upgrade path from one to the 
other.  Don't know how long that will last, though.

> LedgerSMB team hasn't been around that long yet.  It's a similar  

As a team, no.  However, some of these guys have been in the accounting 
and database software, and open source software, arena for quite a while.
Keep in mind, that its main corporate sponsor at the moment seems to be 
the PostGreSQL company, and that is no shabby association of hackers.

> question - if the team falls apart, what are we looking at?  And is  
> it maintainable?

A good question, certainly.  We will have to wait and see when they get 
their 1.3 or 1.4 version released, how it is for new developers to get in 
on the action.

>     Similarly, if I have $20k-$40k to invest in a system, (tweaked or  
> from scratch), I don't just care about the immediate development  
> process, I also care about the longevity of support and the options  
> for same.  And we're not alone, we have clients that do DoD projects  
> having support contracts stretching into the decades.  They're not  
> using SL, but the concerns are the same on both sides of the fence...

I had one of those, in fact, who we did have using SL.  Everyone but the 
President hated it, because it was not more Quickbooks-like (it forced 
them to be aware of the riggers of the accounting process, and most of 
these people had a sales background).  However, for what we did, it was 
mostly usable (we had to customize various things, and do a lot of back 
end database work because of the lack of import features in 2.6), and 
completely stable.

That said, I am not likely to do that again (get a client with DOD 
contracts using SL), because of the same usability factors.  The main 
reason we did it in the first place, was that it had a usable web 
interface, and much of the access needs which were anticipated, were for 
users operating mobile wireless handhelds.

SL won hands down on that question alone, and so we took them there, some 
kicking and screaming.

Regards,

Luke

Re: [SL] Trend analysis

[Ed W <li...@wi...>]

Dr Eberhard W Lisse wrote:
> Give it a rest now!
>
> el
>   

You're not to polite either are you....

Ed W

Re: [SL] Trend analysis - additional development

[Michael H. <mh...@it...>]

There are other concerns as well.  Specifically the "hit by a bus  
scenario".  Dieter is, and to all appearances prefers to remain, a  
one-man band.  If SQL-Ledger ever moved away from an OSS license we  
would immediately have to find an alternative.  As it stands the one- 
man-band is acceptable because if Dieter ever does get hit by a bus  
we (and others) at least have the source to work with going forward.   
If SL moved to a compiled closed-source model everyone using it would  
be SOL if he were out of commission.
    As things stand currently we believe LedgerSMB has a good team  
but it will likely be a couple of years before we're willing to even  
look at it due not only to switching cost but also because the  
LedgerSMB team hasn't been around that long yet.  It's a similar  
question - if the team falls apart, what are we looking at?  And is  
it maintainable?
    Similarly, if I have $20k-$40k to invest in a system, (tweaked or  
from scratch), I don't just care about the immediate development  
process, I also care about the longevity of support and the options  
for same.  And we're not alone, we have clients that do DoD projects  
having support contracts stretching into the decades.  They're not  
using SL, but the concerns are the same on both sides of the fence...


Thanks,

Michael

On Jun 7, 2008, at 7:21 PM, Armaghan Saqib wrote:

> 2008/6/7 Bernd Plagge <bp...@ch...>:
>> why don't you just write the specification for the functions you
>> require, publish it somewhere and ask Dieter for a quotation?
>>
>> If you wish alternatives you could even make a tender. Then, go  
>> for the
>> best offer.
>>
>> Looks straight forward to me...
>
> I think things are not as simple. If someone is going to put $20k-40k
> in some software he also needs to consider (among other things):
>
> 1. Which project is open to criticism and critical discussions.
> 2. Number of core developers behind it.
> 3. Core architecture.
> 4. Community and number of other contributors.
> and so on.
>
> LedgerSMB is currently in terrible state right now but seems to have
> great future ahead with a great community. Things will be clear after
> the release of 1.3.
>
> In short term (or may be in long term, who knows) SQL-Ledger is a  
> great choice.
>
> -- 
> * Purpose-built SQL-Ledger Hosting. Free trial.
> * SQL-Ledger VMware Appliance. Free download.
> http://www.ledger123.com/
>
> --
>
> ---------------------------------------------------------------------- 
> ---
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users

Re: [SL] Trend analysis - additional development

[Armaghan S. <sa...@le...>]

2008/6/7 Bernd Plagge <bp...@ch...>:
> why don't you just write the specification for the functions you
> require, publish it somewhere and ask Dieter for a quotation?
>
> If you wish alternatives you could even make a tender. Then, go for the
> best offer.
>
> Looks straight forward to me...

I think things are not as simple. If someone is going to put $20k-40k
in some software he also needs to consider (among other things):

1. Which project is open to criticism and critical discussions.
2. Number of core developers behind it.
3. Core architecture.
4. Community and number of other contributors.
and so on.

LedgerSMB is currently in terrible state right now but seems to have
great future ahead with a great community. Things will be clear after
the release of 1.3.

In short term (or may be in long term, who knows) SQL-Ledger is a great choice.

-- 
* Purpose-built SQL-Ledger Hosting. Free trial.
* SQL-Ledger VMware Appliance. Free download.
http://www.ledger123.com/

--