I'll work on the unique problem in a minute; but, based on your other
comments, I may not be fully understanding your business model. When you say
the "correct two for the claims 2308" were flagged, that is because there
was a difference in the R.Code (the first two entries had identical Claims,
Codes and R.Codes... the third one (as far as I am concerned) was unique
(because its R.Code differed). Your comments make me think you see a linkage
here that I am missing (which would affect how I constructed my formulas).
Is there some over-riding control (such as the Claim number) which binds the
groupings? Also, when you ask why the "last one wasn't flagged", that make
me now think you want all but the highest price flagged... is that correct?
I mean, the last three have identical Claims, Codes and R.Codes, so there
are three amounts to look at... are you saying you want the lowest *two*
prices flagged? And if there were four matching records, then you would want
the lowest *three* prices flagged? If so, I missed that completely from your
initial posting.

Rick


wrote in message
...
Hmm. I see your view on the unique row being the lowest value, and
that makes sense :) However, what it is we are looking at is
basically overpayments. We have it listed as paid. If a claim
number, rate code, and R. Code is the same, we are flagging the lower
of the amounts as d for us to investigate the overpayment, somehow,
some way, a bill was submitted twice and they paid a part of it
twice. A claim number, rate code, and R. Code should only have one
paid amount. So, uniques are fine.
The 2nd part, when I said row 5, I was counting the header row. If we
don't count the header row, then yes, row 5 should have been flagged d
which it was. Any ideas why the last one wasn't flagged? It flagged
the correct two for the claims 2308.

Is there anyway to have it leave the unique rows as blank, no code?

2917 v8.07 5039 $57.35 D
2917 v8.07 5039 $93.18
2917 v8.07 5039 $63.07