I would probably throw that requirement right back to the stakeholders. The easiest thing to do is say, if there is no exact match, put the whole amount into a suspense account and run it back through a manual process. Often the answer back will be - "put only the extra into a suspense account" or "apply any extra to the oldest invoice."
That really does seem like a requirement that has not been thought over very well, but then, it may make a ton of sense in your environment. :)
-Paul
On Sep 30, 2014, at 10:40 AM, Roger Harman <roger.harman@xxxxxxxxxxx> wrote:
Yep, the requirement to match (allocate) all or nothing throws a wrench into it. Additionally, there may be a credit (or credits) against an invoice (or invoices) which needs to be factored in before we start the matching so we deal with net amounts owed.
> To: rpg400-l@xxxxxxxxxxxx
> From: paul.raulerson@xxxxxxx
> Subject: Re: Combinations & Permutations..... sort of
> Date: Tue, 30 Sep 2014 15:33:29 +0000
>
> Wonderful fun stuff. :)
>
> Of course, you realize that the algorithm you choose to do this also knocks down, usually pretty dramatically, the number of choices and compares you have to deal with.
>
> For example, in English, here is roughly the way one of my AR packages looks at and matches up payments and invoices.
>
> For payment 9999 in the amount of $999.99 from clientID 9999:
> For unpaid or partially paid invoices billed to clientID 9999,
> Sort by date, showing the oldest invoice first.
> Find exact match for payment? - > If yes, pay it.
> No exact match
> Pay oldest invoice
> Repeat find of exact match
>
> All of payment applied?
> Yes, is there change left over?
> (varies by program, can range from putting into suspense account to refund of overpayment to applying the overage to different balances....)
> No Change
> Apply payment transactions
>
> ....
>
> Of course, it gets much more complex if you need to apply payments on invoices for different interest rates, promotional payments,
> and many other issues, but running a select for exact match usually cuts the run time down quite a bit.
>
> I realize in your case, you are looking got not have any "change" left over, so you may need to get more creative, for example, checking for an exact match on 1/2 the payment - late fee, in cases where you are dealing with periodic payments, such as utilities or any consistent period recurring billing.
>
> Hope that helps -
> Paul
>
>
>
>
> On Sep 29, 2014, at 11:58 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx > wrote:
>
> Hey Roger - it's been a long time since my math major days!
>
> So Google is my friend - combinations are unordered sets from a larger
> set - sounds like that's what you want. A number of combinations of n
> items taken k at a time is n! / (k! * (n-k)!)
>
> For the non-math folks, n! is n-factorial, or the product of all number
> from 1 to n - 1 * 2 * 3 * ... n-1 * n - so 2! is 1 * 2 = 2
> So if n = 2 and k = 1, 2C1 = (2*1)/(1*1) = 2 (a trivial case)
>
> The sum of combination so n items taken k at a time, where k ranges from
> 0 to n, is 2**n - as one article says, the binomial theorem shows this -
> and Pascal's triangle is an easy way to see it -
>
> 1 = 1
> 1+1 = 2
> 1+2+1 = 4 = 2C0 + 2C1 + 2C2
> 1+3+3+1 = 8
> 1+4+6+4+1 = 16
>
> If you take out the one with 0, you have 2**n - 1
> etc.
>
> So by this, for 10 items, the total combinations is 2**10 - 1 = 1023.
>
> To walk through this, you don't want to go backwards - if your items are
> the letters from A - J, you don't want to get anything like B-A or I-D.
>
> Does that help some? It should certainly make the job shorter!! Your
> total is more along the lines of 2**22 - probably some zero-ish things
> ignored.
>
> I'm wondering if some kind of recursion would help - there are code
> samples for generating these things out there.
>
> Vern
>
> On 9/29/2014 8:02 PM, Roger Harman wrote:
> > After some more thinking, I believe I've figured out the total.
> >
> > For 10 items, there are 4,037,913 possible combinations.
> >
> > Calculated as:
> > for x01 = 1 to 1
> > Total += 1
> > for x02 = 1 to 2
> > Total += 1
> > <and so on >
> > for x10 = 1 to 10
> > Total += 1
> > endfor
> > endfor
> > endfor
> >
> > Smaller sample size is definitely in order.
> >
> >
> >
> > > From: roger.harman@xxxxxxxxxxx
> > > To: rpg400-l@xxxxxxxxxxxx
> > > Subject: Combinations & Permutations..... sort of
> > > Date: Mon, 29 Sep 2014 17:17:55 -0700
> > >
> > > Put your math hats on......
> > >
> > > I'm looking at a means to *attempt* to auto-match payments to invoices. We do not want to apply payments to oldest first and end up with a partial payment or credit leftover.
> > >
> > > Pick an arbitrary number of invoices for the attempt - say 10.
> > >
> > > Any combination of 1 or more of these 10 invoices that total the payment amount would be considered a match.
> > > Could be invoice 1, or 2, or.... Could be invoices 2 and 5 and 8..... etc.
> > >
> > > I assume it's going to have to be a brute force approach but I'm stumped on the total # of possible matches. Combinations & permutations I understand (3 out of 10, etc) but this "1 or 2 or (1 and 2) or (2 and 5 and 8)" is giving me a mind block. I do know it's a big number and I'll likely cut back the sampling size.
> > >
> > > Any suggestions or clarifications would be very welcome.
> > >
> > > Thanks.
> > >
> > >
> > >
> > > Roger Harman
> > >
> > >
> > > COMMON Certified Application
> > > Developer – ILE RPG on IBM i on Power
> > >
> > >
> > >
> > >
> > >
> > > --
> > > This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list
> > > To post a message email: RPG400-L@xxxxxxxxxxxx
> > > To subscribe, unsubscribe, or change list options,
> > > visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
> > > or email: RPG400-L-request@xxxxxxxxxxxx
> > > Before posting, please take a moment to review the archives
> > > at
http://archive.midrange.com/rpg400-l.
> > >
> >
>
> --
> This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at
http://archive.midrange.com/rpg400-l.
>
> --
> This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at
http://archive.midrange.com/rpg400-l.
>
midrange.com
