Re: Open source ERP vs Whose standards to use?

----- Original Message -----
From: "Stone, Brad V (TC)" <bvstone@taylorcorp.com>
To: <RPG400-L@midrange.com>
Sent: Friday, February 11, 2000 09:55
Subject: RE: Open source ERP vs Whose standards to use?


> I've been following this thread for some time now, and just thought I'd
make
> a couple comments.
>
> In comparing and ERP package to Linux, you're comparing Apples to Piston
> Rings.  OS vs. a Software package, that from what I gather, needs to work
> with every industry in every country.  Why not start with something
smaller.

I tend to agree with you on this Brad. Starting off the open source movement
with a comprehensive ERP is very ambitious indeed. I would have preferred to
see us tackle much smaller projects to begin with. However, the momentum
right now is with the ERP project, so I decided to go along for the ride
anyway. Not because I think it stands a great chance of success, but because
I believe that it will be an exceptional educational opportunity.

> I also am seeing that the flaws of the "open source" problems are starting
> to emerge by the questions asked.  Once this open source is out there and
> modified, if a new version comes out, you will then have to worry about
the
> user being able to incorporate the new version into their modified source.
> Not an easy task.

This is a problem that many of us have been dealing with for years, with
packaged software in general. Buy a package with source, modify, then merge
your changes into the new base code whenever the vendor releases an update.
It's not particularily difficult, but it is very monotonous.

> Another questions that arose was taxes.  This is a HUGE problem.  Has
anyone
> here dealt with a purchased tax package?  Are you including a purchased
tax
> package in this project?  If not, this piece alone will take years of
> developement.  They don't charge what they do for no reason.  What about
> keeping tax tables for every county in every state in every country up to
> date.  That's gigs of data that changes daily.

I'm just thinking out loud here, but I suspect that during the
internationalization discussion, we would borrow the concept of a "locale".
The locale would determine the language, date/time, tax rules etc., that are
used. The initial package would probably only support a single locale, and
it will almost certainly be a U.S. based one. Since I'm in Canada, I might
volunteer to help create a new locale by writing the routines that handle
our GST/PST tax calculations, postal code formatting etc. With the creation
of some well defined procedure interfaces, we may be able to package up this
locale specific stuff into a collection of service programs. This is just an
off the cuff idea, so I wouldn't be surprised if it doesn't work that way,
but the point is that these internationalization issues have already been
handled in other packages. We're not really breaking any new ground here.

> I applaud your efforts, but after working with a company that provides
> home-grown software for only 30+ companies, all in the same industry (with
a
> couple in cananda and a couple out of the US), I think you may be starting
a
> little big and oversimplifing the task at hand.  Even a "simple" inventory
> package would be a large undertaking.

You're so right. Why don't you come over to the OpenERP mail list and share
some of your experience. Right now, I think the list could use some level
headed advice.


John Taylor
Canada

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---