Well I figured this out. Steps below in case anyone else is interested in this. The solution ended up being a custom column field and some client scripting. The key bits of our script are below, it is triggered on Post Sourcing on the transaction: // Loads the item record into a variable based on the item on the current…

Very interested to know if there is a workaround or fix for this, a remittance slip is very useful but not if it cuts off a quarter of every pages usable space on multiple-page invoices...

So apparently this is NOT possible...there is an enhancement request to allow sourcing parent/child field data but who knows if this will also let you source a sublist as well :P So I'll probably have to add a custom button in view mode, and write a script that will find the child records, add the data from those records…

I ended up writing some scripts to run whenever a child record was updated or edited - it after saving the child record it now loads the parent record, searches for all attached child records, copies the data I need from them into a single text box field on the parent record, and saves it. Then when I merge the parent…

It is part of the Withholding Tax bundle (ID 47459) offered by NetSuite. It also includes LOTS of client and user event script files. Are you suggesting the way NetSuite has implemented withholding tax means it can only be used in the UI? I thought the general rule was as long as you imitate the UI in the right sequence,…

Tried your suggestion thanks (except I always have the line number 'i' as the last parameter as per the Reference Guide) - now it still ticks each line correctly, but does not source dependent fields on any line, even Line 1! Even if I have the code set the 'WH Tax Code' field as well, it still doesn't fill in the other…

I moved the script to a user event (before submit), and I created variables where possible. Thanks for those tips, it's a cleaner implementation :) It executes without error, however now while it now seems to be completing the loop on all lines, it does not source dependent fields on all lines...? Results on same lines as…

Not sure if you solved this, but I was having the same problem...figured out that the Price Level field is actually just referred to as 'price', so the following code worked for me (this is for the current line, but would also work for nlapiGetLineItemValue I would think): nlapiGetCurrentLineItemText('item', 'price') //…

Thanks would definitely be useful. For now I'll just have to name them carefully.

What I wanted was to export the Item-list to an excel. The way I did it was to create a custom header field in the form of an inline html which displays the excel-icon and links to the export of a saved search. Thanks I didn't think of this. it's closer again to what we want but not quite there! This would give us the line…

Thanks guys that's another way of doing it but not what we're after - we really want a native Excel export function...click a button and you get a file. Might have to look at whether you can construct an Excel file in JavaScript...

Great thanks - we decided against setting it up in the interim because of the low volume of sales to Fiji, but I'll keep this in mind if the issue arises again. Cheers!

Figured it out! We were populating the 'Display Name/Code' field with the same value as the 'Item Name Number' field (a practice that was in place before I started, not sure why...) which is redundant if you want the code to display with the same value as what NetSuite uses, so I'm wiping that value for every item to fix…

Thanks for the feedback! Sounds like it's do-able then. Would this be the right order to do things to make the transition? 1) update all item records with Category, Sub-category, etc. custom fields (to replace use of accounts for this purpose) 2) create and test new (or edit) reports to replace any that used the old…

Whoops double posted that reply :P

I was wondering about that, but like I said one of the directors here uses an administrator role, and he didn't get the published dashboard, and a sales rep who I switched to the 'classic interface' doesn't see it either. isn't that right, that I can get everyone to switch to the classic interface, then I can just publish…

Bugger! I wondered if that was the case.

So I've fiddled around more, and still no closer to figuring this out. I think I may have been confused in that using the 'classic interface' is not the same as your role being part of the 'classic center'. So this is what I tried this time around: 1. Created custom tab, set to 'all' centres 2. Changed role to sales person…

Well we got a price on SCA, and it's ridiculous. I won't quote it but basically it would double our yearly spend on NetSuite, and we run OneWorld with 3 add-on modules and 40 users! We can't seriously consider Site Builder, because it's stated limitations rule it out and it's going to be phased out sooner or later as well.…

Logins will definitely be by customer (or customer contact). We know we'd be SCA experts by the time we finish it, what we need isn't a run-of-the-mill online store. So with SCA we can read and write pretty much any fields, lists and record types in our NetSuite account, standard or Custom?

I was afraid it would come to this, this means we'll be opening several accounting periods to edit the original item receipt, then hoping it fixes it, before we close them off again. Of course we'll have to make sure there isn't any net GL effect change as well...not the ideal solution but sounds like it may be the only…

Well I ended up re-opening previous accounting periods, deleting all the related transactions, deleting the troublesome lines off the SO and PO, then adding them again and re-doing all the related Item Receipts and Bills.

There are no other orders that the items are being automatically committed to, only this order appears under Reallocate Items. I tried creating a new sales order and it then appeared under Reallocate Items, and it let me successfully move the allocation, but then same issue with the new order - it would not let me fulfill…

First, let me thank the NetSuite team for paying attention to customer feedback and making some quick changes as a result. My first reaction when viewing the web demo on 2014.2 was "wow...ok, it's a big change, but probably for the better, people will get used to it". My second reaction after logging in to our release…

I use CASE all the time and they can be very tricky. Rather than try and work out the logic (I haven't had my coffee yet), can I suggest simplifying it? It looks like what you're trying to say is you want {subsidiary} when custbody193 and custbody194 aren't the same, regardless of which is true and which is false. See if…

Oh that's a pity! This would be so great. The current record is loaded so all the values are there. It would be great if, for example, after I chose 'Expected Close Date' on the Criteria subtab, and it pops up asking you to set criteria, an option would be to base the criteria on the 'Current Record'. So for my example,…

I've compared this to customising a transaction form...on the transaction form under Screen Fields -> Columns you can change the order of the columns and their labels. That's essentially what I want to do with the child record fields, and it looks fine in view mode, but going into edit mode reverts it back to default…

Well I ended up having to rename the custom fields in the child record type to match exactly how I wanted to see it on screen. Still seems weird that a custom view on a child sublist is ignored in Edit mode...why would you want it to change?

Yes they're all either manually entered or created from a Quote.

Thanks everyone, even if it's a hefty project it would be worth it, it could generate an extra $500K+ of revenue each year which would otherwise be lost because sales reps don't track renewals properly. We're currently paying around $300-$500 a month for a solution which technically does this but it requires an extra 20…