Frideas! - 2/21/2025

Frideas
Designed by Freepik.com

On Friday, it’s EpiUsers Frideas Day! Have you been to the Epicor Ideas Portal recently? If so, are there some ideas you want to encourage other users to vote for? Maybe want to add comments to an existing idea?

Just realized this wasn’t kicked off yet for the week (maybe we’re all exhausted from last week’s intended love-fest turned roast :rofl:).

If you have some fresh ones, post 'em up!

5 Likes

Finally! Been waiting hours for somebody to post this lol. Here is my idea. I understand I probably haven’t explained it very well so if anyone else can improve this or articulate it better please do.
Move bpm code to function maintenance and keep in classic aka power tools

Basically what I want is this, but for functions (screenshot from automation studio):
image

8 Likes

I was just getting ready to start a thread. :rofl:

Not mine but:
Reduce Clicks to Add New Part Rev - KIN-I-6084

Stock Status by Bin KIN-I-6078

1 Like

I personally love how Automation Studio does this also. But forgive my ignorance on this one.

Wouldn’t just the “Invoke Function” widget do the same, at least for the “Trigger from an app”?

I know it would still require a BPM even though its may be just a condition and trigger widget. Which may be what you are trying to avoid?

Sounds cool, just want to understand it more :slight_smile:

1 Like

Yes but I don’t want to have separate bpms - that’s kind of the whole point. Why shouldn’t we have the same ide for all our code? Why are there three separate places? It would be so much more manageable to have all the code in one place.

On top of that, the kinetic bpm designer is not usable. Epicor has already conveyed that functions maintenance will remain in a classic type interface via some “power tools” app. I want to essentially keep the bpm functionality available in that same interface by combining it all together because I literally cannot write a bpm in the new designer.

6 Likes

I whole heartedly agree! Wanted to make sure that was the intent. You have my vote on this!

Would be nice to see this go hand in hand with Mark W’s idea that has been “Gauging Interest” for ages. Make the software more friendly for DevOps Practices for Customers, the Cloud Team, and Professional Services

We desperately need all of our code in one place to actually have some decent DevOps practices.

4 Likes

Just read through you idea. Unfortunately I have yet to use Automation Studio, so I don’t have any experience with the interface. But I do agree the Kinetic BPM designer (which is basically just wearing an Application Studio skin) is very tough to use.

I treat it like the Kinetic BAQ designer and try to avoid it (when all possible) until the Classic sunset forces my hand.

But I do agree with your idea of pulling all of these customization utilities into one place.

7 Likes

Add capability to categorize BAQ queries | Epicor Ideas Portal

My Excel sheet is dark and full of terrors.

We are finding it increasingly difficult to manage BAQs and track where they are used and am hoping for the Group functionality to be extended to BAQ. If Group isn’t the answer, then at least provide a way to categorize/ organize BAQs without having to associate them with security codes.

3 Likes

Have you played with Data Tags?

Right mouse click and choose Tag Record:
image

Assign personal or Shared Tags:
image

And then you can search by tag.

Works in classic BAQ Designer but at least in 2024.1, I wasn’t able to tag the BAQ in the browser.

Tags work on most key fields: BAQ ID, PartNum, OrderNum, etc.

Tags can be set or removed via directives. Might give you a start to an idea.

4 Likes

I find the names have to be rather short too, I’ve tried prepending group/category names to my BAQ’s and then you have so few characters left to work with :frowning:

If you put a Key Word of your choosing in BAQ description, you can use that to help search. For example, I always add “CTE” to the description of any BAQ that use CTE queries.

In that case, primarily because I suck at CTE queries and I always have to refer back to previous work to figure out how the heck I ever got it to work the last time :rofl:

6 Likes

Never once crossed our minds … :slight_smile: that may just work, thank you

1 Like

I want to re-post this one from Banderson.
https://epicor.ideas.aha.io/ideas/KIN-I-5955
We use shift select a lot in E10, would hate to loose it in Kinetic.

But also, why can you shift select in some windows and not others? :thinking:
This is from the fulfillment workbench search… but try this in the actual fulfillment workbench? No dice.
fulfillment-workbench

3 Likes

This is an example of Kinetic gaps vs Classic that should be addressed before Classic sunsets @timshuwy

8 Likes

Make the QuoteHed and QuoteDtl Void field actually do something

Not a big need, but one of those times I ask myself, why doesn’t it already work this way?

I am fairly sure that this idea has been delivered, but it has not been marked as delivered. It was a tools thing in the UI that had to be added before we could use it in the apps. I believe that was delivered in App Studio in 2024.2

1 Like

So what you are proposing a central leap off point to maintain all of the development capabilities of Kinetic…

Why not add the rest as well?

Still seeing quite a few posts with the old URL in the links.

Please can we ensure that we are using the updated URL…

The URL is (and it’s in the first post)

https://epicor.ideas.aha.io/

Don’t really want to create an Idea for this but, @timshuwy but it would be great to be able to see a list of ideas with the number of votes. date created, date delivered, status and (possibly version first released) on the Epicor Ideas portal.

I would be a great way to show everyone the success (or not) of the Epicor Ideas portal… Personally I think it’s been a great adjunct particularly since the 50 vote limit was removed, although it would be great for bit more visibility.

Thanks

2 Likes

Sure, it is all server side code, but data directives, method directives, and Functions are different entities and it makes complete sense to me why they are separate screens. Just think about the varying palette of widgets you get in each type… Maybe I’m just extra pessimistic today but I don’t think shoe-horning everything together into one interface would go well at all. The Epicor devs are probably having a nervous breakdown just thinking about it… :slightly_smiling_face:

Is this the real issue here? I haven’t tried it yet… I’m scared to look now :worried: Is it just buggy? Or still far away from classic parity?

2 Likes