Hi folks,
I’m looking at auto inserting salutations + updating salutation formatting based on constituency and a few other things. I’m conscious of overwriting custom salutations that do not meet the format and noticed that in UP_REBUILD_SALUTATIONS it refers to ‘!’ being returned from AP_BUILD_SAL as a flag to not update what is there.
I tested entering ‘!’ into the esal1_desc a few different ways but when I hit the GenSal button it still updates.
Does anyone know how/where the ‘!’ is supposed to be entered so it is read correctly by UP_REBUILD_SALUTATIONS?
Thanks as always!
Natasha
Hi Natasha
Sadly, that "!" code is for using in TR_SALUTATION_FORMAT, for the purpose of locking down a whole salutation type format, not at the individual constituent level.
For example, we decided to take over the esal2_desc field for an organisation name, so we've got ! in the *_namel2 format columns for relevant sal formats. That blocks them from being updated by the GenSal routine.
But there's no way to block at the constituent level, AFAIK. As I've suggested a few times, that would be an excellent use case for developing a Service Interceptor, but I don't think anyone's done it yet - I certainly haven't, in spite of having talked about it. If anyone has, raise your hand?
Ken
Ah ok then, thanks Ken. I guess that makes sense as I was wondering how the ‘!’ was stripped when it came to actually outputting the salutation info.
We have an attribute that we use to stop LP_CUSTOMER_RANK from updating certain accounts, so perhaps I will go down that path as I suspect there will be so few anyway. It would be extremely helpful as you said to have something at the constituent level that didn’t involve having to add attributes or other flags etc.
I haven’t really looked at the grand possibilities of interceptors so this may be obvious, but if you were to create a service interceptor, what logic would you use to stop it at the constituent level that you couldn't do in SQL? I’m thinking that the account would still need to be flagged in some way... wouldn’t it?
Yes - you would still need something (presumably an attribute) to mark the constituent as having a locked salutation.
And you certainly could do it in SQL with LP_CUSTOMER_RANK, in the same way. But Service Interceptors will be a more general tool, and I guess I thought of this as a nice simple one to start learning about them with.
Good point! Perhaps I shall try my hand at this.
Thanks again,