Re: Open source ERP vs Whose standards to use?

John,

Glad to see a level headed participant. Comments in line:

John Taylor wrote:

> ----- Original Message -----
> From: "Stone, Brad V (TC)" <bvstone@taylorcorp.com>
> >
> > 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.

<<snip>>

ERP systems are being written every day.  And have been for decades. I've ramped
up my company to do 3 suites from scratch of 8 integrated applications and a few
Adonis in the past 26 years.  It's not that big of a project.  Let me explain.
In the creation of an OS there are no rules and there are no boundaries.  That's
hard. In an integrated accounting application there a a gazillion rules and
boundaries.  That's easier. The objective is not to create something
fantastically new, but so satisfy the rules and the users.  There are two
disciplines that will come into play in the effort: 1) knowing the rules 2)
knowing how to write adaptable code.


> 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.

Exactly!  This is not in exercise in proving anything to anyone.  It is an
exercise in determining if the AS/400 community has the ability to jointly 
create
a useable product for it's own selfish perpetuation at best, and at worst it 
will
create a forum for some nitty-gritty problem solving.

>
>
> > 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.

I totally agree with the historical context.  Now what exactly is that context?
Closed source? ILE? Service programs?  From some of the messages that have hit
the RPG400 and MIDRANGE-L lists, the ERP providers have settled upon the
limitations of V3R2 and the product is RPGIII.  Now for years, you, as a user,
have been hearing about the benefits of RPGIV and all the goodies that come with
it.  Where is it in the applications that are being offered today?

Since I shot off my mouth about doing this, and BTW woke up in the middle of the
night in a cold sweat screaming once it dawned on me the Pandora's box I've
opened, the intent of this project, IMO, is functional isolation.  This means
that if your application provider has a service program called calcSalesTax, 
you,
yes you, have the ability to write or acquire any calcSalesTax module that fits
your needs.  From any provider, from any nation that understands your needs.

>
>
> > 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".
> <<snip>>

Sorry I jumped the gun on the prior response since it mentions taxes. And here 
we
are again <g>

First I would like to mention that the base code that I have offered does not
contain a "tax package" per se.  What it does have is a tax method, tax
calculation, and tax table that the -user- has the responsibility to maintain.
Hey, it's your taxes. <g>

I strongly subscribe to the design philosophy of externalizing variables and
never (ok, hardly ever) hard code something like tax rates.  IMHO, they belong 
in
a locale table that includes and effective date and the program does the math.
The user can either fill in the table or acquire a new one.

>
>
> > 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.

OK, just to settle some nerves out there, the base code and it's parent has been
installed at 105 companies. (I just printed out the customer list) The 
industries
include highway construction (union and nonunion), manufacturing (union and
nonunion), distribution, refuse removal, water utilities. non-profits doing fund
accounting, consignment resellsers, retailers, restaurants, hospitals, timber
industry from harvesters to mills, trucking, service organizations and it's too
late for me to recall any subgroups.  But if you've got a modeling agency, radio
station or an explosives plant, this code has been in that industry.

This is base code.  Progressive Data Systems, Inc. never positioned it's product
as a turnkey solution to any particular industry.  But all industries have to 
pay
their bills, pay their people, bill their customers and review their financial
position.  Some have an inventory.

For all the JDE, etc. users our there, let's take a poll: How many are running
without any modifications?

I thought so, noone is running without modification.  My fundamental design
philosophy is to allow for adaptation.   IMO, RPGIV will greatly simplify this
capability.  Who knows, we may die a silent death or the heavy ERP hitters may
wake up.

I've made the move to offer a starting point for a new way to create
applications.   What I'm offering is a result of a two man year effort and about
four years of tweaking that resulted in about 400k LOC and 5k+ source members.
That covers 1992 to 1998.  By the time we are done, I believe that none of this
code will exist.  I trust that this group can code better than I can.

I'm trusting that any member that has an issue about a function or industry
specific requirement will speak up and believe that they will be heard.

Geez, I haven''t slept for two nights. It's now 3am and my jets are still fired
up!

Sorry if I rambled, but I believe in this concept/project.

J. Kilgore


+---
| 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
+---