Slashdot Mirror
Accounting Systems on Linux?
cuebei asks: "OK, Slashdotters -
let's talk accounting systems for small-mid sized businesses. With
the popularity of Linux servers running various e-business services
such as web, directory, mail, commerce, etc, it only makes sense for
Linux to become a more mainstream platform in the business
world. One of the areas where I can foresee Linux being used
extensively is in the area of accounting. Linux is both reliable and
scalable, two key requirements for any accounting package. So who uses
Linux for HR/Accounting? What options are out there? Open-source or
commercial? If you were starting your own business and standardized
on Linux as a platform, what accounting package would you use and why?"
GPL'd, web-based, double entry accounting system
for businesses. Full internationalization support
for several languages, currencies and chart of
accounts, written in Perl. Good stuff.
Webpage here
GNUCash is *not* a business accounting system.
It is a *personal* accounting system.
In my experience (manufacturing, specifcially chemcial manufacturing), the accounting software is almost irrelevant. The trick is finding a suitable manufacturing package and then you just use whatever accounting package that works with it.
That being said I'd be ecstatic if there was good process manufacturing software available for Linux! But the gamut of features would be rather daunting- solid flexible modules for inventory with lot tracking, formulations, hazmat and environmental reporting as well as MSDS and labelling, production BOM, scheduling, heck throw in HR...and of course the mentioned accounting package.
Heh, give me all of this and our company switches to Linux!
It might just be me, but in my former experience being a SysAdmin for several junior oil companies, one thing really stood out in the IT and infrastructure areas: These people were extra conservative.
Whereas the exploration group was running on really nice (for the time) new SGI machines, the production group was being more reserved with Sparc/SUN solutions and the accounting department was positively in the dark ages with an old AS/400 mainframe. It was considered quite radical when they migrated to a bunch of AIX boxes and they were terrified to do it.
Don't misunderstand me, I'd love to see the adoption of linux and open-source solutions in this arena, but I feel that this is likely an area that will meet with substantial resistance.
An "accounting" package is not enough these days. Lets face it, developing relationships with customers is what it's all about. Which means that getting information in and out of your systems in the quickest possible manner is what will win in the face of competition. Enterprise Resource Planning systems from the likes of SAP and Oracle are what give big business the edge. Sure you don't have $250K to spend on solutions from these guys but Appgen, Compiere, and GNU Enterprise are bringing these kind of systems to the masses. The most promising at the moment seems to be Compiere but it does require some up-front costs - (nothing a small business could'nt handle if they were planning on a Windows deployment anyway). Check them out!
He who knows not what his nose knows......
I know that there are several accounting packages out there that support Linux (Computron being one) but they are mostly expensive.
The one problem with an open-source accounting package is that accounting standards are constantly changing and the software would often have to be changed to reflect new standards. Anyone working on such a project would have to be well-versed in each of the new SFAS (Statements of Financial Accounting Standards) as they come out. That's not a fun project for a CPA let alone a layperson.
mySAP has been running on ;-).
Linux for quite some time now.
But perhaps that's nothing for small businesses
-- www.linux-laser.org - Open Source Laser Show Software for Linux
Nathan.
People who quote themselves bug the crap out of me -- Me.
The one problem with SAP-DB at this point, from the "can we make it ubiquitous" perspective, is that it's a real pain to compile.
It was coded on mainframes, and the suite of compilation tools are based on that approach. Thus the code base (and compile process) is "cryptic upper-case 8 character names everywhere."
It's a desparate pain to try to compile it, so it has not quickly moved towards being ubiquitously available. Red Hat doesn't include it in trivially-installable manner in the manner of MySQL or PostgreSQL. Debian folk can't do apt-get install sapdb .
Give it some more time, and get some more public input, and it'll get more attention.
Of course, that would merely bring us to the point where it would start being an interesting "data storage" substrate for an accounting application. Then comes the 'real" work of determining what tables, fields, relationships, and such exist, and how to manage UIs...
If you're not part of the solution, you're part of the precipitate.
However, please Do Not use it as a remote administration / accounting tool that serves over the internet. Its place is inside the firewall.
The reasons is that it doesn't have a session control-related audits. Any user that types in http://hostname/sql-ledger/ir.pl?login=admin&path= bin/mozilla could get into the syste under the name 'admin', given the attacker knows the username "admin" (not hard), and regardless of that account's permission. indeed the same scheme is workable on any other .pl program.
You can apply This patch to fix it, if you don't worry about shared proxies.
And yes, this patch has been sent to the author. His comment was more along the line of accountants are not script kiddies, so we don't need to worry too much. That is probably reasonable, too.
A prime problem with GnuCash vis-a-vis trying to get the "bleeding edge" functionality is that it is an absolute pain to get compiled. The functionality may be worth it, but if it's daunting to build, that's a problem.
In exactly the same manner, there are all sorts of projects out there to build some really cool JavaEnterprize-Foo-Beans- Coffee-Espresso-Transactional- EE goodness; if it takes someone who's an expert in all of:
Excuse me if I don't jump up and down cheering at the vast complexity of this.
In contrast, SQL-Ledger is indeed quite straightforward to set up. A bit more manually-involved than I'd like, but certainly not badly so.
If you're not part of the solution, you're part of the precipitate.
I am a CPA in private practice, and for many years I sold accounting software to small and medium sized businesses. At the risk of trolling for flames, I would have to STRONGLY suggest that you not use Linux for accounting in a small to medium sized business environment. (Note: This is defined a company up to $50,000,000 U.S. in revenue) Why?
1. Unless you are blessed with outside accountants like me who read Slashdot and know the difference between Debian and Mandrake, your choice may create significant problems at month/year end when one of my many slightly to nearmost completely computer illiterate colleagues tries to either download/extract your data or wants you to generate a file that to import into either Excel or their audit/trial balance package. Reason: 99.9999% of tax programs/CPA audit software/CPA trial balance software is written in Windows, and all of it takes an Excel file. (Hint: Not being able to do this quickly/easily = higher costs (annually)).
2. Your CFO/controller will have a lot easier time finding people who can work in the Windows environment to do the basic grunt work of entering invoices, bills, and time so the system can print checks (including your own paycheck). In some 15 years in public accounting, highly computer literate, easily trained, low cost clerks are about as easy to find as naturally occurring penguins in the Sahara. Not everybody runs (or wants to run Linux). Most everybody knows Windows, and your clerks will also know some Excel and at least one or two Windows accounting packages.
3. As much value as I see in open source, I would have a very hard time accepting an open source accounting solution as a CPA auditing a set of books. Unless the company is one of the Generals (Foods, Tire, Motors) or equivalent and possesses the internal programming staff and the full time accounting staff to verify that the stuff works right, it's not worth the risk to be a beta site and discover the bugs. Folks, were talking about real money here, and most of my colleagues would be real skittish about any system that "somebody downloaded from the Internet" (It's bad enough to do that with established, old-line accounting sofware companies, and I've got the scars to prove it.) And if you can't convince us that the books aren't bogus (intentionally or otherwise), good luck with the banker.
In short, yes, accountants are conservative and prefer things that we KNOW will work consistently and correctly all of the time. We also like things that have a low total cost of ownership, and unfortunately, Linux and accounting packages don't have it right now. My "as close as I'm gonna get to a professional recommendation without sending a bill" is live with an off-the-shelf, low cost, Windows (there, I've said it) package such as DacEasy, Best BusinessWorks, or Peachtree. Just promise me no QuickBooks, OK?
I'm not really a CPA, I just play one on TV
The same fucking person you sue when your closed-source app running on Windows fails: NOBODY. Jesus, have you ever read a EULA? You sue absolutely NOBODY. This comment needs to be rated -1 Troll or -1 Total Idiot immediately.
If it ain't broke, you need more software.