[sfsonarboy]

Greetings,

I have a customer saved search that we call via SuiteTalk that is used by an external application. One of the fields returned is Price Level (““).

Is there a way to have the saved search xml return data give the text/display value of priceLevel instead of the internalId value?

Context is the application consuming this data would be more efficient if NetSuite could return the text description instead of an internalId (that it would have to map/convert).

I’m wondering if there is a way to modify my saved search, or if there’s a SOAP call configuration setting, or any other way to accomplish this. Preferably that doesn’t require SuiteScript but I’m open to all options.

Big thanks in advance for your assistance!

Steve Egelman
This is a cached copy. Click here to see the original post.

[taylor@abptech.com]

There should be more pieces of data that come through with that priceLevel field, it is a RecordRef object which should contain all of these 4 attributes:

internalId

externalId

name

type

If you dump out the entire SOAP response, I bet that the priceLevel -> name field value is there, you just need to access it instead of the internalId.

[sfsonarboy]

Thanks for the reply, but the SOAP response doesn’t seem to provide that – please see Example 1 below. (I think that solution would work in SuiteScript though).

I found one work-around but it’s problematic as it significantly increases the amount of data returned, and that is to add this value to the SOAP request header:

false

Practically, I’m not sure this is a viable solution, as searches that return say 100 records that used to only have 5 fields per record (based on my saved search) now return ~40 fields per record, and this much additional data will be problematic. Example 2 shows this.

Are there any other options? Perhaps something that could be configured on the Saved Search to specifically return text value for Price Level? Or another configuration that would just bring back the rest of the RecordRef values? Big thanks in advance for your continued help!!

Steve

EXAMPLE 1: Here’s a sample of what is being returned now – I’ve bolded the priceLevel area where I’d like to see a meaningful text value

1000.0

XXX XXXXXXXX

2019-03-22T17:00:00.000-07:00

EXAMPLE 2: The results of the same search as above, but with the returnSearchColumns set to “false”…gives the text value for priceLevel I need but waaaay too much data!

XX XXXX

XX XXX

CUSTOMER-Active

XXXXXXXXX

false

XXXXX

2013-10-02T14:39:16.000-07:00

_default

XXX

30 Net

_auto

292

0.0

0.0

1000

0.0

3830.0

0.0

292

Discount Price Level

US Dollar

false

false

0.0

2013-09-29T16:00:00.000-07:00

false

Customer Center

xxxxx

2015-04-07T13:49:28.000-07:00

_customer

false

false

false

false

…some redacted custom field data

[ktarog]

Hi Steve,

Currently, using calling a saved search via WS AdvancedSearch will only return a recordref or internal ids. This is a known limitation and an Enhancement is already filed (IS # 243330 WS > Saved Search results column that are of list/record only returns the internal id not the text value).

For alternatives:

– Use Get method

– Use Basic Search

– Invoke another search (to get the text value of price level)

– Set preference returnSearchColumns to ‘false’ (as you have stated above)

I understand that these would return so much fields. My recommendation is to create a free-form text custom field deployed to the Customer record that sources the price level. Then use this field on your search.

Steps:

1. Customization > List, Record & Fields > Entity Fields > New

2. Set the following:

– Label = (any)

– Type = Free-Form Text

– Applies To tab > Customer = checked

– Validation & Defaulting tab

> Default Value = {pricelevel}

> Formula = checked

3. Save

4. Call this field on your search columns.

5. Call the saved search via WS.

As per my test, this returned SOAP response:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`

Xavier Hudson

895-789-1234

Base Price

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`

Hope this helps.

[sfsonarboy]

Thank you for the excellent reply and additional information. Glad an enhancement request is already filed, and indeed the custom free-text field sounds like a great work around. Much appreciated!

Steve

[Author]

Posts