I’ve done this via a subquery and a calculated field, then just join in the subquery (doesn’t need to be a complex one) on company or something and display the calculated field which outputs your constant.
2 Likes
Like a subquery on Company (for the current company) - thus having only 1 record - and then a totally bogus calculated field for the sole purpose of being a constant.
Neat - I hadn’t actually bothered to try that before. That’s going in the memory banks.
But this means you are saying there is indeed no simple way to just set a constant of ThisNumber = 7. Right?
Not to my knowledge, but I bet you could via the use of the “run BPM designer” too to set global execution level variables. I like the subquery approach since it’s easy to maintain your global variables in 1 subquery and those apply wherever you want
You could also link to UserCodes or SysTag. Define your variables there.
Pretty flexible.
For sure. But still a lot of extra steps.
I smell an Epicor Idea brewing.
Wow if that isn’t a setup for a dumpster fire. @josecgomez
Look up 1 post
I do like all the alternate ideas, don’t get me wrong. I’ve put a total of zero effort into this problem before, so I appreciate the advice. Lots of tools for different uses.
But does it not strike anyone as a tad absurd that you can’t have a non-prompting parameter, basically?
Your subquery can contain only calc fields.
1 Like
I was going to add a #dumpster-fire tag to this thread, but apparently I can’t go past 10 characters? Oh well.
You don’t even need to bring a table. Just make a calculated field, fill in a value, and you will get one row.
1 Like
I meant to test if that’s what @klincecum was meaning earlier.
No kidding. I did not know that. It makes no sense to me, so I never tried it.
Very nice. Seems like the least bloated option.
1 Like
I just used a single level for an example, but no reason you couldn’t make it a subquery. Or even just leave the calculated field in your top level. You’ll just have an extra column. You can ignore that.
Oh, OK. But you can’t now call that variable* in 4 other subqueries, right?
*I know, it’s not really a variable
You might have to play with the syntax, but you should be able to. If you are using it in different levels, you might have to do level.field to get it to work.
Worst case, you just drop the sub query into whatever level you need it. Then it should be available. (you don’t need to join it)
1 Like
Mmm, ok. I learned not to do that long ago with real tables.
- If you have table/subquery A with 5 rows,
- And you add in table B with 3 rows
- And you do not join table B to anything
- Result set now has 15 rows
Of course, I usually make that mistake with tables that have thousands of rows. Oh what fun that is.
But I guess if the MyVariable subquery has 1 row, then Z x 1 = Z
So I guess that’s why it’s OK?
I feel like the Calculated Field with a static variable is easy enough and I’ve used that for things that I am controlling. But I thought the question was more about getting a value from a table, storing that value as a variable, and then using it multiple places in a BAQ so that you didn’t have to always join that table/create a subquery. His original question referenced getting some setting out of Company Config. Of course you could hard code those values into a calculated field, but that wasn’t the original intent. @JasonMcD correct me if I’m wrong.