How should I handle when a custom module wants to ...
# suitescript
t
How should I handle when a custom module wants to reference internal IDs of items? 2 other suitescripts reference this module and have deployments, but I don't want to setup parameters on both those deployments because it's redundant. Is there a way to do this in my custom module since it doesn't have a deployment?
a
you just pass them as parameters when you call one of the custom modules functions
unless I've completely misunderstood you... something like this...
Copy code
//in your main script
var itemId = 123;
customModule.doTheThingWithItems(itemId);

//in your custom module
function doTheThingWithItems(item){
    //doing stuff in here using item param
}
t
I wanted to avoid passing them as parameters, since that'd require making them parameters on both scripts that use this custom logic
a
they're not SCRIPT parameters
they're just code params in your code
when you call
record.create({ type: record.Type.INVOICE});
{type: record.Type.INVOICE}
is a parameter
t
Ah let me describe this differently. I was looking to see if there was a way or workaround (similar to script parameters) so I could set these item values in my custom module. I might need to deploy this to another project in the future, so relying on editing the file later on isn't ideal. It'd be nice if I could set up a way to edit this in netsuite, but don't want to setup parameters for every script because the items used are the same
a
ooooohh... these are hard coded.. but dependent on deployment things to reference?
t
Hopefully that makes sense. Yes right now I have them hard coded in the custom module. I don't want to hardcode because item ID's might change between accounts
a
yeah... umm okay you can setup a custom record with fields for them to be configured
and then you just need a helper function in your module to get the appropriate value based on the runtime script
is this a suiteapp?
t
Hmm I see, that does seem like a decent solution. Nah this is just a small solution that might be deployed from sandbox to production
hence the different accounts
a
we have this in all our suiteapps, its essentially a preference page with configurable things relevent to the specific app things like discount item - ap account, ar account etc.
then every single suiteapp has a custom module with a function called
getPrefs()
it might be overkill for your usecase tho
t
It might be but I don't really see a different way which would let it be configured inside netsuite
a
yeah that's the only way to go to let non devs update it... I was thinking if it was just a few different values based on environment you could have it hardcoded but use a runtime module conditional to use one set of hardcoded vs. another.
don't sandboxes get refreshed from prod? and then they'll match prod anyway ultimately?
t
Honestly I might just set it up with a separate file where it's clear that this is just supposed to contain the items. It really only is like 8 different values to select
a
you could also add a check box or something to the items and have it setup that way and use a saved serach to get the items which are checked
t
Hmm I'm not sure but currently it doesn't match between accounts. I'll consider the custom record route for now and see how it feels. This isn't some large problem so it might end up being fine if I just setup a different file containing the values
Thanks, gave me a lot of insight here
👍 1