BuyToOrder not flagging on first added release with BPM

Kinetic ERP
1

Mostly asking out of fear of making an infinite loop. Am I way overthinking it?

We have a requirement based on a custom field selected on the header to automatically flag the BuyToOrder flag on the release.

It works fine on the GetNewOrderRel method directive, but only on additionally generated releases. The first release that the line creates does not trigger this method.

The only methods I see in the trace are MasterUpdate and then CheckMakeDirectReleases which has no table in the method parameters.

MasterUpdate doesn’t seem to reach the release level of the business object when the system generates it during an added line record.

I then tried data directive, which got me close but there is some buggyness with it.

With no BPM
image

With BPM
image

It is clearly attempting to do something with it. I tried including setting Make Direct to false and Buy to Order to true but the same result occurs.

I have a feeling it is how these checkboxes function and I need to call their ChangeBuyToOrder directive. But since the only place I can seem to catch it changing is in the in-transaction data directive there isn’t a widget for calling another directive out of there.

I tried a post directive on MasterUpdate and finding the appropriate release and invoking ChangeOrderRelBuyToOrder since that didn’t seem to trigger MasterUpdate. I’m hesitant to call Update Table by Query as an alternative because I’m afraid of triggering a infinite loop and locking up our server. Our testing environment is on the same server as our live environment…

It does invoke the method and I get my show message but I get an unchanged release
image

I’m kind of out of ideas at this point besides running Update Table by Query but I’m afraid of causing an infinite loop. Do the Update Table by Query run the same update directives?

2

I believe when I had to do this, I had a BPM with a condition that checked if the added release was release 1, and if yes I called another update to change the flag.

Or, you could do a Data Directive.

1 Like
3

Data Directive sees it being added but when I flag the Buy to Order flag there it completely bugs out. Neither end up checked and there is a false Override note next to Make Direct for some reason.

Data Directive does work for setting other fields, custom fields, etc, but it seems the BuyToOrder specifically is bugging out.

Where else can I get it to fire? I can’t seem to find a place where it updates correctly on the first release.

I have half a mind to add a customization layer that conditionally checks it.

4

Hhhmmmm…, that’s right. You can’t fire a DD after a DD.

Put a DD in that checks if the release is release 1, put something in a BPM field, and then call the Update method again. Check for whatever you put in the BPM field and update the flag.

5

Won’t that infinite loop it? Pre-Process would fire, then the DD would call the update again which would hit the pre-process into DD again? I’ve tried short-circuiting a BPM before using conditions but it has always ignored it and still infinitely looped for me in the past.

6

Or you mean update table by query inside the same DD?

7

You want to do a Standard DD.

8

Your Standard DD would be:

  • Condition, does release = 1 and is RowMod = A
  • True, set a BPM field to Pineapple
  • Call Update
  • False, nothing

Your Pre-Processing MD would be:

  • Condition, does BPM field = Pineapple
  • True, set flag and RowMod to U
  • False, nothing
9

I guess I’m worried that calling a method directive update from a Standard directive would eventually loop through the hierarchy back to standard directive and cause a loop?

Not a 1-1 comparison but I tried having a method directive call itself before using a conditional statement to call itself trying to do a recursive directive and it locked up the server even though I am 99% sure it was written properly in a recursive sense of the phrase. It was a fairly straightforward statement and each time the integer being evaluated should have been decreasing. Ever since then I’ve avoided making any looping directives like this since our test instance shares with our live server.

image

10

That is why you would use a Standard DD. That triggers after the record is saved to the DB. There is a clear end to the call and you are initiating a new one. When it goes to save to the DB again, it will evaluate to False because the RowMod is U, not A.

1 Like
11

Ahhh, so maybe recursion is possible after all too…

I will let you know if this leads to success! Thank you for the info, I hardly use Standard DD’s, usually got away with not using them.

12

They are good for situations like this when you want to trigger something after the call is done, not during.

13

So I have it kind of working - though I see I deviated from your outline a bit. Am I able to calculate and send the dataset from the DD through the Invoke BO widget or do I have to strictly build it inside the method directive?

The green box email does go out, so I know my logic is following down correctly as this was the expected path for my first test case. I wanted to build it this way so I could see it hit each stage, so it would hit BTO, update, then hit the SD and this time hit Plant, update, then hit the SD and exit out.

image
image1057Ă—777 53.7 KB

image

But when I actually check the release, I don’t have the BTO flag checked.

I tried with only BTO flagged and with all 3 flagged. RowMod is also set to “U”

image
image848Ă—184 6.56 KB

But hey at least no infinite loop so I’m less scared now.

Edit - secondary problem I spotted I’ll have to rearrange some of the logic since I need BTO to be on prior to turning on Dropship for that first chain but I’m working down the “is CrossDock” chain.

1 Like
14

Switched it to do the calculation as described, no difference between calculating for the dataset in the SD or calculating in the update method after I’ve called it.

This time I tested on a drop ship variant. All 3 emails triggered, but the actual release didn’t update. This is when it was fully updated in the method directive.

SD Directive,

  • looking for release = 1 and RowMod = A.
  • Assigned ShortChar01 to “FirstRelease”
  • Got the orderrel the record for it, and sent it in the update method directive.
    image
    image377Ă—528 15.6 KB

Then in the update method directive, it

  • checked in the top left “Condition 3” for it to be flagged as “FirstRelease”
  • ran through logic
  • emailed out after setting the fields desired on first release
    image
    image2140Ă—1038 147 KB

Emails arrived successfully as expected
image

But the release itself is missing

image
image1137Ă—370 28.9 KB

15

Did you trace manually setting the flag? There might be a method that fires that we are not thinking of.

16

I got the DD working.

17

Not quite, there is a damn race condition. :donkey:

18

Strange stuff going on with this field.
(I didn’t have the same issue on FirmRelease)

Trick is to hit it twice.

You must set it when the row is added, which will then fire it again, and you catch it on update.

I’m struggling to explain it, but here is how to set the first release for a condition.

bool yourCondition = true;

if(yourCondition)
{
    //Fire on "A" & "U"
    var rows = ttOrderRel.Where(x => !String.IsNullOrEmpty(x.RowMod) && x.RowMod != "D");
    
    foreach(var row in rows)
    {
        row.BuyToOrder = true;
    }
}

Subsequent releases you catch in the method directive on GetNewOrderRel.

19

I’m gonna try.

If you try to set it just on RowMod == “A”, nothing happens.

For some reason, the DD fires again with a “U”, IF and ONLY IF, you TRIED to set it on RowMod == “A”, otherwise, it does not fire a “U”.

So you have to set it on “A” first, then “U”. Can’t chose.

GIF by NETFLIX

On the other hand, with the firm release flag, this worked fine:

var newReleases = ttOrderRel.Where(x => x.RowMod == "A" && x.FirmRelease == true);

if(newReleases.Count() > 0) 
{
  foreach(var rel in newReleases)
  {
      rel.FirmRelease = false;
  }
}
2 Likes
20

that is not funny austin powers GIF

1 Like