Calc Invoices to Pay?

[Fairlight]

With neither thought nor caution, Stanley Barnett blurted:
> > Yeah, but if you have a pool of 35 invoices that are unpaid and get a
> lump sum payment of $1074.37, 
> > the way I understand it you're looking to automatically find the
> combination of invoices that equals 
> > that amount and flag them paid.
> 
> YES, but instead of flagging them as paid, I just want the list and then
> our people will verify and if it makes sense to do so they will manually
> apply the payment to the list.  I totally agree that the program should
> not be the poster.

Okay, I'll try again...

There may not be "one list".  Just like there's not necessarily "one true
way" or "one true OS".

If two sets of invoices can result in the same sum as the single payment,
which list do you want presented?  That in itself is a logistical problem.

Maybe I'm just looking at it the way I usually do--I want a robust solution
that will work no matter how simple or complex the data thrown at it.  You
may have 5 invoices.  That would be simpler to solve, although it may or
may not decrease the chances of multiple solutions--all you need is -one-
pair of invoices in the same amount and you're S.O.L.  But I'm
extrapolating out to something (given the sums you cited) where you might
be looking at 20+, not just 5.

In both cases, a single pair of matching invoices will still throw a wrench
in the works.  So your odds of this working correctly are already slim
enough if there are -any- recurring payments or duplicate orders, for
instance.  But those odds go up as the number of potential collisions
increases due to the number of invoices increasing.

And that just accounts for matching invoices in the same amount.  That
doesn't count permutations where different sums add up to the same sub-part
of the whole sum.  That's further complexity.

It's like multiverse theory; at every branching point, a whole new
"correct" universe (list of invoices in this case) is generated.  Now which
of those "universes" is the "real" one to be presented to the observer,
even if there's a human operator reviewing it?  And there's the practical
problem.  It's not that there are no algorithms available, it's that there
is no guarantee of non-multiple solutions.

mark->