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
>