User: Password:
|
|
Subscribe / Log in / New account

Accounting systems: a rant and a quest

Accounting systems: a rant and a quest

Posted May 9, 2012 5:36 UTC (Wed) by jcm (subscriber, #18262)
Parent article: Accounting systems: a rant and a quest

Jon, I know it'll do wonders for my image ;) but...let me caution you against going for an entirely free (of charge) solution in the process of going to an Open Source accounting solution. You not only really want an open alternative, but you need to (I would say - but my opinion only) get it from a company that is willing to stand by the numbers through indemnification or at least be accountable (no pun intended). My concern is that otherwise you'll run the risk of getting into hot water later with various end of year filings. So, I wouldn't expect an open solution to necessarily cost less (and in fact, I'd expect it to cost a lot more - simply due to the relatively smaller market for a new offering).


(Log in to post comments)

Accounting systems: a rant and a quest

Posted May 10, 2012 8:15 UTC (Thu) by cmccabe (guest, #60281) [Link]

> Jon, I know it'll do wonders for my image ;) but...let me caution you
> against going for an entirely free (of charge) solution in the process of
> going to an Open Source accounting solution. You not only really want an
> open alternative, but you need to (I would say - but my opinion only) get
> it from a company that is willing to stand by the numbers through
> indemnification or at least be accountable (no pun intended). My concern
> is that otherwise you'll run the risk of getting into hot water later with
> various end of year filings. So, I wouldn't expect an open solution to
> necessarily cost less (and in fact, I'd expect it to cost a lot more -
> simply due to the relatively smaller market for a new offering).

Well, if you check out the QuickBooks EULA, you quickly find that it includes this little gem:

> TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL
> PASSWARE OR ITS SUPPLIERS BE LIABLE FOR ANY SPECIAL, INCIDENTAL, INDIRECT,
> OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION,
> DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF
> BUSINESS INFORMATION, OR ANY OTHER PECUNIARY LOSS) ARISING OUT OF THE USE
> OF OR INABILITY TO USE THE SOFTWARE PRODUCT OR THE PROVISION OF OR FAILURE
> TO PROVIDE SUPPORT SERVICES, EVEN IF PASSWARE HAS BEEN ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGES. IN ANY CASE, PASSWARE'S ENTIRE LIABILITY
> UNDER ANY PROVISION OF THIS SLA SHALL BE LIMITED TO THE GREATER OF THE
> AMOUNT ACTUALLY PAID BY YOU FOR THE SOFTWARE PRODUCT OR U.S.$5.00.

So if you paid $50 for the software, that's the exact amount QuickBooks will owe you if it turns out to corrupt your files, cause the IRS to audit you, and kick your dog. See for yourself at http://www.software112.com/products/quickbooks-key+eula.html

The moral of the story is that you don't get enterprise-level support by buying shrink-wrapped software. You get enterprise-level support by paying enterprise-level prices.

Accounting systems: a rant and a quest

