Calc Invoices to Pay?

[Bruce Easton]

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.