Hi guys, I'm curious about this statement (context at the end of this email):
> I agree > that it should be reasonable to setup a separate Freqspec for the > repayment schedule, but the loan itself needs one. Given: PV( rate, nper, pmt [, fv, type] ) Calculates the present value of an investment @rate : periodic interest rate @nper : number of compounding periods @pmt : payment made each period @fv : future value and nper = the payment schedule the bank agreed to nper' = the actual payment schedule pmt = the payment amount the bank agreed to pmt' = the actual payment amount Clearly the alternate payment schedule can only be ongoing (and therefore a candidate for an SX) if the bank agrees to it. So I'm thinking that means either 1. PV(rate, nper, pmt) = PV(rate, nper', pmt'), or 2. nper' > nper, and the bank is effectively just waiting for the next due date to apply all the money they received since the last due date. In the case of 1, your SX is for nper' and pmt' and I don't know why you would need/want to know nper or pmt. In the case of 2, you're not really using nper' or pmt', you're just dividing pmt up into a multiple chunks and spreading them out within the period defined by nper, whatever that is. What would you do with the "other" Freqspec? This thread started a while ago, so if I missed some evolution, sorry. As an aside, for case #2, I would think that any bank would allocate $$ to interest first, but after that it might depend on the bank. Olaf On Friday 05 July 2002 07:08 am, Derek Atkins wrote: > Josh Sled <[EMAIL PROTECTED]> writes: > > | I'm torn over whether the Principal Account (and frequency) should be > > | defined here or in the Repayment page... There are certainly > > | arguments for both ways of doing it. Consider that you need the > > | Principal Account in order to compute IPMT every period... > > > > Not really relevant to setting the SXes up, though. Plus, I think it > > makes more sense that the high-level data about the loan is on one page, > > but specifics of individual repayments are on another. > > Except you need to know the repayment schedule to properly setup the > loan schedule. They are inherently tied together. You need to know > the payment frequency in order to compute PMT (which is something I > think you should be doing in the Druid to help the user). I agree > that it should be reasonable to setup a separate Freqspec for the > repayment schedule, but the loan itself needs one. > > For example, you could have a loan that has a monthly repayment > schedule, but the user sets up bi-weekly payments. > > Or do you really only care about the actual repayments and not the > loan itself? I was envisioning a Druid where you plug in the > principal, interest, and payment schedule (and maybe escrow amount) > and it will compute and display the monthly PMT amount, which the user _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
