Hi - We’re building a NetSuite integration with a third party developer that is using the Legacy API via a Celigo REST connector.
For the most part, things have been working well enough however we’ve run into an issue that prevents us from writing PO Receipts back into NetSuite as our 3PL PO’s are received in Shiphero:
During the PO POST we pass line_id using a unique NetSuite ID (combination of transaction internal ID and line ID.)
We do the same thing on the Order POST.
When we do this for Orders, when we then GET the Order, the partner_line_item_id equals the unique NetSuite ID we had previously sent. This allows us to later correctly map shipment confirmation and return authorizations to order lines by passing unique line id’s back and forth.
However, when we GET a PO, the partner_line_item_id has been mutated into some sort of alphanumeric key value that makes it impossible for us to correctly tie back to the received lines in NetSuite.
* Is this behavior correct and is there a way to decode the partner ID if so?
As for the partner_line_item_id for PO, should be the one specified when you created the PO, but the one you are seeing is a random number (not coded) which we assign in case it was not provided when creating the PO.
I already submitted a request for this to be seen by the engineering team, I will get back to you as soon as I get any update.
Just out of curiosity… is there any reason you are not integrating with the GraphQL API? (our Rest API will be deprecated next year).
Thanks for the update. Yes that is exactly the issue, thanks for forwarding on.
The reason for using the legacy REST API is that is what the developer had selected to use when the customer engaged with them - so I’d have to follow up (I am assisting with the integration and issues but am not the main developer.) This may be due to the fact that the integration is being developed on the Celigo integrator.io platform which I do not think has a standard GraphQL connector at this time (let me know if I’m wrong.)
I’m not sure what the prevalence of GraphQL connectors is in popular “user friendly” IPAAS platforms - I suspect something like Celigo might abstract it into a prebuilt Shiphero connector like they do for some other platforms, given the added complexity of GraphQL?
Hi @tomasw - Do you have any update on this issue, or alternatively, an estimate/idea of when this might be investigated?
There are workarounds that we can do to mitigate the impact of not being able to automate PO receipts into the ERP but they are not ideal and we’d definitely like to be able to automate that flow at go-live.
Also, if you have any color on possible IPAAS GraphQL integrations I’d be interested to hear them. Clients of this size can manage integrations much more easily using an integration platform over bespoke integrations.
Hi @sjbpdx!
I apologize for the delay on the update. I don’t have an ETA yet, but I’ll bring it up on our Monday meeting to see if I can get an ETA or better insight from the Engineering team. I’ll let you know as soon as I have more info about it.
On the other hand, I must say I’m not familiarized with IPAAS GraphQL integrations. I’ll try to make some research and see if I can find anything about it.
