Calc Invoices to Pay?

[Stanley Barnett]

> For a permanent capability for this,
> I would be inclined to build or get a hold of a routine that would,
upon press of hot key (i.e., HELP key), 
> throw up a browse of invoices, keyed to match-only on the account
number, but then by amount, and use drop 
> processing to drop closed invoices.  This should show in the browse
open invoices for the account in amount
> order.  Of course, you'd need an index for the browse built on acct#,
then amount.  It could be faster if 
> you can build it on acct#, then whatever entity denotes open status -
status flag/empty date paid/balance>0,
> and then amount or date (so the index will start right at the open
invoices even if it has to do a 'drop all 
> after').  And if you built one index as acct#,<open status
indicator>,amount and another index as acct#,<open 
> status indiator>,date, then you could provide two hot keys to view
open invoices for an account in either 
> date or amount order (or one hot key and ask amt/date as a question
before throwing up the browse).

This is the easy part, its the code that iterates the records finding
the right combination as a suggestion to pay is what I'm looking for.

 
> I'm assuming that this is to quickly find these records, not try to
automatically distribute payment against
> them - I agree with Mark on that point.

Yes, its needed to identify the records and let a clerk make the final
decision.


> But for just finding these, as a one-time quickie, and you're
comfortable with sql, then what Walter posted 
> looks good. 

I do not see how Walters SQL statement can iterate the records and find
the right combination.


> And if you're comfortable with extended selection, I think this type
of search is easily appliable with a 
> selection set, that you can save and re-use for different amounts by
just changing the amount range values.
 
To my knowledge selections sets cannot iterate the records and find the
right combination.  All it can do is what Walter's SQL statement is
doing which is the very first phase if the process, which is gathering
all unpaid and posted invoices to be considered by the routine that
intelligently creates a list of invoices when summed equals to the
payment amount to the penny.  If it exactly equals to the penny, I want
the list for human verification, otherwise it is a total failure and I
do not want a list, other than a message saying that an exact
combination was not possible.

Thanks,
Stanley Barnett  -  stanley at stanlyn.com
Stan-Lyn & Associates, Inc.  -  http://www.StanLyn.com
Office: (859) 402-8165  -  Cell: (606) 568-5412

-----Original Message-----
From: filepro-list-bounces+stanley=stanlyn.com at lists.celestial.com
[mailto:filepro-list-bounces+stanley=stanlyn.com at lists.celestial.com] On
Behalf Of Bruce Easton
Sent: Tuesday, March 04, 2008 10:23 AM
To: filepro list
Subject: RE: Calc Invoices to Pay?

Stanley Barnett wrote Monday, March 03, 2008 10:54 PM:

> Hi,  Does anyone have any filePro code for this specific problem?  
>
> A customer sends a check for say $2145.54 to be applied to his 
> account.  His account balance is $9845.52 and covers 42 invoices.
> He wrote the invoice numbers on his check, however they are not 
> legible and after spending an hour trying to find the invoices that 
> the customer intended to > pay, I gave up and will need to contact the

> customer for verbal confirmation tomorrow when the customer is in 
> their office.

> I need a routine that can find the correct invoices quickly by only 
> supplying the check amount.  We are assuming the customer did not 
> partial pay an invoice.

> Thanks,
> Stanley Barnett  -  stanley at stanlyn.com

For a permanent capability for this,
I would be inclined to build or get a hold of a routine that would, upon
press of hot key (i.e., HELP key), throw up a browse of invoices, keyed
to match-only on the account number, but then by amount, and use drop
processing to drop closed invoices.  This should show in the browse open
invoices for the account in amount order.  Of course, you'd need an
index for the browse built on acct#, then amount.  It could be faster if
you can build it on acct#, then whatever entity denotes open status -
status flag/empty date paid/balance>0, and then amount or date (so the
index will start right at the open invoices even if it has to do a 'drop
all after').  And if you built one index as acct#,<open status
indicator>,amount and another index as acct#,<open status
indiator>,date, then you could provide two hot keys to view open
invoices for an account in either date or amount order (or one hot key
and ask amt/date as a question before throwing up the browse).

I'm assuming that this is to quickly find these records, not try to
automatically distribute payment against them - I agree with Mark on
that point.

But for just finding these, as a one-time quickie, and you're
comfortable with sql, then what Walter posted looks good. 

And if you're comfortable with extended selection, I think this type of
search is easily appliable with a selection set, that you can save and
re-use for different amounts by just changing the amount range values.

Bruce

Bruce Easton
STN, Inc.



 



_______________________________________________
Filepro-list mailing list
Filepro-list at lists.celestial.com
http://mailman.celestial.com/mailman/listinfo/filepro-list