Answer by JimmyPena for "And" and "Or" troubles within an IF statement

I like assylias' answer, however I would refactor it as follows:

Sub test()Dim origNum As StringDim creditOrDebit As StringorigNum = "30062600006"creditOrDebit = "D"If creditOrDebit = "D" Then  If origNum = "006260006" Then    MsgBox "OK"  ElseIf origNum = "30062600006" Then    MsgBox "OK"  End IfEnd IfEnd Sub

This might save you some CPU cycles since if creditOrDebit is <> "D" there is no point in checking the value of origNum.

Update:

I used the following procedure to test my theory that my procedure is faster:

Public Declare Function timeGetTime Lib "winmm.dll" () As LongSub DoTests2()  Dim startTime1 As Long  Dim endTime1 As Long  Dim startTime2 As Long  Dim endTime2 As Long  Dim i As Long  Dim msg As String  Const numberOfLoops As Long = 10000  Const origNum As String = "006260006"  Const creditOrDebit As String = "D"  startTime1 = timeGetTime  For i = 1 To numberOfLoops    If creditOrDebit = "D" Then      If origNum = "006260006" Then' do something here        Debug.Print "OK"      ElseIf origNum = "30062600006" Then' do something here        Debug.Print "OK"      End If    End If  Next i  endTime1 = timeGetTime  startTime2 = timeGetTime  For i = 1 To numberOfLoops    If (origNum = "006260006" Or origNum = "30062600006") And _      creditOrDebit = "D" Then' do something here      Debug.Print "OK"    End If  Next i  endTime2 = timeGetTime  msg = "number of iterations: "& numberOfLoops & vbNewLine  msg = msg & "JP proc: "& Format$((endTime1 - startTime1), "#,###") & _" ms"& vbNewLine  msg = msg & "assylias proc: "& Format$((endTime2 - startTime2), "#,###") & _" ms"  MsgBox msgEnd Sub

I must have a slow computer because 1,000,000 iterations took nowhere near ~200 ms as with assylias' test. I had to limit the iterations to 10,000 -- hey, I have other things to do :)

After running the above procedure 10 times, my procedure is faster only 20% of the time. However, when it is slower it is only superficially slower. As assylias pointed out, however, when creditOrDebit is <>"D", my procedure is at least twice as fast. I was able to reasonably test it at 100 million iterations.

And that is why I refactored it - to short-circuit the logic so that origNum doesn't need to be evaluated when creditOrDebit <> "D".

At this point, the rest depends on the OP's spreadsheet. If creditOrDebit is likely to equal D, then use assylias' procedure, because it will usually run faster. But if creditOrDebit has a wide range of possible values, and D is not any more likely to be the target value, my procedure will leverage that to prevent needlessly evaluating the other variable.