Posted May 10, 2012 12:14 UTC (Thu) by ekj (guest, #1524) [Link]

Indeed. And this sort of FUD is depressingly common. You typically don't get a vendor to take responsibility for *anything* other than perhaps the purchase-price of the software, no matter what license you buy.

Even a $10000/year license for Visma Global, will not give you a single cent from Visma if their software causes you to violate some tax-code or other law.

Yet you hear all the time that "you need proprietary software to be safe", when the reality is that paying trough the nose for proprietary stuff guarantees no such things.

Accounting systems: a rant and a quest

Posted May 10, 2012 17:24 UTC (Thu) by jcm (subscriber, #18262) [Link]

Note, I wasn't saying at any point that you need proprietary software, just some commercial entity to take responsibility. I really dislike in the Open Source space how "making money" is equated with "proprietary" (and therefore wrong). The reality is, if you download $whatever version of $foo from git and build it, you can keep all the pieces when it breaks. I truly believe for this kind of stuff, you need to go to a vendor to get a release that has been through QE and at least is backed up with commercial support. Nowhere did I say that means proprietary, unless the idea of going to a vendor is now intrinsically Evil Bad and Wrong :)

Accounting systems: a rant and a quest

Posted May 10, 2012 19:29 UTC (Thu) by ekj (guest, #1524) [Link]

Whereas if you shell out for Quickbooks, when it terminally breaks you get to keep all the pieces, but they may refund you your original purchase-price.

Software-contracts where somebody actually promises to fix things if they break, costs *MUCH* more than off-the-shelf software. Typically orders of magnitude more.

Accounting systems: a rant and a quest

Posted May 13, 2012 18:56 UTC (Sun) by cmccabe (guest, #60281) [Link]

I think I can sort of see the case you're making, although I don't like the way you phrased it.

Accounting and tax software needs to be very bug-free, due to how mission-critical it is for enterprises. Commercial vendors have an incentive to make their software bug-free because otherwise their reputations are tarnished. What kind of similar incentive can we produce for open source developers of accounting and tax software?

If Red Hat or someone else were to offer a commercial support contract for some open source accounting software, Red Hat would have an obvious financial incentive to keep things working. However, support contracts only really make sense for big companies, not for small organizations like LWN.net. This would also tend to drive the developers towards implementing complex features needed by large organizations, not simple things needed by a smaller operation.

Joel Sposky wrote a pretty interesting article about the pricing of software over here: http://www.joelonsoftware.com/articles/CamelsandRubberDuc.... Software offered with a proper support contract clearly falls into what he would call the expensive category.

In the end, I think that we could probably create a good open-source accounting package. It would have to be extensively unit tested, and the development paradigm might have to be a little more restrained than the usual rapid-release strategy. It might also be a good idea for some organization to hold a trademark on the actual name, sort of like how Mozilla holds the trademark to Firefox.

In contrast, I have a hard time imagining open source tax software coming to pass any time soon. It's just not a very rewarding thing to develop-- it doesn't scratch anyone's itch, and the rules change every year in subtle and complex ways. Perhaps the best thing we can hope for is that there will be an open standard for storing tax data. Unfortunately, the IRS's e-file standard seems to fall far short in this regard.

Accounting systems: a rant and a quest

Posted May 17, 2012 4:00 UTC (Thu) by fest3er (guest, #60379) [Link]

Actually, you need to take responsibility for your accounting data yourself. It is inexcusable to blindly enter information into a system and blindly trust the results that come out. And unthinkable to then expect someone else to take the blame. Any good accountant will look at the data in at least three different way to ensure that it is correct: double-entry bookkeeping view, financial accounting view, and financial management view, and in at least three different dimensions, such as by income/expense, by account, and by person. The sums of all dimensions better add up the same. She'll know very quickly whether or not the software is correct.

Money is the lifeblood of every business; without it, the business dies. The purpose of accounting is to know where your money is coming from and where it is going. And, at times, how fast the flow is changing. Satisfying the tax man is secondary.

The basis of any accounting system must be the Generally Accepted Accounting Principles (GAAP). While there are localized variances, GAAP is almost as universally used as is the Uniform Commercial Code (UCC).

I've worked, on and off, for a small accountant for 15 years. He spent the previous 17 years building a fairly complete accounting system (general ledger for client data, time & billing for his work with clients, phone logging, lead tracking, etc.) His programmer essentially wrote 2½ programs a week for 17 years, on average; she did use sound practices, such as code-reuse and good structures. But it's still ISAM-based, business BASIC, one-letter variable names, and almost uncommented (to be expected; disk space was at a premium then: it started on an early BASIC system, moved to a DG NOVA, and finally to Unibasic on SCO UNIX).

If I were to build a small business accounting system, I'd start with his and re-implement it using modern languages and a modern UI. And the first premise of the database system would be as already mentioned: every record inserted must include a record insertion date/time, the record this one retired (or null if it's new), a record retirement date/time, the record that retired this one (or null if it's current) and who did each deed. Nothing is ever deleted from the database or updated in it: 'DELETE' and 'UPDATE' don't exist. Call it 40 bytes per record; in 100M records, that's all of 4GB: mice nuts compared to the bit trail you'd get. And accounting is all about traceability.

Accounting systems: a rant and a quest

Posted May 20, 2012 19:31 UTC (Sun) by renszarv (guest, #84721) [Link]

btw, your requirements are contradicting. If no UPDATE-s are allowed, how/when the 'record retirement date` is modified in that record ? :)

Accounting systems: a rant and a quest

Posted May 20, 2012 21:12 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

You don't.

Instead you create a _new_ record pointing to the old record as the predecessor. So that all new documents from that point on would use the retiree's record, not the old ones.

Accounting systems: a rant and a quest

Posted May 21, 2012 5:32 UTC (Mon) by jackb (guest, #41909) [Link]

A bitemporal data model works like that. Information is only added to the database, never deleted or changed.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds