Steve,
It all works quite well. The looping script has three checks. After
locating all outstanding invoices it compares the total owed with the
amount offered for payment. If the payment is higher than what is owed
an error message is displayed and the script is closed. If the amount is
less than owed then it starts to pay down the invoices from the oldest
invoice date. As it pays off each invoice its running a calculation
comparing every next invoice with the amount still available from the
original decreasing payment figure. While funds remain from the
original payment, the script continues paying down the invoices. If the
running calculation (remaining funds) equals the next invoice the script
exits after that payment. If the amount left on the payment is less than
the total of the next invoice then it pays the remaining amount left of
the original payment to the next invoice which will still leave that
'last' invoice with a balance outstanding. For example if the remaining
funds from the running calculation is only $45 and the next invoice is
$145 then it 'pays' the $45 to that invoice leaving a balance of $100
which will be the first invoice off the blocks in the next 'Auto Pay'
which is what I call that option.
Its a real benefit to those clients who have many invoices to one client
and don't want to pay them off one by one. An example of this is where a
client offers payment of $5,000 when they have 120 invoices outstanding.
My 'Auto Pay' script will make that payment in a couple of seconds by
paying out maybe 102 invoices and the balance on the next invoice as
explained above.
Yes I've been creating solutions for a long time too and this has always
been a nuisance for clients. However, now it is very smooth and they're
happy. This whole thing came up when one client had this anomaly with
the global field. So I've done the work around and its more robust than
before, thankfully. I'll have to now contact my other clients running
this script so I can update there's too in case they experience the same
anomaly. Its 4 am here so I'm back to bed if you have any other
questions i'll check when I get up later.
Steve Cassidy wrote:
Hmmm...
I think somehow it's an issue of the focus of the calculation. I
suspect the logic of the process too -- but then I can't see your
script so I don't know exactly what you are doing. (I can't see how
you get the global calc to take account of more and more records as
you pass around the loop multiple times...)
Anyway, I note that you've made a change such that, at each pass
around the loop, you use a Set Field to grab the new amount remaining.
To my mind this is the sensible and logical way to do things. It is
also very clear (when you need to read the script in five years time)
and will never depend on the current record. This is exactly how I've
solved a similar problem in the past.
Incidentally, as an aside, what actually do you do when you reach an
invoice that the remaining amount is insufficient to pay off? I worked
on a solution like this for ages (having told the client that it was a
silly idea -- but the customer is always right, as you know...). In
the end we did abandon it (meaning that I persuaded the client to
abandon it) because things just got too complex... You end up with an
amount of credit outstanding that's not enough to pay off the current
debt. Then another payment (credit) comes in, so you have to finish up
the previous one then start using up the new one. It's even possible
that two current credits are insufficient to cover the debt... OMYGOD...
It's actually much simpler to run a regular credit scheme: credits on
one side, debits on the other, and the balance is the balance. Monies
do not pay off particular invoices but simply deduct from the amount
owed.
So I'm quite interested in how you might handle what can turn into
quite a complex situation...
Steve
On 10 Sep 2008, at 18:27, Lee wrote:
As I said its hard to explain but I've removed the global field and
its working fine. I have 3 other clients using the original script
and they haven't had any problem, its just been this one client who
has found this anomaly.
--
