loan/mortgage repayment via sched xactions: feedback request

[Olaf Faaland]

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 =3D the payment schedule the bank agreed to
  nper' =3D the actual payment schedule
  pmt =3D the payment amount the bank agreed to
 pmt' =3D the actual payment amount

Clearly the alternate payment schedule can only be ongoing (and therefore=
 a=20
candidate for an SX) if the bank agrees to it.  So I'm thinking that mean=
s=20
either

1. PV(rate, nper, pmt) =3D PV(rate, nper', pmt'), or=20
2. nper' > nper, and the bank is effectively just waiting for the next du=
e=20
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=20
need/want to know nper or pmt.

In the case of 2, you're not really using nper' or pmt', you're just divi=
ding=20
pmt up into a multiple chunks and spreading them out within the period=20
defined by nper, whatever that is.

What would you do with the "other" Freqspec?  This thread started a while=
 ago,=20
so if I missed some evolution, sorry.

As an aside, for case #2, I would think that any bank would allocate $$ t=
o=20
interest first, but after that it might depend on the bank. =20

Olaf

On Friday 05 July 2002 07:08 am, Derek Atkins wrote:
> Josh Sled <jsled@asynchronous.org> 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 pa=
ge,
> > 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