I strongly believe Simple Invoice should handle this scenario ...
Let's say, I create a new customer and a new I total style invoice. I print the invoice number 123 and send it to my customer ... the customer pays (sometimes this happen too!).
After some time, the customer changes location and you update its details in the database. I create a new total style invoice numer 985 and send it along to the new address ... the customer pays
Suddenly, the customer calls and requests a copy of invoice 123. I try to print it and what happens, this invoice 123 is now printed with the last updated details of the customer, which is legally WRONG. You should not be able to print the same invoice twice with different details ...
Unfortunately, the DB layout as it is now ... doesn't allow such a feature. When you try to change a biller or customer data, the system should at least warn you that invoices are linked to this profile.
Common workarounds to the general problem of transaction specific data - especially rarely changing data (RARE):-
1. PDF files generated can be stored in a folder archived with timestamp as part of name prefix for ease of sorting. Very inelegant and huge wasted storage space on large hard disks with huge cluster sizes.
2. Archival database and a separate SI installation that can be used with it - just restore the appropriate archive and generate the PDF Invoice. The time between Archive Snapshots of the DataBase will ignore more than one address change and hence an archival is necessary before the moment a data element (RARE) changes more than once.
3. Have a separate address (and other RARE) database to archive changed addresses (as opposed to mere correction of typos - difference mostly safely ignored) and change th ecode in SI to use an older address under appropriate logic.
4. Use an Identifying Relationship with a separate address table and use the current address fields in te Customer table as current defaults that need to populate corresponding fields newly created in the invoice transaction table. This is the best way and the invoice will always have the correct data as at the time of creation.
it does highlight an issues greater than address though
ie. if you change a product name - it affects all previous invoices, if you change a customer name etc.. if all affects previous emails
only way to handle them all is to record all details in the invoice_items table ie prod name, address etc.. - though that is a big waste of space or offer some archival of db or pdfs
I like the approach #4. Creating an "read only" versions of the invoice foreign key tables (for biller/customer/product/tax/preference/style...) is the way to go. We absolutely have to keep track that on 01 january 2001, you sold Product X at $.45 to Mr X invoiced by company Y with .06% taxes
In order to please everybody, people thinking this a waste of space could just disable this new functionality.
The PDF solution is nice and doesn't request much work, but personally, I like the #4.
