abijah
bcbe3767e3
Check in the near completed implementation of security deposit utilization. It was on it's way to working well (although it only works for existing payment divs and there is not an obviously easy way for new payment divs to have the security deposit info as well). It feels like we've really gone overboard on the payment screen, pushing too much together. I'm going to strip some of this out on the next checkin, and create a dedicated security deposit utilization screen, perhaps just as part of move-out, or perhaps part of move-out and as an independent operation as well.
...
git-svn-id: file:///svn-source/pmgr/branches/invoice_receipt_20090629/site@292 97e9348a-65ac-dc4b-aefc-98561f571b83
2009-07-10 07:25:55 +00:00
abijah
abd166cb98
Modified effective dates to be part of the ledger entry, not the transaction. This is the logically correct way, as a transaction is simply a collection of entries which might be anywhere from completely aligned to totally disjoint from one another (more likely the former). As a practical example, consider a move-in invoice, with security deposit (effective immediately with no end date), a prorated rent (effective move-in day through the end of the first month), and first full months rent (effective beginning of next month through the end of next month). There is certainly more work to be done on this, and testing was minimal. It does seem to be functioning though, so I'm checking in.
...
git-svn-id: file:///svn-source/pmgr/branches/invoice_receipt_20090629/site@256 97e9348a-65ac-dc4b-aefc-98561f571b83
2009-07-08 16:04:53 +00:00
abijah
011c05d098
Implemented the balance field of Leases as part of a single query. This not only reduces the number of queries required, it also allows balance to be a sortable column, so that we can determine which customers are overdue.
...
git-svn-id: file:///svn-source/pmgr/branches/invoice_receipt_20090629/site@251 97e9348a-65ac-dc4b-aefc-98561f571b83
2009-07-07 16:08:56 +00:00
abijah
dfe20e7ef9
Finally, finally... a working version for payment entry. The current schema is working well, and seems to handle our technical needs. However, it does seem to be very confusing with the extra accounts. Nonetheless, it does work and so I'll keep going down this path. This checkin also includes a mechanism to close the books on an account (by closing the underlying ledger) and start a new ledger. One of the decisions worth revisiting is separating out ledger entries that are really part of the same transaction. Without this change, inspecting a transaction results in the transaction total being off by a factor of two, since all money movement is in their twice (once for the expected reason, and again to hit the invoice/receipt ledger).
...
git-svn-id: file:///svn-source/pmgr/branches/invoice_receipt_20090629/site@195 97e9348a-65ac-dc4b-aefc-98561f571b83
2009-07-01 08:17:31 +00:00
abijah
73eacdbcf2
More changes. I just can't seem to come up with a solution that works that I like. The problem now, without invoice/receipt, is that one check cannot cleanly pay for two units.
...
git-svn-id: file:///svn-source/pmgr/branches/single_AR_20090622/site@182 97e9348a-65ac-dc4b-aefc-98561f571b83
2009-06-24 00:33:39 +00:00
abijah
009ea6b44d
Nowhere near done yet, but checking in a snapshot of semi-working code. There is some simultaneous support for both with and without use of the Invoice/Receipt account. I want to do away with them completely, but will need to change how sitelink payments are mapped (right now, they split a payment into multiple parts to match the charge).
...
git-svn-id: file:///svn-source/pmgr/branches/single_AR_20090622/site@181 97e9348a-65ac-dc4b-aefc-98561f571b83
2009-06-23 19:04:41 +00:00
abijah
de93c7545b
Experiment to group ledger entries by their transaction ID instead of their entry ID.
...
git-svn-id: file:///svn-source/pmgr/branches/ledger_transactions_20090605/site@177 97e9348a-65ac-dc4b-aefc-98561f571b83
2009-06-22 19:03:08 +00:00
abijah
d5388e7767
Although I'm not too happy with the modifications, I do have a working version that minimizes the columns need to display ledger entries. The logic feels screwy to me, but I've beat my head on it long enough. I'll move on to something else and come back to it when my head clears.
...
git-svn-id: file:///svn-source/pmgr/branches/ledger_transactions_20090605/site@166 97e9348a-65ac-dc4b-aefc-98561f571b83
2009-06-18 03:57:43 +00:00
abijah
5dd3efa12f
Added initial support for ledger entry reconciliation (e.g. matching payments to charges).
...
git-svn-id: file:///svn-source/pmgr/branches/ledger_transactions_20090605/site@152 97e9348a-65ac-dc4b-aefc-98561f571b83
2009-06-16 21:40:46 +00:00
abijah
c3139220ee
Moved the ledger_entries controller/view to jqGrid.
...
Changed the app controller jqGrid virtual functions for getting the tables for both count and the full query. The ExtraTables bit was too confusing, and was only intended to allow the user to specify a subset for count and augment it for full query. This is easily accomplished by having DataTables just call DataCountTables first... one line solution ends the confusion.
Modified linkable behavior to support a %{MODEL_ALIAS} tag, which is replaced in the relationship conditions at runtime with the actual model alias. This is experimental at best, and certainly will create a problem for any model that ends up using the conditions in 'contain' instead of 'link'.
Broke the LedgerEntry->findInLedgerContext function out into multiple pieces, so those same pieces could be used in the LedgerEntries controller to populate jqGrid.
Changed the ledger_entries element, as a special case, to also allow listing control from ledger_id and account_type, instead of idlist as a mechanism for populating the grid.
Changed the infobox summary css, which will break several pages until I rework them.
Some next steps include fixing the broken infoboxes, and changing the transactions view to use the ledger_entries element. This also means the ledger_entries element will need to add support for idlist, or if we have any credit/debit issues, perhaps another custom transaction_id instead.
git-svn-id: file:///svn-source/pmgr/branches/ledger_transactions_20090605/site@134 97e9348a-65ac-dc4b-aefc-98561f571b83
2009-06-15 19:41:20 +00:00
abijah
e0d9edc4a8
Primarly a cleanup checkin, although a couple minor bugfixes were included as well.
...
git-svn-id: file:///svn-source/pmgr/branches/ledger_transactions_20090605/site@82 97e9348a-65ac-dc4b-aefc-98561f571b83
2009-06-10 05:14:08 +00:00
abijah
ffd1b64580
Significant changes to work with the new account/ledger structure. Removed much of the auto-generated model association code. Added helper functions into the models to perform model related work, such as model 'stats' (a bad name for a function to return a summary of pertinent financial information from a given model instance). There is a ton of cleanup to do, but first I want to get it all captured.
...
git-svn-id: file:///svn-source/pmgr/branches/ledger_transactions_20090605/site@81 97e9348a-65ac-dc4b-aefc-98561f571b83
2009-06-10 02:41:23 +00:00
abijah
677458e942
I'm still in the middle of moving onto a ledger based system. However, I'm am now changing how transactions and entries relate back to the customer. I'll be using a ledger for each lease (for rent, late charges, security deposits, etc), and a ledger for each customer (for POS, non-specific deposits such as reservations or covering mulitple units, bad debt writeoff, and possibly customer credits, when not obviously lease specific). This coming change might not be in the right direction, so I want to capture the work as is right now. This change set is not fully functional. Many operations do work, but there are obviously transaction problems with units and customers.
...
git-svn-id: file:///svn-source/pmgr/branches/ledger_transactions_20090605/site@71 97e9348a-65ac-dc4b-aefc-98561f571b83
2009-06-06 20:18:56 +00:00
