Hello all, posting this here for group knowledge. We have a scriptable cart function that was setting the

shippingcost

field via nlapiSetFieldValue when the FIELD CHANGED callback fired. Doing so would also update the order total correctly, and everything was fine. When 2019.2 was released, setting the

shippingcost

field via the FIELD CHANGED callback would do nothing. The

shippingcost

value set was ignored, and of course the order total was wrong. The solution was to set the

shippingcost

field in the RECALC FUNCTION callback instead of the FIELD CHANGED callback. When this was done, the

shippingcost

was reflected properly and the order total was correct.

Hey @badgerdigital, are you using the integrated FedEx or USPS options when doing this?

@Chris No, we are using a custom calculation via

after:LiveOrder.get

and

after:LiveOrder.update

Interesting. I ask because I overrode the existing shipmethods list but I had to create new shipping items (Lists=>Acctg=>ShippingItems) to get the total to update correctly. I'd still like to be able to set the price for the original integrated shipping items. I'm sure I'm not the first person to mess with this.

Yes, that would be nice, wouldn't it.... we'd like to calculate air rates, but then on ground, have our custom calculation kick in. Frankly, the whole way that shipping is calculated in NS is 100% incompatible with how most eComm businesss do business. It's a mess...

Agreed!

If you have all the product in one warehouse and you are doing all the shipping, sure.... it's fine. But when you throw in multiple origin points and drop-shipping it all falls apart.

As far as I can tell, the integrated shipping stuff is locked down. I couldn't find a way in at all. And yes, if you need to give the customer options based on fulfillment location it gets messy quick.

@badgerdigital Thanks for posting this Michael! We have a very similar customisation implemented by one of our SCA partners that utilises a Client Script to set the

shippingcost

to the correct shipping rate (stored in a custom Transaction Body field), per the customer’s delivery method selection. Your solution makes total sense to me - unfortunately we haven’t had success with it yet 😞 Was there any modification you had to make to your Script’s callback function to ensure it worked? Or, did you simply move the function name entered in the Field Changed input to the Recalc Function input on the Script record?

@Ori Zacher We ended up basically taking the code that was in the FIELD CHANGED callback and copied it to the RECALC callback. Both sets of code continue to run. Our calculation is done in a client script which sets a temporary field on the Scriptable cart form that we are using. It's in the two functions above where we read that temporary field and set the shipping cost

Thanks for sharing! Minus the

IS_PROCESSING

flag, our script is pretty much the same. In our case, our script was originally authored with the

firefieldchanged

parameter set to

false

(the first of the two Boolean arguments in your use of

nlapiSetFieldValue()

). Our regular Solution Provider pointed this out and we were able to resolve it just with that. We didn’t need to utilise the RECALC FUNCTION callback in the end.

@Ori Zacher Our original cost was coded by NSPS and the fix was done by the Commerce Response Team (our whatever they are called...). I noticed that in the field changed function we have

firefieldchanged

to

false

as well. But of course in the code snippet above in the RECALC FUNCTION, we have it set to

true

-- I will be definitely testing this in our sandbox to see if we don't need the RECALC FUNCTION.