This website requires JavaScript.
Explore
Help
Register
Sign In
abijah
/
pmgr
Watch
1
Star
0
Fork
0
You've already forked pmgr
Code
Issues
Pull Requests
Actions
Packages
Projects
Releases
Wiki
Activity
Files
769c02a5f162d067b7d3f3565e494e8a2ddea936
pmgr
/
site
/
views
/
leases
History
abijah
04bc284a76
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
2009-07-23 21:24:49 +00:00
..
apply_deposit.ctp
This rework is nowhere near complete, but there are certain things that are falling in place, and worth capturing. I started a branch for just this purpose of being able to check in intermediate work.
2009-07-19 23:35:25 +00:00
bad_debt.ctp
Implemented bad debt write-off. This was tested about as well as the last checkin for security deposit utilization. Also, both of these need a redirect. I'm thinking redirect will have to be controlled dynamically, since we probably want to have them in a sequence of pages daisy changed at move out. Of course, we also will allow them each to be run on their own individually.
2009-07-10 10:06:56 +00:00
invoice.ctp
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.
2009-07-23 21:24:49 +00:00
move.ctp
Standardized the grid events interface, to ease the burden on the views and ensure that the load functions could be used by the application without wiping out the debug functionality that was built into jqGrid.ctp
2009-07-15 06:21:55 +00:00
refund.ctp
This rework is nowhere near complete, but there are certain things that are falling in place, and worth capturing. I started a branch for just this purpose of being able to check in intermediate work.
2009-07-19 23:35:25 +00:00
view.ctp
More tweaking to all of the grid displays. This was mostly visual, but includes some bug fixes as well (such as a manual filter override in the ledger_entries controller).
2009-07-23 16:53:33 +00:00