Perhaps at a minimum, on the custom definition allow a checkbox to 'hide attach', 'hide remove' when a parent/child list is defined. It may be an all or nothing setting but at least it is something. Users can still 'remove' by editing the record directly and editing can be controlled by permissions. This is very much like…

issue 126722 has been entered to track this problem. Thanks for bringing it to our attention and please use the workaround (disable the field instead) as a workaround. Thanks, Yang Thanks Yang.

Can you enter a case/issue with support so that we can investigate? Thanks, Yang Yang, Not to vent, but opening cases is like a black hole. do you need me to do this to pass on the case number to you for tracking purposes, then I will definitely do it? Otherwise... Thanks. -Steve

Thanks Yang. I'll put the code back in so it works when the fix is released. -Steve

Hi Steve, This probably won't help you right now, but a new field called unitconversionrate should be available in the new release. Here's Evan's post about it: https://usergroup.netsuite.com/users/showpost.php?p=22336&postcount=18 Cecelia Good to know though. Thank you. -Steve

You would pass an array. i.e. to create a search filter that filters on the salesrep field for salesreps whose internalId is any of (5, 15, 44): var filter = new nlobjSearchFilter('salesrep',null,'anyof',[5,15,44]); Thanks, Yang Just what I was looking for. Your example passes an array literal. Can I assume that the…

For filters, you should always use the internal id. Here is the complete list of item type internal ids: Assembly Description Discount DwnLdItem EndGroup GiftCert Group InvtPart Kit Markup NonInvtPart OthCharge Payment Service ShipItem Subtotal TaxGroup TaxItem Thanks, Yang EXTREMELY enlightening. Where would I find this…

OK, actually trying to do a join filter on a sales order to get limit the 'type' to only assemblies, service, inventory, non-inventory, item group, and kits so as not to get back sales tax item, and other items that come back routinely. 1. Looks like the 'type' field uses the text value rather than the value value (e.g.…

Sounds like you need a joined filter such as: nlobjSearchFilter('type','item','anyof',['Service','InvtPart','NonInvtPart', ...]) Also the issue you're seeing with client SuiteScript sounds related to the one from yesterday that I said should be fixed in next week's patch release (6/12/07). The workaround is to search…

Good suggestion: Supporting nlapiLoadRecord('item', internalid_of_any_item) seems like a very useful enhancement to make. It would obviate the need to determine the type for each member item, etc... ... I am not sure why you are having problems looking up the type of a member item. The following snippet should return you…

You could try calling: nlapiLookupField('item', item_id, 'type') Thanks, Yang OK, this has turned out to be a real pain. Does not seem that 'item' is a valid record type for loading a record to lookup a field. It only looks like 'item' is a machine type which is not what I am using. Needs to be either 'assemblyitem',…

... the latter does not work in Client SuiteScript. This has been resolved (issue 125707) and will be released in the next week's patch release. Awesome... :) Re-write here we come... :( Thanks Yang for following through so quickly. -Steve

In the 2007.0 release, that call will return the internal if of the item type. You will be able to return the display text by passing true as the 4th argument to that function. oooo. Be careful... This will break existing code designed around handling the current full text. I for one have code doing an indexOf("kit"),…

Wow - that seems pretty involved considering all you're trying to do is lookup the item's type. Thanks for your feedback though. No, I need to know the items type to look up specific information in the item record. As this thread has ascertained, there is no clean solution for that so I ended up looping through types to…

You could try calling: nlapiLookupField('item', item_id, 'type') Thanks, Yang Yang, Excellent suggestion. I'm curious as to performance and limits which is better: a) LookupField, or b) Create a hidden items list and create some sourced fields off of that items list and then as I loop, set the itemid found into the items…

While I really appreciate that we are able to work with a 'library' script file, one is not really enough as you deploy more and more customizations. It would be really nice if we could define several (20?) different library files, it would lend itself to better code separation for different aspects of the system. For…

Yang,... Second, I created a hidden items list field that had other item fields sourced to it and tried to set this list field via my script loop (loop through the members, get the member item id, set this item id in the hidden item list field which will source in other associated item fields). I was hoping by setting this…

Good question. Your observation about the "type" field was actually a bug. In the 2007.0 release, that call will return the internal if of the item type. You will be able to return the display text by passing true as the 4th argument to that function. 1 - nlapiLookupField() is a much faster way of fetching field values…

As I continue to document my journey, I hope something good can come of this... nlapiLookupField: correct me if I'm wrong please. Seems that I can call this API and pass in an array of fields I want it to return. HOWEVER I can only pass in a true or false as the fourth parameter to return text versus value. So what if I am…

Found it. The item was loading the wrong record type. Which brings me to my next problem. As I loop through the member items, I want to load the member item to get specific information, however I do not know what the record type is for the member item (e.g. assemblyitem, noninventoryitem, etc). Is there a way to still load…

I have three "libraries" over 180K. However, I have used compression tools (open source) which remove all my comments, extra spaces, etc, which nearly cut the size in half (I use javadoc style commenting so I can produce documentation and this can take up a lot of space). It also speeds up the loading of the code which is…

I am doing an nlapiMergeEmail using a document field on a custom record that identifies the template I want to use from the file cabinet. Funny thing is if I go to the actual template file in the file cabinet it has an ID of 66. Yet the ID in the document field on the custom record pointing to it has an ID of 660. Why is…

Thanks for the answer, but should I need to create a permission for the role when the Use Permissions checkbox for the custom record is not checked? Or put it another way - what is the purpose of the Use Permissions checkbox? I have the exact same issue (just discovered). NetSuite, this is a bug! If I do not have the…

Try also setting the field "templatestored" to "T". Thanks, -e That worked. Thanks Evan.

Thank you for answer, your assumption is correct, the form isn't setted up to store with record. Now it works fine. Can you give a list of fields per record that have similar treatment? Or it happens only with fields associated with forms? Regards. I'm having the same problem and the 'Save Form with Record' is checked. I…

Administrators can deploy server scripts to execute using Administrator privileges. There is a "Execute As Admin" checkbox on server script deployments that configures this. Otherwise, by default, scripts execute using the privileges of the currently logged in user. The exception to this rule are scheduled scripts which…

Yes, the nlapiGetNewRecord in AfterSubmit is read only. You need to use nlapiLoadRecord using the id of the record to have write access.

On After Submit afterSubmit() - send email Load the Case Record Again - write date/time of sent email to case field. Submit Again You have to load the record and then update. I did load the record. I needed to so I could read values from the case (e.g. who to send it to). -Steve

I believe you can cause an error in beforeSubmit to prevent records from being inserted. Thanks, -e I thought about this but we do not want to display to the user (avoid users seeing "Unexpected Error. Go back."). Is there a way to "silently" error? Thanks. -Steve

You are not allowed to submit the current or previous record returned by nlapiGetNewRecord() and nlapiGetOldRecord(). Your best bet would be to set this field's value in a beforeSubmit trigger. Thanks, Yang Oh, how we learn so painfully... We want to send a survey email out at the close of a case. I thought doing this in…