Olivier Gagnon NC Red Ribbon

Go with nlapiSetFieldValue() at the end. nlapiSetFieldText() if just for setting Select type field using the textual value instead of the id. It does not work for anything else.

What does script in form.addButton('custpage_gotoSuitelet', 'Go to FA Worksheet', script); refer to? The code for that funciton is not in your snippet. It SHOULD point to something like function script(){ var url = nlapiResolveURL(suiteletScriptID, suiteletDeployId); window.open(url) }

use the confirm() javascript function

That page is not scriptable However, you could place a script on the actual Vendor Bills themselves, and at that point detect what Class it is and set the Account accordingly. This may contradict what the user selected on the mass selection screen, but you have few other options.

Hmm, my memory is a little fuzy on this last step. I think you use nlapiRedirectURL() to point to the suitelet's URL?

Wait wait wait... just caught something. request.getMethod is not a function," and, as far as I can tell, that is true, and the value of "request" is the string "create." That's not right. How did you deploy this code? Doesn't sound like you created a Suitelet. Di you go to Setup->Customization->Script->New, and chose…

Uhh, no... You can't call a script that resides on another record type. That just.. won't work. UE scripts do not trigger UE scripts. If you want that to happen, your UE script can call a Suitelet/RESTlet to submit the record for you. THAT will trigger local scripts. But, it'll trigger all of them. So either you're cool…

Can you include some sort of extra param that indicates what you're supposed to do? Your suitelet could check the existance/value of that param to decide what it's supposed to be doing.

I don't usually bother with setValues, it's very sensitive and the time you spend debugging it could be half the time it takes to write a for() loop and just cycle through the results and set value to each column individually. I'd just go with that

That's interesting... My account doesn't have a run as admin box (and obviously, I'm logged as Admin)

I think you also wanted to check the form in use - so you can do that there are well, but unless that's recently changed, beforeLoad kinda ****s at doing nlapiGetFieldValue('customform'). You'll probably need to load the record and check the form that way.

As far as I know this is as designed, though haven't had further confirmation from NS regarding this.

Uhhh, hold on there.. Why do you have a response.write() within a for statement? And what is it returning? Looks like a simple pipe-encoded serialization. Vestige of a previous approach? It really shouldn't be there. And like ivan states, you shouldn't return the string, you should response.write it.

I haven't tried that either, but my impression is that the RESTlet runs with the permissions given. Customer Center access has very few permissions.

You sure you're going to be ok with the concurrency limit?

beforeLoad(type){ if(type=='print'){ ...

Are you sure there is a Class field showing on Quote lines?

You can set a SUITELET to run as admin, not RESTlets.

Yup, all the time. You have to manually serialize and unserialize it yourself, though... so when you say the suitelet doesn't recognize the object, that doesn't seem right because you're giving it a string.. right?

You can place a beforeLoad function that captures the 'print' action and nlapiRequestURL() of a suitelet that uses xml to pdf to render your page.

Yes, per user. What you could do is buy 5-6 user licenses (so getting up to like 300 concurrent users, let's say). On the app-side of thing you'd need to implement load-balancing logic to pick the correct user. Cause buying 1 license per mobile user would, you know, blow quite a hole in your ROI. I'm not saying it can't be…

Elham, My assumption at this point (which may be wrong) was that we're looking at a mass-market app that woulkd have thousands of users. Since it's some sort of mass-transit/transportation app, my assumption is also we're looking at peak hour usage, not an equally distributed user base over time. So, potentially…

It's like 50 isn't it? "High" is relative. If you got thousands of users, or if the processing the app has to make is lengthy, the odds of 50 simulateneous requests start getting e bit more likely. It's really dependant on those factors.

If you want to keep the custom record definition but drop all records, then no, there is no alternative. Don't worry about the metering though, schedule scripts can just reschedule themselves when they run oit of units. The concept of metering if fairly meaningless for scheduled script.

Well you're just talking about shifting a GL hit from one COGS account to another. What I'm saying is you'd let the fulfillment hit the same COGS account from your item, then afterwards you'd create a Journal to shift from that COGS to whatever other COGS you want. It's kind of the same thing as your Inv Adjustment path,…

Wouldn't it be simpler to just set a global var for gsExecType in the pageInit() function? That's what we usually do. Another easy trick to is to pull nalpiGetRecordId(). Records in create mode don't have an ID yet, so if that api returns null you know you're in create.

1. Javscript is case-sensitive. So, don't put anything in caps unless it is supposed to be (it rarely is) 2. ''custbody_storefront_order'' is a body-level custom field. To get body-level fields, use nlapiGetFieldValue(). Cheers

Modifying the COGS on the transaction is not possible. Your other solutions are in line with what is possible. I'd probably just go with a Journal Entry, though.

#3 definitaly throws a wrench in things. At this point, I can't answer off the top of my head. This is pretty complex and would need to be tested out. My solutions trails include looking at using Alternate Sales Amount for the commissions. However, I'm also thinking that if you "buy" some items at 0$, you're also…

If you're really trying to get a sublist field, double-check the field name. It is impossible it start with 'custbody_'. It would be 'custcol_'.