The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Design of operation system?


When desining an accounting system with Journal/Voucher, General Ledger, Trial balance, FS... One accounting principle is that, errors should be traced or be corrected by another entry/transaction.
So, each time the entry is posted all the corresponding accounts are updated especially the balance. e.g. The AR's balance is updated. And a correction to the AR would be through another entry or adjusting entry.

But for operation system. I mean a system that is being used for day to day operation. It is easy to correct a wrong transaction by directly editing transaction. e.g. when there is a problem with Sales# 232 the system must correct that specific transaction. And when retrieving AR/balance the software will re-compute based on all the details or references to that account e.g. Sales, Payments table. No Ar/balance column is maintained.

What are your toughts/comments?
Monday, May 14, 2007
As any accountant will tell you - they don't make errors. They do make adjusting entries.

In view of the above, there is no reason to have a balances field is there. (Think about it).

BTW: These are basic accounting principles and are required by law for tax reasons in most countries.

You try telling a tax inspector that you deleted that error because you didn't really pay that much for the car/boat/lunch etc. and bsides it's this cruddy error prone software we're using :-)
Glen Harvy Send private email
Tuesday, May 15, 2007
In many countries (eg. Canada) it is illegal for an accounting software to modify or delete existing data without preserving the original data.  Also it is customary practice in accounting only correction entries are made without changing original entries.  Even quickbooks has this feature where you can disable deletion/modification of existing data. After you have set that option you cant change that option.
Donald Duck
Tuesday, May 15, 2007
Accountants do this for very important reasons, as well as several other things that may be unfamiliar to the layman.  Understand the application domain or your project is doomed.
Tuesday, May 15, 2007
"It is easy to correct a wrong transaction by directly editing transaction. e.g. when there is a problem with Sales# 232 the system must correct that specific transaction."

Yes, it's easy but no system would permit you to directly edit the transaction. It's not just accounting principles; what if you accidently edit the wrong record?

For example, let's say you wanted to edit sales #232 and your finger slipped and you accidently opened sales #233 instead without realizing it. Not only do you have two errors to fix, you might not remember what #233 originally contained.

Almost every system of this nature will simply display the most recent "version" of that sales record and you have the ability to mark it as invalid, in which case it will go back a version.

So in my scenario, you'd mark #233 version 2 invalid, and the system would simply display #233 version 1 (until someone adds a version 3). You can likewise simply create a #232 version 2, version 3, version 4, mark the 4 as invalid, version 5 and it would look like you've made three changes total, skipping over the invalid version 4.
Tuesday, May 15, 2007
I've been pushed into situations where if I followed the request of an operations manager, and built the software to their specs, they'd be in some trouble possibly down the road. Some small advice for those who are new to this situation.

I am sure there are many others who have dealt with this fellow while gathering requirements:

"If I haven't printed or sent the invoice to the customer, I should be able to edit the details..." Hrm...

To those, I say "NO WAY". Cut an invoice, it is too late! If the customer wonders why an invoice says 12345-3, you tell them a problem was corrected before they received it, thats it.

If you are unsure, just tell them it isn't GAAP approved and that might scare them off. Or run to the comptroller..

Operations system people typically HATE generating credits for corrections, but it is the only way to keep things straight in the long run and show a history that will make sense to auditors.

I can't say if it is more of a legal issue or a moral question, but we do have some responsibility to protect the purchasers of our software from buying features that could land them in trouble, and they might just want to try to bring you with them - be wary!
I still code in Delphi
Tuesday, May 15, 2007
Reversals should not be hidden from customer, they should reflect on their statements too.

If you are doing many reversals then this is a problem with some other part of your system.
Tuesday, May 15, 2007
Hmm actually read your comment again and you're talking about an invoice.

I think it is ok to edit invoice details, if it has not been sent yet. Invoice does not reflect a transaction.
Tuesday, May 15, 2007

To the idea of invoice versions. I'll count on it.

Another scenario is, after invoices are made. The next day or 2 or before final payment, the customer will call asking for a discount with Sales Invoice# 232.
I think it would be easier to just edit sales 232 and add a discount, than to make another entry just for the discount.

Tuesday, May 15, 2007
"I think it would be easier to just edit sales 232 and add a discount, than to make another entry just for the discount."

Easier, yes. Correct thing to do, no.

Besides, it's a computer program. It really shouldn't take that long to write a routine that does something like...

Invoice x = new Invoice()
x.copyFrom( 232 revision 4 ) 232 revision 5 )
Wednesday, May 16, 2007
Yes. The software must track invoice revisions or versions everytime an invoice is changed. Is that what you mean?
Thursday, May 17, 2007
"Yes. The software must track invoice revisions or versions everytime an invoice is changed. Is that what you mean?"

This is a simplification of the structure I use to handle these "adjustments".

order 123
- item abc $100
order total $100

invoice created: 123-1
- item abc $100
invoie total $100

-- Invoicing clerk realizes the error, and makes a correction

Credit/Rebill function invoked. All (1) items selected, new item added - a discount line of $20 linked to the item abc

credit created: 123-2, supplemental credit note type correction
- item abc $(100)
credit total $(100)

invoice created 123-3, supplemental
- item abc $100
-- discount (on abc) $(20)
invoice total $80

Customer statement shows all corrections. All records are pushed to accounting.

In this situation the operations manager places the responsibility on the invoicing clerk to make sure everything is correct BEFORE invoicing to keep things clean.

This is a model that I have used in service oriented, corporate sales, and it also maps to retail operations and I always have the comptroller on my side.

Sales reps and sales-oriented operations managers (typically) HATE this. Accounting people (typically) WANT this.

You can follow the flow of corrections, I allow for an internal note to be attached to the supplementals. As well, for credits you don't want these to be viewed as 'someting to pay to the customer'. It should be clear that the credit is for account correction purposes, contrasting with retail, the payment method of the invoice is really "AR" if this is a customer with credit.

I assign a type id to the 'invoices' so that a correction and automatically place some pre-written text on any printed invoice "CORRECTION" or whatever.

Maybe there are other approved structures, but this has kept me and my clients out of trouble with auditors. Money lenders are an aspect of having credit customers, they often will question a percentage of credits to invoices, a dilution factor, but if you provide the explanations that these are billing corrections (a new system, a new billing clerk, etc...) they should be satisfied with the explanation, and you can prove the actual billing is not impacted by any corrections.
I still code in Delphi
Tuesday, May 22, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz