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
>