Kinetic BAQ designer - can no longer have criteria on two different tables in the same subquery?

Kinetic ERP
1

Is anyone else struggling with this issue in 2025.2? It seems like the baq designer isn’t seeing the two table widgets as unique. I have recorded what is happening since its hard to explain. Anybody already have a PRB for this? I can’t find a workaround, having to go back to classic BAQ designer, again, at 2025.2.

Time is running out before the classic sunset. Kinetic BAQ designer is still not ready for prime time. We need the classic baq designer, in power tools, now. Even if this bug got fixed tomorrow, that would not change anything. Just as this show stopper bug was introduced in 2025.2, any new show stopper can again be introduced in 2026.1 or future editions. The stability is simply not there with the kinetic development toolset.

8 Likes
2

I just tried it in our 2025.2 DB but didn’t get the issue:

image
image1015×554 22.6 KB

Shocked Oh No GIF

3

It definitely seems to be intermittent. But like with this baq, I can close it and reopen it and the problem persists. Probably have to delete it and start over.

2 Likes
4

I had a similar bug where I copied a subquery, and the criteria were linked between them.

4 Likes
5

you better export it first if you can repro reliably

1 Like
6

So that’s funny. I exported it from live, imported to third, and it lets me set the criteria properly in third.

Epicor should be willing to fix bugs even when they can’t be reproduced reliably.

3 Likes
7

Could not reproduce in live - 2025.2.7 We are cloud. Often with bugs like this, I close or delete the offending BAQ, Dashboard, Event, or widget, then start over. I agree Kinetic sucks. No amount of Epicor begging us to think otherwise will help.

Good Luck!

3 Likes
8

It’s never going to work right. It can’t. “Table criteria” isn’t a thing in SQL, it only exists in BAQ. The only way to do that is to add a subquery and apply subquery criteria in that context before joining the results.

And BAQ doesn’t do that. It hackily shoves “table criteria” into join conditions or the global WHERE conditions, imposing criteria in unexpected contexts. I recommend not using table criteria and intentionally selecting criteria context instead.

  • Add something in a join condition if the join should be constrained.
  • Add it in subquery criteria if the context should be the entire subquery.
  • Filter your table in a subquery if you want to constrain the volume of data before it’s joined. LaborDtl, for example, can benefit from filtering prior to a join.
3 Likes
9

Well, it composes the where clause correctly in classic, just not in kinetic. But I get you, its safer to do it the way you have described.

2 Likes
10

I can tell you why - that came from Progress. Because how E9 queries were executed, suddenly after switch to the new version different result was returned.

2 Likes
11

Kinetic needs to execute a baq the same way that classic does. If it doesn’t, that’s a huge problem.

3 Likes
12

If you import it back into that same system (new name) does it work?

1 Like
13

Yes, it appears either the export or import process is reassigning the guids, not sure which one since I can’t look at it without importing again. ETA: Talking about the original issue. The left join issue remains either way.

2 Likes
14

well attach export here, export does not reassign anything

1 Like
15

This is a new BAQ not a converted BAQ right?

If you export the bad one, then export the good one and run a comparison of them are there any differences outside the system?

1 Like
16

BAQ is executed on the server, regardless of UI version.

1 Like
17

export.baq (7.9 KB)

1 Like
18

But the UI is somehow composing the query differently, so the result is different.

2 Likes
19

Yes new BAQ. Maybe I will do that if I have time.

2 Likes
20

If you save inbetween does it still happen?

1 Like