Anyone every successfully use the `record.attach` ...
# suitescript
d
Anyone every successfully use the
record.attach
function?
I know my custom record and relationship is setup correctly as I can perform the attach/detach grea inthe UI
Copy code
record.attach({
    record: {
        type: 'customrecord_xxxxx_trans',
        id: 1
    },
    to: {
        type: record.Type.PURCHASE_ORDER,
        id: 10959
    },
    attributes: {
        field: 'custbody_xxxxx_trans'
    }
});
"You have entered an invalid type argument: customrecord_xxxxx_trans" is the message I get
Copy code
customrecord_xxxxx_trans is the custom record 
custbody_xxxxx_trans is the transaction body field that holds the relationship
I'd pay money for the right answer at this point
😳 1
c
Your code looks correct in terms of using the API. have you tried converting both IDs to strings or numbers? I ran into something recently where my ID worked as a string but not a number.
e
Ya, I did that too @creece
If I could inspect what NetSuite is doing when it's attached in the UI, but I don't know how.
c
i've honestly never attached a record like that only emails
b
two things wrong
first is that the custbody field is being used for parent/child
which means that the child purchase order is being attached to the parent custom record
e
The relationship is the other way
b
second is that only the reverse is supported in suitescript, only a child custom record can be attached to a parent transaction
e
From my custom record, I can attach the PO (in the UI)
So, am I doing this the wrong way? I'll test
b
if you reverse the relationship you get a more useful error message
and you can confirm that the relationship works as I described by using a field on the custom record for the parent/child relationship
e
I'm trying to manage a NS PO with an integration, and want to NOT interact with the PO at all. So, my thought is to create a custom record attached to the PO that I can use to manage the PO
I'll play around a bit, but I have it set up the way I want in the UI. Reports, searches, etc are perfect
d
Well, every combo I tried failed .. .but like you said @battk, when I reversed it, the error changed
One of the other things I'm trying to do is to 'Source In' a status from the custom record onto the PO. So, that means the PO needs to be the child
I guess what's most frustrating is the fact that it all sets up well in the UI
I simple cannot perform the 'attach' in SuiteScript
b
you can do the same on the record by setting custbody_xxxxx_trans
although that tends to be unfavorable since these sort of solutions are usually made to avoid edits to the transaction
d
That is exactly why I'm doing this pattern. I don't want to make any transaction edits at all
c
When are you creating these custom records that manage the PO? If you can create one on create of the PO and then set it on the PO, then you can get around editing the transaction.
d
Ya, these could be existing POs.
Attaching of record type transaction to customrecord_xxxxx_trans is not supported.
Damn!
Ok, I may have to resort to doing a submitFields after the creation of the custom record.
c
You could also do something like what i mentioned and have a process that creates the custom records for "historical" POs and then do a CSV import and not check run server-side suitescript so no scripts fire. So going forward you'd have the relationship w/ no edits and "historical" records are also taken care of w/ no scripts firing.
Im just throwing out ideas for not firing scripts
d
Appreciate any/all ideas @creece
Its for a SuiteApp, so low-touch/no-touch
c
I also am kinda iffy on not doing something like that because it runs scripts. If the scripts were written properly, there shouldn't be any issues and if there are, its on whoever script wasn't correct.
BOOM Found the answer (undocumented)
d
how'd you find that out?
d
Monitored the 'Network' tab in my browser to see what NetSuite was doing when I clicked the 'Attach' button
m
Are you doing that client side?
d
I'll be doing in server-side in my solution
m
Does it work server side?
d
I can't see why not
m
You don't have the session credentials server side
Also pretty risky using an internal endpoint in a suiteapp
d
While I agree @michoel (whole heartedly), the alternative is worse
b
if you are trying to avoid the last modified date, you probably dont have any good choices
if you are just trying to avoid other workflows or user event scripts, then you can take advantage that user events wont trigger other user events
e
Yes, while it's not exactly documented it's doing exactly what I need
n
Did it work server side @darrenhillconsulting?
d
No, it didn't