I feel like I’m taking crazy pills. I’m sure I used to be able to get the

class

of an item in a transaction in create/edit mode client script using

nlapiGetLineItemValue('item', 'class', i);

or

nlapiGetCurrentLineItemValue('item', 'class');

I have found a few places where our business logic relies on this so I’d be surprised if it never was working. However, now, it returns a non-null value that is not correct on some transactions (in fact, on the affected txs it returns the same value for all lines even if they are different classes). Has anyone encountered this?

did you try to fetch the same with a saved search?

Just tested - it’s also wrong in the saved search. WTF.

I did a suiteQL query yesterday with a class criteria in it.... it worked for me (I suggested the SS cause I figured it will produce the same results)

it would make a BIT more sense if it was null or something, but being non-null and randomly wrong is super weird.

does anything else set the class?

the non-null is like an extranalId so it's ok to be non-null but randomly wrong, try to check the script deployment parameters for something wierd

the class resides on the item…I guess it gets copied to the item line somehow? I don’t really know how that works.

this sounds like you arent showing the line level class field on your form

Just an idea, but could it be related to the setting that prevents an item moving GL accounts when you edit the income account? I wonder if it does similar with DCL

we aren’t showing it, but only because we are using that trick of the label being blank (but “show” is still ticked)