How easy is it to lose money for your client if yo...
# sdf
c
How easy is it to lose money for your client if you don't pay attention to details? This code is supposed to check the itemreceive box on the item fulfilment record using the line index coming back from the findSublistLineWithValue() call in the first block of code. As you can see, the value field on the findSublistLineWithValue() function call is wrong, the code is passing in an Object into that field which is clearly a defect as it will ALWAYS return -1 I would hope that NS would throw an error/exception when trying to setSublistValue where the line index is -1 but instead it still works.. it looks like it just sets the value of all the line items starting at index 0. WTF netsuite? This means that the next line of code (sets the quantity that was fulfilled in the JSON message) is always going to default to all instead of the actual number in the JSON from the warehouse. This code will always miss an underfulfillment from the warehouse and assume that 100% of the ordered qty was fulfilled.
netsuite 1
b
although not really sdf, this sounds more like the preference for
Default Items to Zero Received/Fulfilled
is set to false
c
Wrong channel... doh
b
meaning the code did nothing
c
Yeah, you can config your way around this but your code needs to be a bit smarter. Setting a value against a -1 index is not the right thing to do.
The real answer is that the code should log a message saying that the item was not found on the transformed IF record and not process that line form the JSON. That's far more robust than relying on the system preferences to not allow your code to fulfil the wrong amount.
b
usually for integrations you want to set everything to not received
and then receive the things in your data
for more general cases, you really dont want to rely on the item being unique
c
Yeah, you need a unique identifier
as findSublistLineWithValue() will only return the first match
@battk So you're looking for this value ('looking for') is a phrase, not literal.
It's already set to true - but the bug remains...
b
not that im looking for it, but you set everything to false anyways so it doesnt matter
c
All that does is default the IF line item to not be checked on transform by default
that doesn't mitigate the issue in the code although it probably should - I think that setting is getting ignored - maybe a defect in NS?
I don't fully understand how this code is managing to fulfil every item when the line index is -1 on each iteration of the loop - that doesn't feel right to me given that setting is enabled.
b
it shouldnt
as a minor example
Copy code
require(["N/record"], function (record) {
  var fulfillmentRecord = record.transform({
    fromType: "salesorder",
    fromId: "29411",
    toType: "itemfulfillment",
  });

  log.debug(
    "line 0 itemreceive: " +
      fulfillmentRecord.getSublistValue({
        sublistId: "item",
        fieldId: "itemreceive",
        line: 0,
      })
  );
  log.debug(
    "line 1 itemreceive: " +
      fulfillmentRecord.getSublistValue({
        sublistId: "item",
        fieldId: "itemreceive",
        line: 1,
      })
  );
  log.debug(
    "line 0 quantity: " +
      fulfillmentRecord.getSublistValue({
        sublistId: "item",
        fieldId: "quantity",
        line: 0,
      })
  );
  log.debug(
    "line 1 quantity: " +
      fulfillmentRecord.getSublistValue({
        sublistId: "item",
        fieldId: "quantity",
        line: 1,
      })
  );

  var PLFulfilledItems = [{ quantity: 5 }, { quantity: 5 }];
  for (var i = 0; i < PLFulfilledItems.length; i++) {
    var index = fulfillmentRecord.findSublistLineWithValue({
      sublistId: "item",
      fieldId: "item",
      value: {},
    });

    log.debug("index: " + index);

    fulfillmentRecord.setSublistValue({
      sublistId: "item",
      fieldId: "itemreceive",
      line: index,
      value: true,
    });

    fulfillmentRecord.setSublistValue({
      sublistId: "item",
      fieldId: "quantity",
      line: index,
      value: PLFulfilledItems[i].quantity,
    });
  }
  fulfillmentRecord.save();
});
outputs an error, because no line has been fulfilled
c
That's what I would hope for - I don't know why this account isn't getting that error
b
id double check to make sure there are no scripts that are interfering with your code
c
Yeah, often times I find workflows interfering.
b
and potentially run something simple like i did
c
also, it's my inherited code - I would always check for -1 🙂
s
all this is an argument against using that API - checking for -1 doesn't really describe anything about the business problem.
_.find()
is what I'd use - you either get a line object or not - far closer to the intent of the code imho.
a
I don't understand why checking for -1 is not the right way to do it?
findSublistLineWithValue
is documented and clearly states that it returns -1, so why not checking
index
!== or === -1?
Never had a problem with
findSublistLineWithValue
with the exception of multiple/duplicate possible values in the sublist in which case I write my own implementation, but I don't see how this is a bug in any shape way or form.
s
If you're referring to my comment what I mean is that checking for the magic value -1 is not intuitive and doesn't describe business requirements. My version reads much more like english and doesn't need any magical -1 check.
a
@stalbert Not your comment specifically but the general idea I got from reading this thread is that this is somehow a bug, which I don't think so... I understand what you mean but -1 is as common as the use of
indexOf
so I guess I still don't get how checking -1 is weird or inconvenient.
s
agreed - if you're using
indexOf
you have to obey its rules
c
@alien4u it's a bug because it's returning -1 every time. That was not the intention of the developer. There is nothing wrong the with findSublistLineWithValue function, that is working as expected. If -1 was checked for, the bug would have been picked up earlier.