[amccausland]

I’m writing a SuiteScript 2.0 Scheduled Script to copy data from some (but not all) Items in a Sales Order over to a new Custom record type.

The trouble is with the “rate” column on Sales Order : Item sublist.

If I use:

var lineCount = salesOrder.getLineCount({ sublistId: ‘item’ });

for (var i = 0; i This is a cached copy. Click here to see the original post.

[saenzmariano]

Hi Aaron, this is the wrong forum topic for that question.

[Olivier Gagnon NC]

So, sidestepping most of this and just answering the easy point: there is a search column for rate. It’s programmatic ID is ‘rate’. It is called ‘Item Rate’ if you are using the UI.

[Olivier Gagnon NC]

Ohh, sorry, I see what you mean now.

Yeah, looks like NS is dropping the info that this is a percentage.

I would look at a solution where you divide the discount amount by the amount of the line above to determine the effective percentage. Looks like there is a flaw there where NS fails to capture the percentage anywhere else.

[fjannelle]

Good morning,

I faced the same issue with using getValue to obtain ‘discountrate’ in 2.0.

It is broken. Your observations are accurate (getValue, getText). There is no other hidden field allowing us to know if it is % or $. No formatter. Nothing. As you mentioned, using a sourced field produces the same result. One note, using a 2.0 client-side script produces the same undesired result. Only the 1.0 functions return the % or $.

Here is what I did to work around it:

1. Create custom transaction body field of type Freeform Text, display type = hidden (main tab)

2. Create 1.0 user event before submit script (triggered on create, edit, copy). Script simply copies ‘discountrate’ value in hidden freeform text field

3. 2.0 script now references the custom field instead of the ‘discountrate’

Two keys:

1. Script at step 2 needs to be 1.0

2. Script at step 2 MUST be triggered BEFORE regular script (you can change the order via Scripted Records). This is if your script is a user event script on the same record. In your case since it is a scheduled script you will be fine.

Two problems:

1. Unnecessary processing. getValue should work in 2.0. No viable workaround. This adds 1 ‘unnecessary’ script.

2. Does not apply to past transactions, only moving forward

An alternative would be to rebuild your scheduled script as 1.0 (which is far from ideal).

I am planning to file a defect. If you already did let me know the # and I will attach my findings.

Thank you.

Best regards,

[amccausland]

fjannelle,

I am unable to find a Defect about this. I thought there would be one but it seems it was treated only as a Case.

I am in favor of filing a Defect, so please do so. It appears you have at least as deep an awareness of the details of the problem as I do, if not more.

[Olivier Gagnon NC]

We have this as Defect 367714

[Author]

Posts