First pass implementation at generating an invoice, which seems to be working. Largely untested, but worth checking in. Next is to get receipts using the same algorithm, and after that will be to work on a reconciling mechanism, creating payments, and matching them to charges. This checkin includes an additional customer_id fields as part of the transactions table. I think it was an oversight not to be there, as we need some way to keep track of monies which have been paid by a customer, yet not applied. If there is a different way to do it (short of actually having each ledger entry hold customer_id), it escapes me at the moment.

git-svn-id: file:///svn-source/pmgr/branches/yafr_20090716@372 97e9348a-65ac-dc4b-aefc-98561f571b83

db/schema.sql

@@ -973,6 +973,22 @@ CREATE TABLE `pmgr_transactions` (
 
   `stamp`                TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
 
+  -- All entries of a transaction should be for the same
+  -- customer.  By keeping track of customer here, it ensures
+  -- that we can always track what's happening with the user
+  -- even if there are only ledger entries, and no statement
+  -- entries for some reason (the primary concern being the
+  -- receipt of money, with nothing to pay for).
+  -- customer_id can be NULL, for internal transfers and such.
+  -- In that case, there should be no statement entries for
+  -- this transaction, only ledger entries.
+  -- REVISIT <AP>: 20090723
+  --  It sounds like a transaction that has customer_id as NULL
+  --  is really a fundamentally different type of "transaction".
+  --  Do we need to have a new table for those type of
+  --  entries / activities?
+  `customer_id`          INT(10) UNSIGNED DEFAULT NULL,
+
   -- The account/ledger of the transaction set
   -- (e.g. A/R, Bank, etc)
   `account_id`           INT(10) UNSIGNED NOT NULL,
@@ -1072,6 +1088,9 @@ CREATE TABLE `pmgr_statement_entries` (
   `through_date`         DATE DEFAULT NULL, -- last day
   `due_date`             DATE DEFAULT NULL,
 
+  -- Customer ID is redundant, since it is saved as part of the
+  -- transaction.  Keeping it here anyway, for simplicity.  If it's
+  -- truly redundant, and unnecessary, we can always re
   `customer_id`          INT(10) UNSIGNED NOT NULL,
   `lease_id`             INT(10) UNSIGNED NOT NULL,