Could be several things... most obvious, are you positive that you have transactions using the Swiss tax codes?

See this thread

If you check on the custom form, you should see a History tab which offers basic logging of who touched it last. As to the subject of Netsuite updates - Netsuite patches the system every Thursday night, and twice a year goes through a version change. These events CAN cause temporary malfunctions.

I checked that very recently and found it was not supported. I don't know if there is an Enhancement Request for it.

It's telling you your method signature is wrong. getOrderSummary(string,string) is not valid, the method does not take multiple params. It only takes one. You would need to do .getOrderSummary(['total', 'subtotal']) (i.e. use brackets to create an array).

Enhancement Requests work by votes - the more votes on them, the more likely NS is to package one of these in the new release (NS has 2 releases per year). However, votes aren't everything. The degree of complexity affect the likelyhood, and of course NS may have their own ideas about new features they want to release that…

You can rename and renumber the account Netsuite uses, if that helps.

Do you have client-side scripts deployed on items? While these types of problems are sometimes legit NS bugs you need to call Support about, the first most likely culprit are broken scripts on your side.

Is that in your production account? For sandboxes and things like that, that is the normal behaviour. If you're getting that message for all fields in Prod, though, I'd file a case. I just checked and I have no problem on my prod account, so it doesn't seem to be system wide or anything.

Can you limp along using Interco Journals or not even?

Your problem is the dangling 1 billioneth of a penny on discAmt. If you use nlapiFormatCurrency() on that, that will solve your exponential number. However, at that point, you may want to revise the equation because the result will be 0. The "0.5813953488372093 * 1720.00" equation is redundant since that comes out to being…

I'd run that through the Debugger and track the values. That value doesn't make sense, it's getting corrupted somewhere, or the math formulas are wrong.

Where and how does AVA_LineAmount[] get set? Is this being read from a Netsuite field? If can you find that field and see what it says in Netsuite?

Yeah that doesn't have anything to do with the bundle. There is a Netsuite issue preventing any form customization right now. File a case with Support and ask to be attached to defect 214492.

The billing tab of orders now has a "payment events" sub tab which has the cvv info we used to have right in front of us on the billing tab. --> Mmmm... that change took place like last version (so like 8 months ago). Our accounting tab has altogether disappeared on some sales order forms. --> Don't know about this one…

Try running an Inventory Activity Detail report (under Reports->Inventory), filter on that item on that location, and wee if this gives more insight.

Hi Paddy, This is a bit of a loaded question. What you should do depends a lot on your business workflow. I think the best I can do is make sure you fully understand how Netsuite behaves (I think you already do, but just want to go over it to be sure) Any Invoice, Cash Sale, Vendor Bill, Credit Memo or Cash Refund created…

You filed a Case as well, right? It usually make the NS people life easier when you post the case number as well. Please update here when you get news, I'm interested to see if this is a general problem or what. Cheers

Have you recently inactivated any employees?

Netsuite does not have any upper limit logic. You'll need to turn to a custom solution. You could go with Avatax but a small, custom script taylored to this specific problem will be much less expensive.

Scripting is able to read preferences, but taking a screenshot is actually going to be by far the quickest thing to do. I would, however, suggest you talk to your NS account manager in regards to getting a Sandbox. "taking a screenshot of all setting in case we f--k things up" sounds like a scenario where everyone's blood…

Yeah, on your fake submit button add as an instruction "window.ischanged = false". Be careful with this one though, it's pretty powerful, you bypass a lot of validation, including validation of mandatory fields and stuff.

Hmm, nothing pops out. It's almost certainly the use of the extra arguments on your window.open(), but why exactly I'm not sure. Try taking out the extra arguments after the URL, see if that does it. It would at least confirm where to look exactly.

I recently received notice this was fixed, though I did not test to make sure.

Can you post the button code?

Definitely an issue for NS Support to investigate. Hang in there!

Do you use Units of Measures?

Did you talk to Celigo about this?

Coincidentally I've been playing around with making custom calls to Merchant e-Solutions for a client. What I think I can say is that while Merchant e-Solutions (and likely the others ones) certainly do support communication via tokens, base Netsuite does not. So, if you want to communicate with your gateway using only…

Contact NS Support. Each NS instance varies in performance and you cannot rely on other people's benchmarks. If your performance is not good enough for YOU, talk to Netsuite.