Josh, You are correct and this is a common source of problems. Deletions should be rare, as permission to delete ANYTHING in NS should be not be handed out to anyone except super users. However, deletions aren't the only problem, as users could modify the lot number after the fact, which would break NS as subsequent…

Yeah those stats seem way too long, but hard to say what could be affecting it. Have you tried opening a performance case?

Yeah, just simplify the whole thing by dropping the load. Even if you get this to work, it's very expensive (relatively speaking) in terms of performance load and metering, plus you may hit some permission problems (as not all users that have access to SOs will have access to Items) Simply create a custom column field that…

These do occur and I recommend you do what the error say and contact the merchant account.

Unless you have something like FloDocs to compare environements in great and automated detail, you'll have to use your Mark 1 Eyeball to try to spot any changes. If you can't find any, then it's your judgement call if you should bundle over or not. If you don't feel secure, then manually port the changes so you have better…

Hmm, what is the name of the script? Can you also figure out what bundle its from?

Suitelets trigger scripting on records. So, yeah, it might not be the suitelet itself but other scripts deployed on the Task. You'll need to get someone technically knowledgeable to debug this. I would start with the person that coded the suitelet

My first guess would be that your UE is not deployed so as to trigger for external uses. The All Roles box should be ticked and no other checkbox (Employees, etc) on that page should be ticked.

Netsuite has indicated they are aware of the issue

Do you use Bins? Bins have been the villain in just about all inventory problems I have ever encountered.

Did the SO have Terms or a Payment Method set?

That's right, I do remember someone saying they got unstuck following that SuiteAnswer. It's worth a shot. I'm not clear on why it works sometimes and no others, but you have nothing to lose to try. If it doesn't work... well, there is always what I suggest.

I can confirm it is *impossible* to revert numbering. Once a higher number is entered, it is PERMANENT. You can either live with your new numbering scheme, or implement a customization to replace NS's auto-numbering. This involves turning off NS's auto-numbering for the affacted transaction an using scripting to set the…

I had a similar error occur this morning. I think NS has an issue. Only had 1 such error log come in, might have been a temporary glitch.

I recommend filing a Case with NS Support

This is a new class of Sandboxes NS is offering to meet the needs of those that need a Sandbox with production-like performance. This is required if your building processes where performance and handling large-volume is going to be a big deal. They are very expensive, so no, not everyone gets one. You need to contact your…

File a defect with NS. This is a Defect that will require Support

Last night was Thursday night, which is the hot patch time. So, my guess would be a bad hot patch. I would file a case.

You had criteria on custom fields that had field-level permissions on them? Never tried that, I could see that returning an error, yeah.

The only time the search would throw an error is if the entire base record the search is based on is not accessible. For example, if someone tries to run an Employee search and their role does not have access to Employees, you get an error. However, if you build a search based on a super class, such as "Transaction", then…

Ok, yeah. That "as designed". You won't get anywhere with NS support, this is normal. Reports shouldn't have this behaviour, but as you say, they are more restrictive in what they can output.

Are you seeing this problem with *Report* or with *Saved Searches*?

Where are you sending this? Why are you trying to do this instead of just completing your operation with an nlapiSubmitRecord() operation? If for some odd reason you HAVE to submit this via a requestURL, then you'll need to build a RESTlet listener to accept the incoming JSON and perform the submit for you.

Sandboxes are purchased for a set time period, usually 3 months, 6 months or 1 year. Actual activity doesn't matter, but your contracted period term does.

I tested these a few days ago and did not have the above issue. I recommend you start by doing all the browser gymnastics (clear cache, close browser, try again) and then filing a Case with NS Support if that does not work

Could it be a concurrency problem? Not sure what error message pops when you hit concurrency limits, maybe it's the same as timeout?

nlapiGetNewRecord() will effectively only show submitted field only under an xedit operation. Otherwise, it returns the complete object. The point might be moot, based on what you are saying in the second part of your question. What exactly do you entail by "I don't want to submit unnecessary fields."? If you use…

Oh. Well you can do getOldRecord and getNewRecord and then .getAllFields() and cycle through them one by one, comparing the two values.

Yikes. Did you file a defect? To correct it, though, Inventory Adjustment Worksheets are going to be your best bet, as they allow you to reset negative quantities to 0.

To give access to customized versions of Reports, go on the customized report itself and press customize, and then go on the very last tab. You will see a section for granting access to Role or user, etc.