[sney]

I’m trying to source the description and cost of the shipping item/method that’s selected on an Estimate – and while trying to figure this out I’ve become a bit confused regarding sourcing shipping info in general.

For starters, the description. I can easily get the Name of the shipping method using ${record.shipmethod}, but that doesn’t appear to be a valid way to source fields from the Shipping Item record, as ${record.shipmethod.description} returns an error. I have also tried ${record.shipitem.description}, but that returns an error when saving. Looking at the built-in Advanced Templates, they only include ${record.shipmethod}, not the description of the shipping method, so I can’t cheat and copy something there

Second, the cost. I actually got my template to display the cost correctly using ${record.shippingcost}, but later I noticed in the built-in Estimate template that they used ${record.altshippingcost}. Both work, but I have no idea what the difference is – if any?

All help appreciated!

Cheers
This is a cached copy. Click here to see the original post.

[sney]

Oh and I know about having the Shipping Item display at the end of the other line items on a transaction, I am attempting to break the shipping info out to make it more prominent on the printed form. If it’s not possible I have figured out how to identify the shipping item in the list ( ), so I guess I could leave it as a ‘line item’ and highlight it in bold or colour or something.

[michoel]

If you can access the shipping item in the item list you can place it wherever you want in the form by having two lists, and in the first only display if it is a shipping item, and the second only display if not. Something like this (pseudo code):

${item}

..

${item}

[sney]

Huh good point. That seems like the long way around to get it though, I was hoping it could be referenced directly.

FYI you can identify the shipping item like this (inside the #list declaration):

Not sure if it’s better to have == instead of one = ? In all cases where I’m evaluating a string I’ve used one and it works fine.

The valid itemtypes I’ve seen so far are InvtPart, Description and ShipItem. I assume there are others for non-inventory, other charge, etc as well. This has let me apply different formatting to the lines based on their type, it has come in very handy.

I found out what the valid types were by adding a few different item types to a test transaction and printing it using the new form, with this code (again inside the #list declaration):

${item.itemtype}

I’ll give your suggestion a test, it will work I just hope it doesn’t slow down producing PDFs by any noticeable amount, as all the line items are being processed twice.

Cheers again

[michoel]

Not sure if it’s better to have == instead of one = ? In all cases where I’m evaluating a string I’ve used one and it works fine.

Strictly speaking, the ‘=’ operator is for assignment and ‘==’ is for comparison. In Freemarker you need to use the directive for assignment, so probably if ‘=’ works to compare I doubt it could cause any problems. In some programming languages using ‘=’ instead of ‘==’ can really mess things up.

I found out what the valid types were by adding a few different item types to a test transaction and printing it using the new form, with this code (again inside the #list declaration):

The full list of valid item types is documented here:

https://system.netsuite.com/app/help…_N3188567.html

I’ll give your suggestion a test, it will work I just hope it doesn’t slow down producing PDFs by any noticeable amount, as all the line items are being processed twice.

My guess would be that any increase would be insignificant, but let me know how it goes.

[sney]

michoel, you are a font of knowledge! I was thinking about PM-ing you a couple of questions but I suppose discussing them out int he open leaves a trail for others to follow, hopefully someone else will benefit as well.

It worked perfectly, and the form doesn’t seem to take noticeably longer to render.

[Author]

Posts