Case insensitive substring filter in a BAQ

Our RMA team has to activate inactive parts so we can process the RMA(create a job), but that means they have to remember to inactivate the part after we are done processing the RMA. We decided to come up with a simple process to add the word “inactive” to the description and then create a monthly report showing all active parts with the work “inactive” in the description and corresponding open jobs so we have a reminder to inactivate these parts(and any we may have forgotten - no active jobs)…

So I need to create a BAQ that finds all active parts that will check if inactive is in the description, but I want it to be a case insensitive check. I think I need to do something like what is shown in the screenshot below, but this is resulting in an error. Any pointers?

Sorry to answer my own question. That statement worked, the error was coming from another LIKE statement, but since it showed up when I was defining the new calculated field I assumed that is what the error was referring to…

Hi @embedded,
I’m just wondering what your horizon time (for sake of a better term) for inactivating parts. I would think that you could have a process where the part goes from active to runout to inactive. You should be able to process returns on active and runout parts, then when the part has no transactional activity for some period of time (probably based on sales or shipments), then it could be made inactive.

Just putting that one out there.

Simon Hall

@Hally Interesting idea. We accept RMAs for any part regardless how long ago we sold it, so there isn’t a horizon time where we’re getting ready to inactivate the part and will accept RMAs, and then once it goes inactive we won’t accept RMAs any longer. If you bought something from us 20 years ago and we’ve had the part inactive for the last 10 years company policy states we need to process the RMA.

I think this is what you were asking?

Yes that’s what I was asking. Wow. That’s service!

ERP database should have Case Insensitive and Accent Sensitive collation. It means that any string comparisons are case-insensitive on the SQL side.

At least, all ERP logic is implemented around that idea.