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.

Security for simple Invoicing system

I have created a simple Invoice creating software product with other common functions like Quotations, PO etc. I know there are so many similar software programs available but I thought my products main strength was its ease of use. And also I was targetting a different group of customers who need just the basic functions of the other more powerfull and complicated programs.

But now few days before launch, I have realised that I took Security for granted with my main aim of ease of use.
Here is my problem and I will be deeply gratefull if anyone can suggest a solution.

My program allows a created invoice to be edited even after it being printed out. I thought it was good feature until someone pointed out that it makes my program very vulnerable to a dishonest employee. He can just edit any invoice anytime once a customer leaves the premises to show a lesser amount than charged to a customer. In fact he can just reprint the new edited invoice and no one will know.

I need to sometimes allow for empty invoices to be printed whereby the sales guy etc can visit the customers place and write manually on the invoice and return to office later to update to system. What is the best way to solve this problem with ease of use and security considerations. I cannot just lock the invoice after printing since manual writing on the Invoice is a important feature..
Thanks for all your help and advice in advance.
suhumaran Send private email
Tuesday, July 04, 2006
 
 
Why not just allow some people to create the blank invoices and edit them later -- and normal users aren't allowed to edit printed invoices.

Another option is to simply add an audit track. Everytime you print an invoice you copy the data to an audit table. Invoices that are printed multiple times will have each version stored along with a revision comment/revision user.

If anyone queries an invoice, you can see the audit track of who changed what and when.
Katie Lucas
Tuesday, July 04, 2006
 
 
Can you have a status like "submitted for approval" which disallows editing?
KC Send private email
Tuesday, July 04, 2006
 
 
"Why not just allow some people to create the blank invoices and edit them later -- and normal users aren't allowed to edit printed invoices."

This will make the program a bit complicated and as I mentioned earlier, ease and simplicity of use is the main selling factors in my program.
But the audit track method looks like a good idea. I will think of a solution using this method but am still open to any other ideas.

Thanks a lot for your suggestions.
suhumaran Send private email
Tuesday, July 04, 2006
 
 
"Submitted for approval" where it can't be edited anymore is not suitable for my program since editing of all created documents is a main feature
suhumaran Send private email
Tuesday, July 04, 2006
 
 
Normally invoices are not allowed to be altered (it is assumed that upon printing they will be presented to the customer and obviously they cannot be changed after that).  Normally corrections or changes are issued as further invoices or credit memos.  Occasionally, you will see another invoice with the same number but with a CORRECTION notation.  (Purchase Orders, Statements of Work or Quotes have usually slightly different rules)

However, since you have decided to go down this path...

Audit trail - let people do it, but make it so that there is always a record of changes.

All invoices which have been changed should be indicated on the subsequent printed/emailed/transmitted invoice who last changed it and when.

Change the invoice number to reflect the revision, so that invoice 123456 has revisions 123456-1, 123456-2 or something.
Cade Roux Send private email
Tuesday, July 04, 2006
 
 
just one question for Katie Lucas, when you said to create a audit track, do I need to create it only for Invoices or even for other documents like Quotation, Delivery Order etc...
suhumaran Send private email
Tuesday, July 04, 2006
 
 
This discussion reminds me: I am beginning to grok that security and ease of use are inherently opposed goals, and that it takes thorough thought to do risk analysis and UI iteration so as to think of and achieve an appropriate tradeoff.

Most people reconcile their invoices with some sort of accounting program, such as QuickBooks.  What accounting integration, if any, does your application provide?  Could that be a line of defense against fraud?

I say, if possible, keep unobtrustive logs of all document changes, accessible to administrators.  That seems like a great idea for tracking down errors AND security breaches after the fact.
Sumana Harihareswara Send private email
Tuesday, July 04, 2006
 
 
"Normally invoices are not allowed to be altered "-  Yes I do agree to that this is the ideal solution but as I mentioned earlier, there are times when empty invoices need to be printed out.

Cade Roux -  I have decided to follow your advice on "All invoices which have been changed should be indicated on the subsequent printed/emailed/transmitted invoice who last changed it and when".

Sumana - No my program does not reconcile with any Accounting programs. There are reports showing payment paid, outstanding payments, ivoices created etc.

Thanks a lot for all your suggestions.
suhumaran Send private email
Tuesday, July 04, 2006
 
 
One more thing, if anyone is interested I am willing to give my program IBS version 2.0 (INVOICING BILLING SYSTEM) for free.

It will be completed in aroung 2 weeks time with some error handling and the security thing to be sorted out. Just send me a email.
suhumaran Send private email
Tuesday, July 04, 2006
 
 
"do I need to create it only for Invoices or even for other documents like Quotation, Delivery Order etc..."

The problem with not creating them for other documents is that you might open opportunities for things going wrong.

