BuyToOrder not flagging on first added release with BPM

Kinetic ERP
21

Thought I had it working about 10am - it’s now 5 and I’m just discovering some more dumpster fire shenanigans with this one. I am building it with widgets though so ymmv.

First in-trans DD record is an ‘A’.

It only generates the ‘U’ if you try to update one of the fields that trigger additional background events such as BuyToOrder. If I update other fields it doesn’t trigger the ‘U’ in-trans DD. I have suspicion drop ship or plant may work similarly but haven’t tested.

The Standard DD fires regardless, but in an ‘A’ state. This occurs only once after both the ‘A’ and ‘U’ in-trans DDs have completed.

If I call a method directive Update off of the Standard DD, it doesn’t hit my in-trans DD again or the Standard DD again.

Maybe I was blind and doing something wrong, but I also couldn’t get it to recognize my unsetting a contextCallBpmData field. I was trying to run the in-trans ‘A’ record, set a flag, then run the in-trans ‘U’ record and unset the flag. This way it wouldn’t set the default on subsequent updates. For whatever reason, even though I did this

  • if Condition rowmod ‘A’ ?
    • then set flag + set bto
    • else if Condition rowmod ‘U’ and flag is set ?
      • then un-set flag + set bto

it was still triggering the second condition on all ‘U’ records regardless of if it was happening from this silly BTO thing or a regular update.

Furthermore, even if it was working as intended, I need to then set an additional dropship flag.

When I run it the first pass through it will do
In-Trans A, In-Trans U, Standard A, Method Update.

What I would like is for it to carry on to run through the In-Trans or DD again, so it can flag the dropship.

Right now, because I have a method directive on Update to validate the fields again, the condition ignore step is a non-issue for me, but still buggy and would like it to respect it. But I need to get further calls to go through to set the drop-ship flag and plant properly. My method directive actually attempts to set BTO, Drop Ship, Plant, etc but because BTO is “not flagged” yet to the system it doesn’t flag drop ship. Once it saves and if I change a random value on the screen, the method directive works fine for swapping those. Just need to bridge the gap between flagging BTO and flagging Dropship.

Leaving yours solution though since it technically does answer the original question.

1 Like
22

May I ask why? This level of complexity is way beyond widgets.

Also, would you mind mapping out exactly what you want to happen?
You may have already and I just got lost, but a simple list in order might jog loose some ideas.

23

I was throwing a bunch of message blurbs in between each step of it to debug it early on trying to see when values were actually changing and which ones. I also am impatient and find the added time opening the BPM up again, then opening the c# widget up again annoying. Those two are some of the slowest to load screens in the system lol.

It also helps me keep track of what I’m doing a bit better. I usually do a hybrid of widgets and code but if I’m working with a single row I tend to stick to widgets when I can. Also keeps it a little more readable for some of the non-coders that are in the bpm’s occasionally.

I also anticipate Epicor gutting c# widgets at some point so don’t want to rely to heavily on them… especially after this System IO stuff.

So basically, we have a custom “OrderType” that gets set on the Customer.

Based on the OrderType, we default the OrderType along with 2 other fields on the header level on the added record only. The user is free to change these after it defaults. Then releases also copy these 3 fields down as a default on the added record only. But alongside these 3 fields, the release also may get flagged BTO, BTO + Dropship, and the plant + warehouse may change.

Each OrderType has a defined structure for these 6 additional fields, so while the user can change the OrderType on the release after the fact, any mismatches from the OrderType’s structure then gets automatically set again based on the OrderType and we let the user know which fields got reset on them.

All of these requirements work, other than the BTO flag and dropship flag being set when required, on the first release. And there are technically additional calls happening that shouldn’t need to be on a regular update, but because of our validation method it is a non-issue.

Well, now the BTO flag works, but the dropship is being missed since it hasn’t finished setting the BTO flag fully yet when it tries to set dropship.

Edit - I should also mention that the BTO flagging works without a standard directive at all - but I am using it to try to trigger the dropship flag by either running the drop ship method, the update method, or the in-trans method again.

1 Like
24

I imagine that is working, but by that time the data is back to the screen.

Any saves would overwrite it.

25

Screenshots of what I’m trying to accomplish

In-Trans

image
image1125×1044 72 KB

Standard
I tested after this screenshot, but it is making it to the is Dropship false condition

image
image1322×936 57.4 KB

Then it triggers my MD for Update

image
image909×1071 85.2 KB

This code would be very short and readable lol… it’s for the non-coders :sweat_smile:

26

Not trying to be a :donkey: , but who do you think is going to look at this and understand it?

I know I sound like it anyway, but it’s a serious question.

27

Can’t say, there’s a widget guy watching @markb_wi :face_with_peeking_eye: I could use some more descriptive titles on some too that would help.

1 Like
28

Thanks for the help on this - I’m going to mull this over overnight and come at it with a fresh brain tomorrow.

1 Like
29

Also not to be a :donkey:, but not all of us are coders. I can read that and understand it… I would not be able to read it in C#.

1 Like
30

Three Little Pigs Wow GIF by Laff

31

Nope… don’t think that… but those widgets have been a lifesaver for me more than once when our Dev guys were too busy. They’re clunky, they’re certainly slower, and arranging them all on the canvas can be interesting, but they get the job done for those of us who are minimally-at-best skilled in that area.

2 Likes