Menu
▾
▴
sql-ledger-users
|
From: Bernd P. <bp...@ch...> - 2008-06-07 09:41:05
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >Date: Sat, 07 Jun 2008 02:11:17 +0100 >From: Ed W <li...@wi...> >Subject: Re: [SL] Trend analysis >To: sql...@li... >Message-ID: <484...@wi...> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed ... >At the end of the day I just want to get some work done - by all means >try and demonstrate that SL still has a friendly and helpful community >to work with, but so far I'm not impressed. Hi Ed, 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... 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) iD8DBQFISld/pYU8M8PbPV4RArA9AJ9ww9MAuZj3cWtTnh4vs5PUVe/IxwCgiHVl K0ngv7Ocet5P2Wr4cwsTDBU= =YMVK -----END PGP SIGNATURE----- |
|
From: Armaghan S. <sa...@le...> - 2008-06-08 02:21:25
|
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/ -- |
|
From: Michael H. <mh...@it...> - 2008-06-08 05:31:36
|
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
|
|
From: Luke <sl...@li...> - 2008-06-08 06:43:42
|
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 |
|
From: Ed W <li...@wi...> - 2008-06-08 18:48:36
|
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. |
|
From: <la...@cl...> - 2008-06-08 18:18:17
|
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 |
|
From: Matt B. <ma...@li...> - 2008-06-08 18:43:30
|
-----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----- |
|
From: Luke <acc...@li...> - 2008-06-08 21:14:07
|
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 |
|
From: <la...@cl...> - 2008-06-09 06:49:28
|
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 > |
|
From: Michael H. <mh...@it...> - 2008-06-08 21:48:05
|
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 |
|
From: <la...@cl...> - 2008-06-09 07:54:41
|
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 > |
|
From: Luke <sl...@li...> - 2008-06-10 08:53:34
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X