What does their accountant and bookkeeper say?
How well would their records stand up to an audit by the taxation authority?
Surely those folk become the ultimate arbiters on whether or not their business practices are sufficiently robust.
Here in the UK and I believe other countries too, our tax authority (HM Revenue and Customs) require that sales invoices are numbered sequentially.
This is easier to undertake in a Sales Invoice table, where the sequential serial number can be generated as each new invoice is added.
It can still be produced from a Projects table, if each new Sales Invoice calls for a new record in the Sales Invoice table and uses the new sequential number from that table.
However, nothing beats the list of Sales Invoices in invoice number order as generated by a proper Sales Invoice table.
As far as I am concerned, I now always use a separate Sales Invoice table.
Best wishes - Alan Stirling, London UK.
The most incredible thing I continually see with Invoices from custom databases is the ability to change the Invoice once it has been posted... I have been told by a few people that it is illegal to change an Invoice once it's been sent to the recepient. If you have a problem with it, create a new Invoice or credit the existing Invoice then create a new one. Seems like a painful business process to me!
An invoice should certainly be a separate record to the original project and then locked off from being able to edit it once it's sent. (well, at least in a perfect world) ;-)
In the US, it is not illegal to change an invoice as long as you represent it as changed or updated, etc. Otherwise you get into the fraud area. However, all accountants will vehemently argue against changing invoices. It is like making a mistake in your bank account. The bank does not "fix" the original mistake by getting rid of it. They instead issue a credit or debit rectifying the original mistake, leaving the original mistake in the account ledger as well as documentation of the correction.
Small businesses are known for being run by entrepeneurs that know their products well, but as a business owner, have to handle all of the other things required in a business like accounting, taxes, HR, etc. Some of these entrepeneurs want lots of control and make decsisions on what seems best to them in areas that they are not an expert and that is where problems like this arise.
As a database consultant, all we can do is provide advice to general accounting principals as well as good practices for software development. A client does not have to follow our advice, nor do we have to work for them if they ignore our advice. If the proposed development is not inherently fraudulent, I usually implement it with warnings to my client on potential problems. I also make sure to not advertise myself as something I am not like an accountant. So when you run into problems like this, a way to get the monkey off our backs as the software developer is to refer them to their accountant which surely will not concur with such a request.
Best of luck!
What John Wolff said. With things like accounting workflow it's helpful to look to existing accounting packages (like Quickbooks) and note deviations froms that workflow. Accounting packages are designed the way they are for good reasons, including some of the ones you outline. Accountants like them because they understand the workflows and trust them.
You could tell the client (gently) that the fact that they are surviving without a good data model and accounting controls is not reason to continue doing so, any more than it would be to continue driving without vehicle maintenance or insurance simply because you've gotten away with it so far.
One way of moving that conversation forward is to ask to bring their accountant in to review the current system's workflow for improvements in a group meeting. The accountant is likely to make your argument for you very convincingly.
Thank you all for the insights.
It was less an issue of legality and accounting practices (I have enough to worry about ) and more one of flexibility and best FM practices. I felt having an invoice table was worth the trouble for the flexibility it gives the user in all aspect, reporting, analysis, data entry and wanted to confirm that.
Many thanks for the detailed thoughts.