Being able to alter the delivery orders would allow, for instance, someone to note that a customer ordered 20 monitors. Change the delivery note to read 10, fake a phone call asking where the other 10 got to and talk dispatching into creating a new shipment of 10 which can then disappear without anyone being the wiser.

Writing a similar system, we just decided it was so much easier to just have an audit track on all the main tables. If you're using a proper database, it's actually not that hard to transparently implement using triggers/stored procs. We ended up automating the database creation with perl scripts which produced the tables, the shadow structure to track changes and the triggers which stored off the copies.

In this case it was more because the customers were "fickle" and would keep saying things like "actually, can we go back to the quote you did me three versions ago..." so there was more of a user interface involved, but on a previous system they'd had issues where people had changed orders AFTER the orders had been dispatched to the customers; The sales staff got their commission based on the size of the orders. If the order grew after delivery/invoicing but before the end of month commission summing, no-one noticed until they did end-of-year sums and found out that things didn't add up.

If you have only one copy of the tables, you can't fix this problem even if you notice it, without a LOT of effort. Audit tracks doesn't mean it can't happen, but it does mean you can find it.

Basically anything which produces a paper copy, we set up so printing it first clones the working record, and then prints from the clone. This has the advantage that EVERY bit of paper you've generated, you've got a record of, so you can reproduce any version of any invoice. People aren't allowed to edit the clone table, anymore than they can edit the paper version... And (as someone said) then you can number the invoice/quote revisions properly.

Other things to be cautious of; you need to "freeze" item prices into things like quotations and orders. If a customer agrees to an order and then the price of one of the items goes up, the order value can't change (it's part of a contract). So having line items on the orders refer back to items is only OK for descriptions, and not the prices -- they have to be copied at document generation time.

This causes a processing problem for quotations. Again, you need to freeze the prices in. But if the price of a quotation is held for a certain time, you need to make sure that when it's ordered, you check that and reject the order if the quotation has expired and any of the prices changed... and you're into implementing business rules...

You also need to freeze sales tax computations in the same way. We don't change VAT rate very often in the UK, but the last time it happened, it broke an incredible number of databases; invoices had been written at 15%... but by the time payments arrived they didn't match because the invoice record now thought it should include 17.5% tax. Everyone figured rates would change one day, and included a table of VAT rates. But just changing the standard rate to 17.5% caused all historical sales to change...

{I've never dealt with a system where things change actual vat rate... largely the stuff has always just been 'standard', but HMC&E fiddle with classifications all the time, and some industries may need to be able to cope with  items which move about between bands...}
Katie Lucas
Wednesday, July 05, 2006
 
 
thanks katie for writing a detailed explanation, i think i have all the info i need to get started. I am going to implement this "audit track" to all the documents.
Thanks again to all. This forum has a amazing group of people...
suhumaran Send private email
Wednesday, July 05, 2006
 
 
And yes, the various tradeoffs and conflicts between simplicity, usability, security, and meeting actual business requirements all mean a lot of job security for programmers and designers for years to come.

Wasn't there another thread on this forum about building "intelligence" in software so they wouldn't need programmers?  Heard that before...  Just makes more work for programmers in the end.
Cade Roux Send private email
Wednesday, July 05, 2006
 
 
I have the feeling Suhumaran is not going to be finished in two weeks.  :)

Another suggestion is to set up the invoicing system purely as a Write Once Read Multiple environment. This is basically Katie's audit trail idea reduced to a basic premise: every time you "save" the document, you write a new record. You never ever go back and update a record.

There is the risk that a salesperson will draft a new invoice but there's two things going for you...

a) As Katie says, you do have a record of all actions and the order they took place in (and your source code demonstrates they can't be tampered with).

b) Most legal jurisdictions give the customer the benefit of the doubt when trying to determine which invoice is valid.

...at this point, the only real security risk is that your books won't add up at the end of the quarter. If your business is such that you can't trust your staff to add the books properly, you probably won't buy this software anyway (instead, you'd buy something more...  professional).
TheDavid
Thursday, July 06, 2006
 
 
This is not a 2 week fix!  I write accounting software that deals with this.

We handle it this way.  Every document has a revision number associated with it.  This includes quotes, POs, Sales orders, RFQs, Invoices, etc...

Each document has a series of actions that can be applied to it through a cycle.  It's pretty easy.  The cycle works like this:

1.  Create new.  Each document has to start some where.  In our system a Sales Order can be created from a Quote but I won't get into that.

2.  Each document with status of NEW sits in the system and can be edited time and time again but not printed.

3.  When a document is RELEASED or POSTED, the document can be then be printed.  One of our customers puts in 100 to 200 quotes a day and at the end of the day, they batch the POSTing.  When POSTing a New document the revision sits at 0 for.

