Here's the full code snippet. <@U5TF1GQ20> <@U5L94...
# suitescript
c
Here's the full code snippet. @battk @eminero
b
minor variation of the previous answer, the sales order line id is not the same as the item fulfillment's line id
although you have already been told about the orderline
c
@battk I would have thought they are the same until you save the fulfilment?
At this point in the code, the fulfilment is the result of a record.transform but .save() hasn't been called.
Unless they are set as part of the transform() function. I assumed they would be set during .save()
b
on create it should be fine, mostly because it inherits the line from the sales order, but that line will be overwritten on save
c
Yeah, I'm mutating the fulfilment before it is saved
so the lines should be identical
r
orderLinId: 12 === Line 13
0 index when dealing with sublists in 2.x
c
Nope
OrderLineidn is the same as the line
It’s a variable
r
when dealing with item fulfillment, you will see lines disappear that have been fulfilled and make your lines not matchup with the sales order. That what you’re referring to?
c
Nothing should disappear
I’m rewriting this function to make it clearer, that’ll probably fix it. Just looking for a consistent way to match lines on SO, TO and IF before the IF is saved.
b
the other thread has the answer for line id and line number not being the same thing
not even offset by 1 for the difference in index
r
Copy code
if (!keepLineItem)
          lineItemNum = fulfillmentRecord.getSublistValue({
            sublistId: 'item',
            fieldId: 'item',
            line: i - fulfilledLines,
          });
It wasn’t the most efficient means, but I had to compare the item fulfillment record against the sales order to ensure the lines were matching up, or add a flag to skip a sales order line when working with IF records
Copy code
if (lineItemNum !== lines[i].SOitem) {
          keepLineItem = true;
          fulfilledLines++;
          log.debug({
            title: "lines[i].SOitem doesn't match ",
            details: {
              keepLineItem: keepLineItem,
              lineDetailsItem: lineItemNum,
              SOItem: lines[i].SOitem,
              newFulfilledCount: fulfilledLines,
            },
          });
          continue;
        }
c
Was this working presave or post save?
r
it was exec with
beforeLoad
on IF records
b
that code matches by item, which is fine if dont have lines with duplicated items
r
it was clunky, so we went back to modifying the SO record instead, but it was how we addressed lines not matching the SO after items had been fulfilled.
that is only a part of it, it does check for lines and it checks for “non-item” lines and adds a skip for each from the sales order.
b
Copy code
const fulfilmentLine = fulfilment.findSublistLineWithValue({
	sublistId: 'item',
	fieldId: 'line',
	value: orderLineid
});
is an attempt to match fulfillment line id to order line id, which in general is wrong, but during create is fine since the fulfillment doesnt have line ids yet so the line id on the fulfillemt is temporarily the same as the sales order
👍 1
r
Copy code
if (itemRecord.type !== 'inventoryitem') {
          log.debug({
            title: "objRecord didn't match",
            details: itemRecord.type,
          });
          keepLineItem = true;
          fulfilledLines++;
          continue;
        }
        if (lineItemNum !== lines[i].SOitem) {
          keepLineItem = true;
          fulfilledLines++;
          log.debug({
            title: "lines[i].SOitem doesn't match ",
            details: {
              keepLineItem: keepLineItem,
              lineDetailsItem: lineItemNum,
              SOItem: lines[i].SOitem,
              newFulfilledCount: fulfilledLines,
            },
          });
          continue;
        }
c
It’s using the result of record.transform without a .save()
So those line ids should be the same
Until you commit to the DB via .save()
The alternative is doing it after .save which will require .load
r
@Craig, if its not time sensitive you could pass that .load off to a scheduled task on afterSubmit
c
Fixed: As expected, this was an off by one error. Some code was taking the line attribute and not running it through findSublistLineWithValue()