Best Of

Hello Dext3r,

As per checking, we were able to verify that the Reference Serial/Lot No. field only accepts hyphens and alphanumeric characters. And  "/" character in the Warranty Registration Reference Serial/Lot No. field is a current limitation.

Also, I haven't found an existing Enhancement Request about this, so feel free to submit one. You can do so by either submitting a case to NetSuite Customer Support or via SuiteIdeas.

Refer to these SuiteAnswers Articles for the steps on SuiteIdeas:

 30288: Steps to Navigate to SuiteIdeas

 10054: Voting for Enhancements > To enter a new idea

We apologize for the inconvenience and appreciate your understanding of this limitation.

-Lyka

Thanks for all your replies, the answer i found elsewhere which is "I think you can't filter the netsuite fields directly but you can set customisable fields which then auto fill the standard fields, and the customisable fields can be filtered for whatever journal options you want."

Thanks again Paul

Cracked the solution: Below are steps to execute —>

• Add a checkbox to the journal entry called “has been edited”
• Add a set field value on entry into rejected state to set the “has been edited” checkbox to UNCHECKED
• In the add button action add a condition of “has been edited” = T
• Add a set field value action that sets has been edited to CHECKED after record submit when the event type is editChange your transition to only execute on button “re-submit”
• Add another set field value action on Exit that set “has been edited” to UNCHECKED.

Hi Patrik,
I think we figured it out.
I was concerned that we couldn't pay different currencies via EFT for the same subsidiary, same GL but that's actually not the case. As long as we add the different currency in the vendor record and setup one bank detail per EFT file then it works.

Manuel

Hi @User_80C0N

Try the below code and let me know:

<#list record.item as tranline>
<#assign itemIndex = 0>
<#list salesorder.item as soItem>
<#if soItem.type == 'Item'> <!-- for filtering out non-item lines -->
<#if soItem.item == tranline.item>
<#assign itemIndex = soItem_index>
</#if>
</#if>
</#list>

<tr>
<td colspan="12" style="border: 0.5px;"><span class="itemname">${tranline.item}</span><br />${tranline.description}</td>
<td colspan="3" style="border: 0.5px;">${tranline.serialnumbers}</td>
<td align="right" colspan="2" style="border: 0.5px;">${salesorder.item[itemIndex].quantityordered}</td>
<td align="right" colspan="2" style="border: 0.5px;">${salesorder.item[itemIndex].quantityremaining}</td>
<td align="right" colspan="2" style="border: 0.5px;">${tranline.quantity}</td>
</tr>
</#list>

Turns out the trouble he was having related to using upper case letters instead of lower case.

the url we call is case sensitive :

Good:

const url = 'https://1234567-sb1.restlets.api.netsuite.com/app/site/hosting/restlet.nl?script=customscriptcustomscript_rest_getdl_item&deploy=1&custscript_companyid=3639'

Bad:

const url = 'https://1234567-SB1.restlets.api.netsuite.com/app/site/hosting/restlet.nl?script=customscriptcustomscript_rest_getdl_item&deploy=1&custscript_companyid=3639'

the sb vs SB


There won't be a single number to answer this question. A few considerations will impact it:

• Will there be sourcing involved? This can add additional performance burdens with the lookups.
• Will there be scripts or workflows using or running on the custom record associated to the custom segment? These will also create a performance burden and will magnify the impact of many values.

Barring extra performance limitations involved in sourcing, scripts, etc., most record types can go into the thousands before you start to see any measurable performance impacts and into the tens or hundreds of thousands without that impact becoming really noticeable.

To echo @CDuf above, I would challenge the reporting strategy that leads to thousands - let alone tens or hundreds of thousands - of values for a custom segment. Even by the time you reach 1k active values (inactive records shouldn't cause any performance issues), there is probably a better way the data could be segmented to be able to produce meaningful performance.

Gia My "Mei" Luc

As others note, without explicit limitation in SuiteAnswers & the reference to the same behavior as Departments, I would agree the list in a custom segment could be as long as necessary. The UI performance would mimic any excessively large pick list selection and may be annoying.

Another consideration is mass general ledger related processes (revaluations, rollups, etc). Mass processes generally have to process through every unique combination which would add a bit of processing time.

While custom segments are a great NetSuite feature, I would first scrutinize the real need to add the attribute to the general ledger.

Does the attribute apply to all posting transactions across all modules?

Can you accomplish the additional attribute with a custom "field" used in searches, reporting, Analytics in lieu of a custom segment in the general ledger?

I would brainstorm the absolute need to put the attribute in the general ledger as a custom segment. If you still think it needs to be on every general ledger transaction, go ahead and create it but I've found I can accomplish my need through an ordinary custom field with a custom list and even dependent list selection limitations…

I hope this helps.
Best Regards,

I am working on getting the screen shots from the 2 employees with the issues.