https://netsuiteprofessionals.com logo
Join Slack
Powered by
Hi everyone, i am using restlet to create sales or...
# suitescript
k
Hi everyone, i am using restlet to create sales order, and skip the creation if the sales order already exist. I however am running into duplicate order because I believe it is because the restlet is being called again before the record is processed. Is there a way for me to await until a sales order is created and is in the system before sending request back?
l
interesting. dup sales order id only, or completely duplicate orders?
k
completely duplicate order record
c
@Ken What are you using to determine whether a Sales Order is a duplicate? Do you only ever want the RESTlet to be active for one Sales Order creation process at a time?
k
yeah, i currently have a search to see if an order exist on Netsuite, if it does , it skips
c
What are your criteria for determining that it's a duplicate?
k
Copy code
function checkExistingOrder({ AmazonOrderId }) {
  const searchObj = search.create({
    type: "transaction",
    filters: [
      ["numbertext", "is", `${AmazonOrderId}`],
      "AND",
      ["poastext", "is", `${AmazonOrderId}`],
      "AND",
      ["class", "anyof", `${sales_channel}`],
    ],
    columns: [search.createColumn({ name: "entity", label: "Name" })],
  });
  const searchResult = searchObj.run().getRange({ start: 0, end: 1 });
  if (searchResult.length > 0) {
    return true;
  }
  return false;
}
l
i think tranid should be used.
k
I use PO + NumberText together because we use a fixed number on tranid. This means tranid = 555 get match with 0055500 or 1255512
I had issue when I query tranid because of that
c
@Ken Do you ever see that search returning 
true
when executing the RESTlet? Is the case just that sometimes, multiple calls to the RESTlet in quick succession will result in multiple SOs with the same PO number?
k
yeah, I do all the time, i have a log.debug on every run
c
You could add logic to a beforeSubmit script deployed to the Sales Order that prevents it from being saved when the duplicate criteria are met.
k
We have a sync from webhook and a fallback batch cron job to sync.
but wouldn't that not work for beforeSubmit, this is because the record is technically not in Netsuite?
or not processed*
c
What I mean is, if the RESTlet gets called again with duplicate data prior to the first order being saved, when the second Sales Order is saved, the beforeSubmit script should catch it and prevent the duplicate from being saved.
k
ah, will beforeSubmit be able to catch the one's in processing?
c
Yes, if one slips past the RESTlet, it should get caught in by the beforeSubmit.
k
ok sounds good, will give that a shot
c
Another option would be to implement a lightweight queue record that records the unique criteria set from the RESTlet request. Saving that should take much less time than processing a Sales Order save (which could take seconds, depending on workflows and scripts deployed to them). You could check for the existence of a queue entry with the criteria at the top of the RESTlet -- if found, error; if not, create the queue record then create the Sales Order. Best practice would be to include a status field so you could capture stages such as REQUESTED, SAVED, ERROR
e
^ This sort of queuing approach is what I tend toward for most integrations, particularly those that don't need to be near-real-time.
k
I have a queue set up on our back end system, recently and that rule out a lot of the duplication, but not fully perfect
a
A quick and simple way to fix this is to use external ID, when you create the Sales Order set the external ID (that you build from your data to be unique for that data set representing your order), External ID is specifically designed to prevent duplicates, only one record with the same external ID would be allowed (default NetSuite behavior). Your external ID could be the unique ID of that Order in your external system (the data source).
👀 1
👍 1
e
^ This works really well if there is only ever one external system creating Transactions. If you have different external systems that generate similar IDs, your risk of false collisions increases
b
tends not to be a problem in a restlet where you can add your own prefix to the external id, especially if its only being used for duplicate detection and not actually as a foreign key
e
True, but still something you have to be aware of, adding your own prefix
i
I agree with the externalid approach its a quick and simple way of preventing duplicates
k
@battk i started adding prefix on my other stores except for the main store.
19 Views
Open in Slack
PreviousNext
Powered by