Is there a way to access a custom sublist on a custom record via suitescript? I have a record that users will enter criteria into that will then populate a bom in the sublists section via a saved search. Is there a way to access this data? When I try to run currentRecord.getSublists(), it says that it is not a function.
Any help is appreciated. Thanks!
Just in case people still run into this issue, it's a matter of dynamic vs static records.
currentRecord in a User Event is both a static record and cannot be "saved" (i.e. if you want to make changes in an afterSubmit method).
You'll want to record.load in dynamic mode to get what you are looking for.
var linect = rec.getLineItemCount('recmachcustrecord');
Related
Using the REST suiteql query endpoint or the records endpoints, is there a way to query NetSuite to get a list of custom fields?
You can use SuiteQL to list customfields.
For example to list entity custom fields:
{
"q": "SELECT * FROM CustomField where fieldtype = 'ENTITY'"
}
Use Setup -> Records Catalog to see the records you can query. It includes custom records and custom lists. ex. If you have a custom list called customlist_year then the records browser will include it and you can do a query like: SELECT * FROM customlist_year with SuiteQL.
One caveat: SuiteQL is still in development so the fieldnames and results might change with a NetSuite release. Make sure things get tested with a Release Preview account so you are ready for any changes when they hit your production account.
Using RESTWEB Services you can fetch the schemas of the objects. Below is the screen shot which gives the sample rest web service request.
enter image description here
Any specific reason to use suiteqql? With a normal RESTlet you can load a dummy record and read all field names starting with "cust".
I am having a problem finding out an id of a sublist. I am using SuiteScript 1.0. For instance, I need to list the components of an assembly item record, how do I find out the list id and the "type and field name to use in the nlapiGetCurrentLineItemValue or nlapiGetCurrentLineItemValue methods. What I am looking for is how now and in the future when presented with a sublist, do I go about finding the ids of the objects needed. I have internal ids turned on but that does not help in the sublist view. What is the best way to get this information when I need it? thanks for any help you may give.
You can use nlapiGetAllLineItems() to get an array of all the sublists. You may need to load the record first and do record.getAllLineItems()
I have found the most useful method for figuring out internalids is to run nlapiLoadRecord(..) in your Browser Console and examine the resulting object. Another trick is the add &xml=T to the end of the URL of the record, which displays the record in XML format. NetSuite also documents most of the internalids in the Records Browser.
In this case you use console in Google Chrome. Open the Specific Assembly Item Record page and Press F12 and select console.After give following code
nlapiLoadRecord('assemblyitem', 90088(id for specific record));
after show result in console. Select linefields and Item. Now it show the fields of sublist. If You have any doubt let me know.
I have scripts that react off of, for example, a client Recalc client event. For example, on my form I have a subtab that users may add or remove items from. Based on actions on this subtab (housing a child record of the parent) I would like a field on the parent to update (say to show a total from the children records).
As I was saying, these events seem to work fine if in edit mode but they do not work correctly in view mode. (even in view mode these child records have a "Delete" option at the end of each row in the subtab. This was provided by netsuite by default.
I wondered if anyone had any tips to best allow this parent field to update real time while in updating the subtab rows with the form in view mode.
Thanks.
You can make a custom field on the parent (header) whose value is determined by saved search. For instance, make a saved search that totals the line values by transaction. Be sure to make it filter by transaction in the Available Filters tab. Make the search public so everyone can use it.
Create the custom field that sources the total from the saved search. Make sure to uncheck the "Store Value" checkbox, as you don't want to store the data, you want to reference the search results. You do this on the Validation and Defaulting tab. You'll see a field for Saved Search there. Choose the search you created above.
As you remove/add/change lines on the transaction, the field updates accordingly. In essence, you don't need a single line of code to make this work - it's all in how you create the search and the custom field that references it.
I have a similar situation posted here.
The NetSuite team answered me by email, and it happens you can't really achieve this on the view mode: some API methods are not available. Their suggestion to my case (and I think it applies to yours too) was really to force a refresh on the whole page.
Of course, you can always achieve this accessing the DOM elements directly, but this isn't a best practice, as your code can stop working if these elements change on a version update.
I had the same problem, I'm not able to restrict on view or remove edit button. But, there was one alternative solution with workflows, you can deploy workflow on child record edit mode restrictions, then if the user clicks edit on view then the record will not be available to edit. This concern will apply to custom record as well.
I am creating a custom workflow which will trigger when status of a Quote will be changed and it will create an Order taking all the values from that Quote record.
Now Creating an Order is the easy part, but get the values from the Quote record is not, for me.
Could you please suggest me a way.
Thanks.
Why are you doing this rather than simply clicking the "Create Order" button on the Quote form? That'll suck all the information in the relationship mapping through for you. And the products.
Not sure if you can do it without a customer workflow activity. You'll need to create a customer workflow activity. You can grab the id from the PrimaryEntityId. Once you have the Id, you can lookup all of the attributes using the C# SDK and use that information to populate and create your Order.
Is there a standard way to associate custom properties with a user? I need to store the number of items per page a user selected in a grid of a document library separately for each user and document library.
Edit:
Sorry about this vagueness, I wanted to do it programmatically. It seems like I've found the solution, it is UserProfileManager class, though I'm now looking into whether there is a limitation on the number of properties you can save this way for a user, because the easiest way of saving page sizes on per user+document library basis seems to be using GUIDs of Views as property names and numbers of pages as values. Though I don't know if it is more efficient or not, depends on how sharepoint stores these properties.
No, you would need to create custom code to store the data.
Given the potential amount of data created, it may be wise to store it in a separate database.
This would give greater flexibility in the way the data can be manipulated and retrieved.
Your question is a bit vague. Are you looking to do any custom code? You could do this many ways so it is difficult without knowing more of what you want.
Using custom code you could set up a workflow or event handler to respond to item events and record the information and store it using the User's Profile or as an SPPersistedObject.
If you want a less developer centric way to do it you can use auditing and simply do reporting on your audit results.
You could set up a list to store the selection data, then use events/AJAX on the document list to push tick/untick items into the selection list (store user, library and document as a minimum.
If you don't want a separate list, you could create a field in your document library that stores which users have a given document tagged... You'll still need some kind of event/AJAX to update the list when a user ticks/unticks the box. Crude :)