Olivier Gagnon NC Red Ribbon

Yes it can

Well the report is custom so it's probably something you did. In any case, contact NS Support.

Log into the NS user interface and try to fulfill it manually. My guess is the item(s) on the SO are not fulfillable for any number of reason.

Client scripts have no choice but to execute under the permissions of the user that triggered it, so in this case you will need to make sure each and every Role that has access to the functionality has all proper permissions.

Sounds like you want to use the window.opener reference in the Suitelet to write back to the customer. That isn't quite the whole picture though... you'll need to figure out how the customer can figure out it has just been modified to act on it. If your customer is in View mode, that's a bit of a problem. The architecture…

The problem we are facing that when we try to create Sales order with shipping details. When we select ground shipping method and hit calculate shipping button it should not send XML request to get the rates from UPS and it should set the shipping cost as "0". When we select the shipping method as three day select it…

Depends if the script is running with its own permission or using the logged in user's. In either case, whatever Role the script is configured to use must have access to all the records you're hitting. So, probably View on all transactions and Edit to the custom record, perhaps more depending on the details of your script.

I think you should be able to use window.opener to write back to the customer record. That being said, if you're just using the Suitelet as a data middleman and there is no UI component needed, then you can switch to a non-UI Suitelet and just request it, and the response will be the value you need. Then everything is…

Under what Role is your suitelet executing? It may not have permissions to fetch the search results.

Sorry, I hadn't noticed before: when you are adding the line (nlapiSetCurrentLineItemValue) you are using the wrong API. You reverted to local-record coding, as opposed to object coding. You need to switch to TOrecord.setLineItemValue() kind of APIs

So you can do this the easy way, or the hard way. In the easy way, your button would create a new TO, add all the line items, SUBMIT IT, then redirect the user, in edit more (if desired), on that newly created record. In the hard way, your button redirects the user to a blank TO, perhaps passing in the URL a custom param.…

Yeah, just custom build the logic. You won't really be able to do Excel (except as an XML), but CSV is a plain text file. So just output a file at the click of a button.

In general, though, DOM manipulations are not coding Best Practices and are at high risk of failing sooner or later. Your button code should be switched to respect best practices.

Can you narrow down the problem a bit more than "it's not working properly"?

You have "var TOResult = nlapiSubmitRecord(record, false, true); " twice in there - the second one is probably erroring out, since you're submitting an - at this point - invalid record object.

Yes, this has happened to me a few times. Filing a defect sometimes works, but sometimes you just need to change your filters and that fixes it. It's weird.

I think it's ok. What I would probably recommend more though, since you're gonna recode this sucker anyway, is to go with a Map/Reduce script. You'll get much better performance, as you can make use of your multiple threads.

Have your RESTlet return immediately whatever value you want, then have the RESTlet offload remaining execution to a scheduled script.

Well it might be "normal" in the sense that the script sounds badly designed, so there would be a lot of waste there. But in general, NetSuite will be significantly slower than the environments you are used to. This is due to a number of reasons, but principally because you are never accessing the databse directly: you…

What Phil said. Also, a Map/Reduce script excels in this type of "process-each-results-of-a-saved-search" and takes care of governance for you, so you never have to worry about that. So, might be worth considering rewriting your script as a Map/Reduce as well.

From memory, I think only AfterSubmit is triggered?

This is not possible. The only thing you can do is use scripting to either add or not a BUTTON. But you can't add to the Create New menu.

There is a sort of hierarchy in statuses. If your PO was billed, then if you close the lines because they won't be received, it will still say Fully Billed. However, if you close the PO and it was never billed, it'll say Closed.

You cannot read the results from the tab itself. Use scripting to separately call the same search that resides in the tab.

Super edge case: if you're using LoadRecord in a script type that triggers other scripts (ex: scheduled script), and the record loaded as a script deployed on the BeforeLoad trigger point, you could cause something to happen. Otherwise, yeah. Like David said, it's a costly thing to do, performance-wise.

I have created this as a saved search before. The most logical way is to pull all transactions from the beginning of time and sum them up to your as-of date. The far trickier, but less data-intensive way is to "subtract down". Taking the On Hand quantity specified on Item records, SUBTRACT transactions from end of time…

At a glance, I would say try switching to: var customerid = result.getValue('internalid',null, 'group'); The 'id' field is not the same as Internal ID and your submit will fail because of that.

Not possible - that screen is not customizeable. The only option would be to scratch build you own replacement upload screen (via a suitelet) and on every single screen where a user can upload, add a button to call your own screen. Which is not feasible as there are many places you won't be able to get a button on.

Thanks, appreciate it. I share your frustration in regards to getting cases filed to get things fixed when it comes to scripting. At least we can share and make each other aware.

That's your problem. Stored fields will not default properly when the order is not created via the UI. Go fetch it from its original source or change the field to store value false, which SHOULD work better.