RE: Combinations & Permutations..... sort of -- RPG400-L

Essentially, that is what happens. If we can match the entire payment amount, wonderful. If not, it just posts as unallocated and they have to review it. Anything to offload the manual intervention is a plus. There is a lot of volume.

Admittedly, it's not what I would normally think of in remittance processing but I understand the requirement and, yes, it does make sense to do in our environment.

As previously mentioned, there is a process in place doing this but it is in serious need of a rewrite and the opportunity is ripe for improving it.

To: rpg400-l@xxxxxxxxxxxx
From: paul.raulerson@xxxxxxx
Subject: Re: Combinations & Permutations..... sort of
Date: Tue, 30 Sep 2014 15:47:24 +0000

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.
>

--
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.