Advanced Search Select fields and Search scope

This question has suggested answer(s)

On an Opportunity I have a Company lookup, and a Fee Basis Lookup. The Fee Basis lookup is Restricted based on the Company selected (cracking functionality by the way). It also has some search SQL on the Fee Basis lookup to show only active fee basis (feba_archived IS NULL).

This works fine for new cases, if a companies fee basis gets archived, it does not show up on the list of available fee basis (isis, we are never sure what the plural of a "Fee Basis" actually is). Once a fee basis gets archived which is already selected on an Opportunity, when we navigate back to that opportunity where it was selected, it appears as though there never was a fee basis selected at all! 

Is there a way to allow the selection to still SHOW the archived (thus out of scope) fee basis and have the search only return fee basis that are NOT archived? The only way I can think my way around this is a cludgy solution of using two fields, one to select the fee basis, and one to store it? 

Am I missing a better way of doing this?

All Replies
  • This is a good question, and behaviour I was not aware CRM displayed.

    I have never tried this, so it is more of a thought that a definitive solution, but could you manage the adv search select via Jscript, to remove the product if it is not active, as opposed to controlling it via the SQL clause on the field itself?

  • For want of a better way of doing this, I have used my two field cludge method. As well as my oppo_feebasis field, I have created a oppo_feebasisnew field which is used to SELECT the new fee basis. Both are ASS fields (err if you know what I mean).

    In the custom ASP for the page, I set the feebasis to read only and only display the select on edit:

    oppo_prodidnew_accessname = OpportunityDetailBlock.GetEntry('oppo_prodidnew');
    oppo_prodidnew_accessname.Hidden = true; //We unhide this later on if the CRM.Mode is edit or save (and validation failed)
    oppo_prodid_accessname = OpportunityDetailBlock.GetEntry('oppo_prodid');
    oppo_prodid_accessname.ReadOnly = true; 

    The we have a TLS on update that moves the values around on update, and clears the select field ready for the next edit:

    function UpdateRecord()

    {

    //Copy the Fee Basis
    Values("oppo_introfeebasis") = Values("oppo_introfeebasisNew");
    Values("oppo_introfeebasisNew") = "";

    }

    This actually solves the problem moderately gracefully, regardless, you would have thought that when they developed the ASS to take this scenario into consideration. One for the development list Jeff??

  • There is a reason why we refer to SSA (Search Select Advanced) fields rather than errrr, you know what I mean.

    There is a whole set of changes planned to the interface and the way these types of field work is part of the mix.


  • Delightful, I will keep an eye out for news. Thanks Jeff

  • I'm a little late to the party on this one but could you add the Search SQL Clause in the CreateScript rather than on the field itself, so that you can control when it fires?

    For example, if you wanted to restrict it to only active records while the Opportunity is In Progress you could add this to the Introducer fee basis CreateScript:

    if (oppo_status == "In Progress"){
      searchsql = "feba_archived IS NULL";
    }

    Then when the Opportunity is Won or Lost, it retains its value.

    Also, the plural of basis is bases ;o)

    Darren.

  • What ho Darren, thanks for the response. Its a good idea, however it does leave us vulnerable to the fringe case of an opportunity being "In Progress" AFTER a product has been withdrawn (this does sometimes happen). User will go in and edit something else on the oppo, unknowing to them, the archived product will vanished on save.

    And, thanks, that solves the great basisisis debate once and for all!

  • I did actually think about that scenario but I didn't have a completely clean solution to it. I was thinking that if you based the check on whether the field itself was already populated, it would work. The first time you populate it, it would give you only the Active records to choose from. Once it had a value in, it would retain it. The only annoyance would be if you wanted to change the value as it would give you the full list again.

    Darren.

  • I know this is a very old thread, but this is a great suggestion.  

    Jeff, any chance this might still be do-able?  

  • It should still be doable.  SSA fields are very flexible and powerful.