QuoteSvc ChangeSellingExpQty

Epicor ERP 10
1

I’m attempting to work through trace log call sequences for different types of updates to Quote lines and am stumped (again).

ChangeSellingExpQty(ref QuoteDataSet) works as per the trace when the dataset contains a single QuoteDtl line. As soon as it contains more than one QuoteDtl record it fails with message “Error in application”. The data being passed has been through the same steps as the trace I’m following, and I’ve logged the full dataset for comparison via both routes and can’t see anything different between them.

Does anybody have any details on what this particular method might be complaining about?

2

Is this clientside? or BPM?

3

BPM. (Well, Advanced Update in a uBAQ).

I’m following a client trace but using the SvcContract, which I’m finding behaves subtly differently.

4

Right, so is this for a new row? or an existing row in the QuoteDtl?
I just had a similar issue with Customer Shipment and it turns out the BO just doesn’t like multiple rows sent into the call.
So I had to clear the ShipDtl make the call and then put it back.
See this

Maybe the same?

5

Very interesting. By the time it gets to this particular call it’s always a set of existing rows because you have to update earlier to even get to this point. It’s only this one call (so far) that’s behaving this way so it does seem odd that the BO is OK with multiple rows generally but not in this one case. I’ve stopped being surprised at the quirks by now, though.

Thanks, I’ll follow this route and see what happens.

6

Well the other issue may be if you are not using the before image.
Try this first.
Epicor in the ABL days used something called the before image (BI) to determine changes and they’ve kept this going in the 10.X version.
Most of us fail to use this properly but technically every call into epicor that updates an existing record should carry a BeforeImge (a un-dirty copy of the modified row)
See this example

UD02Tableset ds = UD02svc.GetByID(udRow.Key1,udRow.Key2,udRow.Key3,udRow.Key4,udRow.Key5);
      //Create the Before Image
      UD02Row OriginalRecord = (UD02Row)ds.UD02.NewRow();
      //Populate it
      BufferCopy.Copy(ds.UD02[0], OriginalRecord);
      //Add to the data set
      ds.UD02.Add(OriginalRecord);
 
 
      ds.UD02[0].Date02 = DateTime.Today;
      ds.UD02[0].Number02 = (decimal)((TimeSpan)(DateTime.Now - DateTime.Today)).TotalSeconds;
      ds.UD02[0].CheckBox01 = false;
      ds.UD02[0].RowMod = IceRow.ROWSTATE_UPDATED;
      UD02svc.Update(ref ds);

I would try the before image first, see if that fixes it. Otherwise try clearing the Dtl.

7

Thanks, I’ll try both. My hunch is that your first clue was the key, based on the fact that everything works fine when there’s only one row and that it’s not on the Update that the error occurs, but I’ll take your advice.

1 Like
8

Reporting back …

It IS the single row issue as per your CustShip thread, but with the wrinkle that there are calls that can happen before and after that don’t care about having multiple rows. That’s very annoying for my current situation, because the whole point of this exercise is to cut down the time taken when the quotes are simple, and it looks like a whole load of these update calls not only can’t be avoided, but there’s additional unnecessary processing that has to happen around them.

Still, at least I have a way forward again. Thanks.

1 Like