Olivier Gagnon NC Red Ribbon

Well you can go to your Suitebundler and install stuff that is freeware, or create bundled of functionality and provide them publicly on Suitebundler as well.

Correct, this is not standard

Are you perhaps developping on a Sandbox?

I think that field might indeed be a dumb sourcing of the value from the item record. It might not be possible to set it by script.

Sounds like something we're coding for a client right now. The approach we took is to have a base Assembly with just the common components everything shares. Then, using Item Options, user select the options desired for this sale. Then, when the Work Order is generated, a script reads the Item Options, looks up some Custom…

ERP Guru has very stringent ones, don't know about you :D Coding standards are up to each individual coder to set up and respect. If you are part of the SDN, I believe NS has guidelines for you to follow, though I wouldn't call them coding standards.

To allow order entry people to select all the right "options" on products being added to orders?

Could you use the Center Link section on the Suitelet deployment?

What do you intend by "configurator"? A product configurator for a web store?

No, nlapiSubmitField() causes an xedit type of entry into the script, which by design only carries information for the fields being submitted, You can change your logic to use nlapiLoadRecord()/nlapiSubmitRecord() if the xedit won,t work for your code.

var rec = nlapiTransformRecord('salesorder',[id],'revenuecommitment'); //play around with quantity from your line item here nlapiSubmitRecord(); Nothing complicated to it. To have multiple rev commits, just reduce the Quantity of the line items. NS will keep track of the full qty vs what's been committed, just like it…

function validateInspectionOfItem(){ var numberOfItems = nlapiGetLineItemCount('item'); for (var i=1; i <= numberOfItems; i++) { var inspectionneeded = nlapiGetLineItemValue('item', 'custcolcustcol_inspection_needed', i); var inspectionconfirmed = nlapiGetLineItemValue('item', 'custcolcustcol_inspection_confirmed', i); }…

Yes, we switched to Daylight Saving Time, which adds 1 hour to the clock. You can't prevent this. Your script will need to accomodate this fact. You can run a google search to understand how DST works.

What is this script running on? the alerts suggest a client-side script but the record loading suggests a user event one. Which is it? In both cases, you must be running this on a creation. Record ID is null until the record has been saved at least once. My guess is you want to convert this to a fully client-side script…

No, that is not possible. Allocation/commitment causes no event on the SO record itself. Someone had a very similar question just yesterday, so you can see my detailed answer here.

What about a Customer Deposit, applied to the Sales Order?

The functionality you are referring to is a 2013.1 enhancement, so you'll only start seeing it when your account is upgraded.

Are you getting that on the Transform itself or the submit?

yeah, nlapiMergeRecord()

You may need to have the Payment be created to hit a Liability account, but aside from that it should be ok. I'm not sure you want to verify if the payment amount matches the invoice amount though (step 4) - even if they don't match, you probably want to apply it - unless your intent is to have this fall into the "failed"…

yes, throw an error throw nlapiCreateError() it will interrupt the save

Hi All, The script is able to reference the invoice by invoice number and also by internal ID but when I use either value as the parent invoice I get the INVALID_KEY_OR_REF error when it tries to create the custom record. I'm assuming this is because accepting payment closes the invoice and it's no longer available to be…

What are you looking for?

You'll have to handle that scripting. You could have a template with special strings (let's say "$$$lines$$$"). You can script to execute a find & replace of this string with a routine that would fetch and output the line item info. It's certainly about 10x the work of just executing a merge but it's totally doable.

You want to look at the before last parameter of the API nlapiSendEmail(author, recipient, subject, body, cc, bcc, records, attachments) records {hashtable} [optional] - An associative array of internal records to associate/attach this email with. The following table lists valid keys -> values. Check the Help documentation…

You can wrap your nlapiLoadRecord in a try/catch, and let it gracefully fail if the load fails dues to the given internal ID not being a valid SO one. Or, you can add a hidden field on the transactions that sources the created from transactio type, and check this as part of your logic.

While this is perfectly correct, I wouldn't take this approach in this case. Looking up the record type will have a performance cost (as minimal as it may be), which you simply don't need. You would go with a lookup if you needed to know which type and then branch your logic off depending on that. But in our case, you need…

Yes, throw an error in beforeLoad if your conditions aren't met. This will prevent the record from being edited or viewed. Record locking can also be well achieved using Suiteflows. Note, however, that a person could still view the data from the record via a Saved Search. If your goal is 100% invisibility, you will need to…

Yeah, yeah, you could do that. By script, you read the url param, maybe it's the item to add, and by script you stick it in the sublist. Depends exactly on how much info you want to pass, like are we talking about 1 item or a whole bunch, and do you need to pass more info like qty, price, department, etc... the concern is…

Keep in mind pulling the exchange rate from currency X to Y, then pulling the exchange rate from currency X to Z, then calculating the difference between them is not equal to pulling the exchange rate of Y to Z. Currency exchange rates work on speculation, not mathematics, so there is a good probability you will have an…