|
----- 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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.