4.  Now, if a document needs changing after it has been POSTED, a CHANGE ORDER must be made.  The Change Order action takes the document back to an Edit state where it can not be printed unless it's RELEASED or POSTED again.  When it's RELASED again, we increment the Revision number and, if the customer wants transaction tracking, we take a copy of the document before the Change Order.

5.  Depending on the document and the customer's needs, we can cross out lines and do fancy things like that -- highlight new lines, etc... Most don't want this but we have a couple that do.

Also, to do transactional tracking you essentially (at least we do) keep tables in duplicate for the header,  lines data.  For example:

salesord_hdr  (header)
salesord_lns  (line items)

rsalesord_hdr (header revisions)
rsalesord_lns (line item revisions)

We also have logic/capabilities to roll back or peer back at old versions.  Also, depending on the customer, our security mechanisim can require a manager approval to create change orders.
~Eric
Friday, July 07, 2006
 
 
"Other things to be cautious of; you need to "freeze" item prices into things like quotations and orders. If a customer agrees to an order and then the price of one of the items goes up, the order value can't change (it's part of a contract). So having line items on the orders refer back to items is only OK for descriptions, and not the prices -- they have to be copied at document generation time."

We deal with this too through document transfers.  In our system a Quote can be created/generated, editied, re-relased with the same flow I mentioned in my last post.

When a Quote is transferred to a sales order, that sales order will always pick it's prices from the originating quote.

Anyway, not such a simple invoicing system we have but the OP was looking for simple....  It's not simple! :)
~Eric
Friday, July 07, 2006
 
 
Thanks eric, i have to agree that eventhough i mentioned that my Invoicing program was simple, it was not simple or easy to develop. I meant easy for the users.

After reading yours and the other post, I have realised that there were lots of things my program does not do. But I am still going to repeat my reasoning for developing it that way:
- Most of the Users / Small companies do not use most of the features in a full fledged Invoicing systems. Some might but then as someone mentioned, they will buy a more professional one (some even come with ith 2 days training provided). Mine just needs 5 mins and a beginner can create and print a Invoice.
- I am assuming that my customers will make mistakes when creating Quotations, Invoices, DO etc. Thats why easy editing of all documents is important. Its not easy, doing a demo in front a customer, printing out sample Invoice and then say can't edit to customer when he spots mistake in sample Invoice. Hope you see what I mean.
- Printing of empty Invoices, Quotes etc are very important for the customers I am targetting. No getting around that.
- Some mentioned that I should reconcile with another Accounting program and it is perfectly right. But my program does not, it just allows printing of simple billing, customers, stock report.

Thanks for all the suggestions and comments. Really..
suhumaran Send private email
Friday, July 07, 2006
 
 
I think there's a market for the Simple Invoicing System. If someone wants me to come over and clean the malware off of their system, I usually charge them dinner or a couple of beers. Handing them a basic invoice would emphasize that they really need to practice safer computing.

That said, it's hard to see what the difference is between a Simple Invoicing System and a really nice word processing template, or Access database front end.

Suhumaran, I wish you luck with your project. I just want to caution you against spending a lot of time trying to engineer security (or elaborate features like sales tax) into it.
TheDavid
Monday, July 10, 2006
 
 
To theDavid, ok I get it, you are a genius who can create the most secure program with super ease of use and I am a dumb guy who makes a simple Invoicing system with lousy security issues.
Well, I have decided to retain my "ease of use" features but with a complete Audit tracking system for all documents created..and while you are gloating and thumping your stupid chest, I am going to sell my program and make some mullah...
and if anyone finds errors, malware, virus in my program, don't worry, I will email you since you are the genius who can create the most secure program with super ease of use.
suhumaran
Monday, July 10, 2006
 
 
or theDavid might just be a dumb guy who posts stupid unconstructive comments in forums.
theGoliath
Tuesday, July 11, 2006
 
 
"Simple invoicing" is by no means simple.  Making it simple for the user is, indeed, a very good cause - but there are *very* good reasons for the complexity under the hood.

The cost of improperly doing financial records, including invoices and purchase orders is ***HUGE***.  At minimum it will cost many hours of some expensive accountants time.  At worst, it will land you in federal 'Pound me in the ass' prison for a while.

As the designer of such a system, you have an obligation to ensure that your software meets your interface design requirements while meeting *major* *important* constraints your accounting-newbie customers dont even know about.  They aren't just for "big companies" but ANY company doing business.  This means you should be doing a significant amount of homework before writing a single line of code - you should be attending fairly advanced accounting and business courses.  You should be getting your designs blessed by an both an experianced laywer and accountant.  Both know way more about accounting then you or I.

The people buying your product trust you are an expert who will keep them out of trouble.  Make *sure* your software doesn't land newbie business owners in a world of hurt!
Cory R. King
Thursday, July 20, 2006
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz