Update BO Deleting PackSlip

Epicor ERP 10
1

I have an updateable UD BAQ that, when the status of a field is updated, a pre processing directive on the update goes out and runs this:

  callContextBpmData.Character01 = "";

  foreach(var tt in ttResults.Where(r=>r.Updated()))
  {
    int packNum = Int32.Parse(tt.UD24_Key2);
    try
    {
      using(var shipBO = Ice.Assemblies.ServiceRenderer.GetService<Erp.Contracts.CustShipSvcContract>(Db))
      {
        CustShipTableset cTS = new CustShipTableset(); 
        
        cTS = shipBO.GetByID(packNum);
        
        cTS.ShipHead[0]["KuebixStatus_c"] = tt.UD24_ShortChar01.ToString();
        cTS.ShipHead[0].RowMod = "U";

        shipBO.Update(ref cTS);
      }
    }
    catch(Exception e){callContextBpmData.Character01 = e.ToString();}
  }

Well, it runs without error, buuuut, it deletes the pack slip being updated and updates and entirely different one. WUT?

Example, I updated PS 91339. The code runs, DELETES 91339, and updated 91342.

The message box debugging I did showed that the correct pack slip is being referenced throughout.

2

I’m sorry did you say it Deleted a pack??? :open_mouth:

Do me a favor and pass in the BeforeImage let’s see if that helps

using(var shipBO = Ice.Assemblies.ServiceRenderer.GetService<Erp.Contracts.CustShipSvcContract>(Db))
      {
        CustShipTableset cTS = new CustShipTableset(); 
        
        cTS = shipBO.GetByID(packNum);
        //Create Before Image
        var origRow = cTS.ShipHead.NewRow();
        BufferCopy.Copy(cTS.ShipHead[0], origRow);
        cTS.ShipHead.Add(origRow);
        //Update Record
        cTS.ShipHead[0]["KuebixStatus_c"] = tt.UD24_ShortChar01.ToString();
        cTS.ShipHead[0].RowMod = "U";

        shipBO.Update(ref cTS);
      }
6 Likes
3

Oh yeah–full on gone. I even tried it twice to make sure I wasn’t crazy.

That before image worked, but I’m not entirely sure what that’s doing. ELI5?

4

Sooooooooooo… you don’t just wanna take it at face value? The explanation is long winded (and my memory is spotty) lol

So back in 9 or possibly 8 (6???). Progress had these shadow records called BeforeImage
https://knowledgebase.progress.com/articles/Article/P17959
Its basically a transaction which keeps track of what’s changed in case there is an error. Some of Epicor’s logic used this BeforeImage records to figure out if something changed.

For example on a BPM when you say Condition of Field X changed to Z to V it used (and uses) the before image to figure out what changed. There is also some logic in the Business Object which uses the before image to determine some “logic” flow. For example if BI.Field X == “P” then Do RainBowMagic

In 10 they kept that same mechanism by passing in a copy of the current (unchanged) record without a row mod, and when you write a BPM that checks if field X changed it uses that to figure it out. So in the Shipping BO there must be some logic where it checks the BI and if it can’t find it, it behaves erroneously.

We should ALWAYS use the BI when we call BO’s from a BPM. When we do it from the UI using the Adapter Epicor is nice and does that for us.

Note the terminology/context may not be 100% accurate, maybe @Bart_Elia can correct me where I’m wrong it’s been a few years since I looked at this but that’s the gist as I recall.

3 Likes
5

Whelp, then I’ve been a certain combination of lucky/naughty because I didn’t even know that was thing. I’ll add it to my toolbox!

3 Likes
6

We have all been doing it, it works 89% of the time without it, but that 11% is a pain in the ass. For example if you want to UnRelease a Job without the BI can’t be done if you have the prevent changes to Released Job checkbox in your company. It will refuse to let you do it in code. Because when it checks “what fields changed” (which should only be the released flag) it fails to see this and stops you. There are many other examples were this is the “solution”

I"m working really hard to make sure that all my code as of the last few months does this correctly,because I believe Epicor is getting more serious about it in the newwer releases I get bit by it again and again.

5 Likes
7 
    //Create Before Image
    var origRow = cTS.ShipHead.NewRow();
    BufferCopy.Copy(cTS.ShipHead[0], origRow);
    cTS.ShipHead.Add(origRow);

Will the syntax ever change much from this or can I basically copy+pasta with a few modifications to the tables?

8

Should be the same for everything just make sure you “clone” the right table.

1 Like
9

Jose you have the name right - You’ll see a bunch of variables like BIOrderHedRow or the like.

Some of the functionality is a lot of fuzzy - have not been in there in years and not day to day on ERP so you probably have it fresher in your head than I do (Too many cobwebs since I am spanning products now).

1 Like
10

Wow. I have never seen this requirement before. But the BI record definitely saved the day. Thanks for the insight Jose.

1 Like
11

HandHeld.CustShipTest.CustShipTableset custShipTs = client1.GetByID(packID);
if (custShipTs != null)
{ //Create Before Image
var shipHeadRow = custShipTs.ShipHead.NewRow);
Epicor.Data.BufferCopy.Copy(custShipTs.ShipHead[0], shipHeadRow);
custShipTs.ShipHead.Add(shipHeadRow);
}

shipHeadTable does not contain a definition or an accessible extension method “NewRow”

12

Try changing it to

var shipHeadRow = custShipTs.ShipHead.NewRow();

I think you left out the beginning ( after the NewRow

13

many thanks for responding, it is correct but that is not the detail I have it like this
var shipHeadRow = custShipTs.ShipHead.NewRow (); It will have something to do with the epicor version, I’m in 10

14

Here I am… in 2022… baffled as to why a RowMod=“U” (for updating a ShipHead) — ended up removing it!
The ShipDtl lines are still there, btw.

If I was not shaven… I would be pulling my hair out!! I was originally doing an UpdateExt which has other problems – so I modify my Epicor Function to use the GetByID/Update approach. I spent hours on this – why did it remove the ShipHead!!

I search the site hoping someone shares a similar issue and come across this topic. This site is a life-saver at times!!

I believe this is an issue in BPM and Epicor Function land. Direct DLL BO does not seem to do this at all, which our legacy code still does. I have never known a ShipHead being removed like this.

Is there any other sections of Epicor we need to cater for this “fix” other than ShipHead ??

Cheers

1 Like
15

I still forget about this.
It literally just happened to me yesterday. So annoying.

1 Like
16

… So I had a transfer order pack turn to 0 the other day and I am trying to figure out if it was my function for updating it or some other weird bug.

Are y’all saying that it completely deletes it or does it turn the packnum to 0?

17

It deletes it.

18

Alright.

19

Glad it is not just me in recent times. Hopefully you have a workaround (like I now have)

1 Like
20

I just had this happen to me today when I was playing around. Love this forum.