https://netsuiteprofessionals.com logo
Join Slack
Powered by
anyone have a code snippet for copying line items ...
# suitescript
r
anyone have a code snippet for copying line items from one transaction to another. This would be a customer transaction to a Purchase order. similar to record.transform.
c
You can break this down into multiple steps and look for code examples for each step 1. open a transaction 2. loop through the items list and save each line into an array (deciding which fields you wants) 3. open a PO 4. Add each element in the array to the item list in the PO (decide what to do with existing items on the PO, if any)
r
thanks, I do this for other transactions but I was hoping for an easy way to copy all line item fields by default.
s
Copy code
_.map(tx1.item, i => {
 const newLine = tx2.item.addLine()
_.assign(newLine, i)
})
j
I have something but it was annoying when there are item groups
does it step by step, not in one fell swoop
r
thx all for feedback
c
@Shawn Talbert and now you've limited your scripts to devs that can use lodash. Have you not seen the average level of software engineering competence in the NetSuite world?
s
actually, I believe without doubt that it's even more important for newer developers to use something like lodash. The alternative is they write a bunch of code to perform the same behavior -full of bugs, poor performance. I feel it's akin to asking a new driver to build their own car (writing all the code themselves) vs. driving an already built car (using battle tested libraries)
with lodash in particular - it's a library already debugged doing low level things. My position is there is little value in a developer reinventing anything in lodash. Far better to spend your time on the actual business problem. I'd suggest it's experienced developers that should be making tools like lodash - and newbies should be using tools like lodash - not writing amateur code to ultimately achieve the same result.
Sorry this is a bit of a sensitive topic for me 🙂
last but not least - using libraries like lodash result in easier maintenance. Both because you typically have fewer lines of code with function names that are well known and thereby easy to read and it's well documented. There will be none of that for random spaghetti code written by the noob that achieves the same thing. My position is - unless one is sure they will do better in terms of familiarity of code to other devs, readability, performance, unit tests, and documentation, you should use a library.
r
Shawn, not scared of lodash and love learning new things... but if I read correctly, its an iterator to add current item to another array. Is this a copy (map) of the item or reference pointer of existing item? I can read the documentation but thought you might give quick thought. If it is a reference and not copy then will NS like a ref vs a copy?
s
sorry @redfishdev none of my rant is meant to be aimed any anyone in particular. Syntax like I show in my psuedocode is simply NFT (another library that makes using other libraries like lodash possible)
r
I have not seen NetSuite FastTrack Toolkit. thanks for sharing , will digest. Back to my question if you know. Does NS allow pointer addition to another records sublist or should it be copy. I assume should be new object copy and maybe these libraries facilitate that faster.
I can try each method but always looking to learn
@Craig @Shawn Talbert Shawn, I see you are an author of NFT. Some neat things there. Seams like an object oriented style abstracting SS2 code. The code looks cleaner/smaller footprint like " var c = new Customer(1542)" in the example. But this would require the next developer to understand your custom framework. One simple approach might be a simple helper function module that abstracts just as easily unless I missing something. Something like var c = nsHelper. loadCsutomer(id); It seams 90% of my SS code involves customer, standard transactions, sublists, etc. Or is the real goal for a strongly typed environment?
s
In my humble opinion, someone coming in new to NetSuite development but experience elsewhere will ramp up on NFT faster than 'native' netsuite APIs. Because NFT provides commonly used patterns that many developers are already familiar with. In contrast, NetSuite's API for data access are similar to Java circa 1995
NFT just requires you to know some JS 101, such as "data is objects with properties", assignment is done through built in language features everyone is familiar with (e.g. 
=
)
The strong typing is a nice side effect too 🙂
NFT provides utility for both OOP and FP style, by design.
Native netsuite supports neither OOPS or FP imho. So, NFT lets me use well established patterns and libraries, which in turn results in code that is often about 33% the size of 'native' suitescript. Cheaper to write, cheaper to maintain, win win as they say. I can't imagine writing SuiteScript without NFT. It'd be like asking me to ride a horse to work instead of driving my car.
c
@Shawn Talbert I get it - I'm a convert
Clients are being told they need to spend more money to fix issues because the previous dev used 'non-standard libraries that are unsupported by Oracle".
Then the CTO gets all upset because he heard that something is 'non-standard'.
Seen that happen a few times now.
I come from the land of comp sci and soft eng, so I get it, it's still an issue when you're using libraries that other contract SS devs will complain about though. Your client needs to make a conscious choice to be ok with your choice of libraries and understand what the longer term support issues may be. If you've got a strong in-house NS competency, this is less of an issue.
I just rolled off a project with one of the largest NS users in the UK, they would not accept a new library being introduced that hasn't gone through the architectural governance process where one of the criteria is the number of resources available in the dev market. There are so few SS devs already, it seems risky (according to them) to add more barriers and ramp up time for new contractors. Of course, this needs balancing against the improved code quality etc.
r
Craig this is my fear. but more so as I learn more and more quickly about this platform I have to already go back and refactor old code. to go back and refactor 100+ scripts for a new library and test them all is daunting. On a new install I would likley use this kind of library but I fear having some with and some without and then tomorrow learn about an even better library. vanilla has some value.
s
the problem is folks with the 'not invented here' syndrome are living in denial of reality - if you're not using a library, you're writing bad, buggy version of whatever the library would have done. That code will be generally less secure, harder to understand and maintain, and more brittle. A few of these arguments held up back in the days when closed-source code was dominant.
c
@Shawn Talbert it has little to do with 'not invented here' and everything to do with resourcing risk. I've sat in plenty of architecture design decision boards and heard this over and over again. Do we go all in on a library and pay every contractor we bring onboard to learn it? What happens when lodash isn't flavour of the month anymore? Will we end up with a library that nobody wants to use anymore? Damn... we made this mistake with angular etc etc... Going with what Oracle supports guarantees you resourcing availability, even if you have to pay oracle professional services. If someone really wants to introduce third-party libraries, they need to be brave and take responsibility for that risk but large companies are political and nobody gets promoted because they chose a better JS library, hard to measure that in your KPIs...
s
I politely disagree. Not using well tested, well known libraries is maximum risk, across the board.
One story from my personal experience - I once spent over a week to track down a bug caused by a team writing their own code instead of using a standard library. If I hadn't found it, it would have cost them a $1million bonus on a contract due to slipping the completion date. The whole fiasco would have been avoided if they didn't roll their own (buggy) code.
I wouldn't want to hire an experienced JS developer that doesn't know lodash or a comparable library.
c
@Shawn Talbert nor would I, it happens though. You also tend to find the good JS devs don't want to work in ERP/NetSuite so you get what you can get on the market.
14 Views
Open in Slack
PreviousNext
Powered by