Epicor/Kinetic Wiki file

Kinetic ERP
1

I like this thought and analogy a lot.

I wonder – and this might exist already – if we all here, or a company or something, could put together the “missing modules” kit for Epicor.

Like, I hate Android, but it is a wildly different experience from my mother-in-law’s cheap old LG phone vs. a Samsung Whatever. There’s a layer of sheen over top the Android base.

But back to the point, we have all made dashboards (BAQs) that saved our lives because Epicor doesn’t compile the info you need or help you monitor for The Things That Will Destroy The Company (missing GL code; settings that affect MRP, etc.). Would it help to have a single repository for those?

I mean, I think that’s probably the intent of the hardly-utilized Code Review category here, but, of course, there’s nothing stopping bad or ugly dashboards from muddying up the pool of useful ones. What a new user would want is like a single group of curators to oversee a single project. (I am not volunteering…)

What I can’t understand is, what is “commonly needed”?

  • Standard-costed parts with a standard of 0.00? I think that would have a use
  • Part master - how are all of our parts set up, std/avg/etc cost for each part, “list price”…
    • But it turns out that “THE list price” is actually not a single number always; you CAN do it that way, or you can assign different base price lists to different customers, etc.
  • Report of customers missing a GL code? That’s OK, if you want it to default to the Company setting, but perhaps bad if you are multi-site and want them to be separate. Or maybe even then you don’t care if they all go to the same account.

These are just some examples, of course.

EDIT: Also, what I sort-of had in mind here is that when I, personally, make a BAQ for a “rule,” it’s myopic. I can only see the needs of this company at this time. “Here are the GL accounts for the parts in our system.” Oh, except that we went multi-site and we flex the “division” segment when transacting. Or I assume fairly static UOMs when some companies use part-specific.

1 Like
2

I will second Mr. McDermott’s motion! Perhaps not quite “Expert’s Corner” but rather more like “Epicor Pickers Storehouse and Museum”, except the found treasures would be free! And I do believe that Jason would be the perfect curator! :wink:

3

That’s all great sentiment, but falls apart once you try to scale up. You’ll “one more thing” yourself into a 15 volume 10GB help file, and have the same problem that you have now. There is the help file, KB Articles, tech guides, this forum, EUG and Epicor Education portal. All with valuable information. The hard part is to know what you don’t know. Once another resource becomes big enough, then it will have the same problem. No one can know if all, and/or it just take years of experience to be able to know enough to be effective.

The secret sauce needed is for someone to be able to take a that information and make it so people can find what they need, without knowing what they need. That’s a pretty tall order.

@Mark_Wonsil in the past worked on a WIKI page for Epicor stuff, I’m not sure how far he made it, but I bet the task grew too large to quickly to truly take off.

And to be clear, this isn’t an Epicor problem. This is an ERP problem. Business is complicated with a lot of moving parts, and any software that tries to tackle that problem will be large with lots of moving parts.

3 Likes
4

Breaking this into a new thread as it’s kind of taken a different turn. Good discussion though.

5

Yup.

But I’ll turn your own words against you: you say there should exist “out of the box functionality that you would find in other products.”

And I honestly 100% agree with both statements.

I don’t know other ERPs, but I sure hear about how much better they were from new employees here (and I find those same people don’t know much about computers and come from a Fortune 500 company that had an IT staff in the dozens or 100’s). But regardless, I think there is real merit in the idea that there are some supposed “common” reports that could be collected.

This might be a good fit for a product to sell, but then I can’t see Epicor saying to new customers, “After you buy our software, you should buy this 3rd party kit that makes Epicor as useful as you were expecting.”

Uh, no. :stuck_out_tongue_closed_eyes:

1 Like
6

Yeah, that’s the hard part… I often think about trying to “sell” pre-packaged BPMs or Customizations or reports, etc., as a consultant, but it rarely works out in practice… everyone always wants their own little tweaks.

3 Likes
7

The key would be to get the configuration into a format that’s amenable to git branch and merge. Then people could pull what they want into their own branch and point some tool at it to set up Epicor in minutes.

1 Like
8

@KevinK You are nominated!

9

We created a public git repository for all these and anything else to be put into and made available. It has sat un-used for years

Everyone (and I’m not picking on you @JasonMcD) wants these wonderful lists and wikis to exists but nobody has the time or is willing to put the effort into creating them, curating them and maintaining them.

Trust me having been running this site for 6+ years it isn’t easy or fun at times to bear that responsibility.

Also as far as what is lacking or not in Epicor every company’s idea of what “Ideal” is is different. For you CRM looks one way and for me it looks a different way, I abhor the concept of storing every piece of communication email phone etc with the customer in the ERP system. It feels akin to hoarding and nobody will ever look at it, I prefer manually curating and calculating what will be stored or flagged in the CRM when its important. But that’s just me, the same applies across the board of functionality.

And yes @KevinK that sounds like an amazing tool that doesn’t exist. Akin to Unicorn poop, sounds delightful but un-realistic

image
image1920×1077 147 KB

2 Likes
10

I have so many thoughts on this based on lessons from EpicWiki but the day job is calling. Will post the thoughts later today.

I get my Unicorn Poop from a nice DevOps store in Ann Arbor called The Unicorn Project. :wink:

3 Likes
11

No, I certainly didn’t take any offense. I don’t really want the list. It’s the “everyone” that does. And as I said (unabashedly hypocritically), I’m not willing to make the list either.

1 Like
12

It’s a nice thought but I think this list of functionality that everyone needs or wants is mythical - in the moment it seems so obvious that x, y, or z are needed, but then you go to a different company and they don’t need any of those things. Epicor will only ever deliver 80% of the functionality you need, at best. That’s how its designed and it’s never going to change. There is very little overlap between companies in the other 20% of the functionality that’s needed. Just look how many ideas on Kinetic Ideas have only 1 vote (and how many different ideas there are). That’s a good demonstration of how different each business is.

I think the frustrating part is that even though the Epicor toolset is quite deep, they push this view that people should use everything “out of the box” and stop customizing so much to make upgrades easier, but you can’t have it both ways! You can’t provide a product that absolutely requires customization to be functional for the vast majority of customers and then make it hard to upgrade the customizations! I haven’t really got into kinetic too much yet but in classic at least the tools to deal with upgrading customizations are sorely lacking and I hope there is some dedicated development focus there going forward.

4 Likes
13

This site is the wiki you are looking for.

@Bart_Elia said it much better a long time ago…

3 Likes
14

Back in the days…


Oh, let the old man talk…

10+ years ago, there were basically two discussion boards for Epicor-related products: The Yahoo!Group and the Epicor Users Group. There were some other sources scattered around the web like the SpiceWorks Forum and individual efforts like Ginger Help. And of course, there was EpicWeb, and now EpicCare.

The thought was:

“Wouldn’t it be helpful if there was an easy way to find Epicor information without having to have to go to each source to get the answer?”

(The other reason I wanted a different site, unlike EpiUsers.help recently, there was strictly no selling or marketing on the the Yahoo!Group or it was pay to play in the EUG. A wiki could also let entrepreneurs hang out a digital shingle.)

The solutions recorded in this place could also link back to the original source(s). Of course, this is what a Wiki does. The software that runs Wikipedia is called MediaWiki and is free. So I took out a domain, epicwiki.com, and got started. I learned a lot about wiki’s and one of things that makes them successful is the ability for anyone to contribute easily. Single-person cultivated wikis rarely survive. The difficult part is providing some structure to the pages to make it easy for everyday users to contribute. This is where EpicWiki crashed. It was somewhat easy to throw a page up there but every page would look different.

So if you go to https://epicwiki.com, you’ll end up here.

But the problem remains. People come here and ask questions that have already been answered multiple times. The search is fine but you still have to comb through threads and maybe somebody even marked a post as a solution. But like @JasonMcD, one is left with the impression that it could be done better.

So, besides a Wiki, where else can we find a user-contributed help repository? One such place is Microsoft Docs. Microsoft uses an open source tool called DocFX. Like this forum, the entries are comprised of Mark Down, albeit a specialize version called DocFX Mark Down. It takes these mark down files along with a table of contents file and builds a static web site. Because one uses headings, etc., you get a built-in document structure. Each page has a site search, a topic index with filter, and a page index. More importantly, there is an Edit link. When you click on the Edit link, it takes you to GitHub where you can make a change and submit it as a pull request. If they approve the change, it starts a build process and republishes the site. In addition to editing directly in GitHub, you can also clone the repo and use some nice Visual Studio Code extensions. There is previewer, an image manager (compresses your images, a link checker, among others. There is even an extension to write your own Microsoft Learn module.

Once the site is built, it just needs to be deployed to a web server somewhere. The good news is we could use GitHub pages to deploy the site. It’s a nice little DevOps example.

When DocFX first appeared a few years ago, I asked @josecgomez if we could get a public GitHub org. And he did. Did I start the project? I did not. Again, the issue is with creating a structure to make it easy for people to add/maintain content. To me, that seems like a group effort. More importantly, any group is smarter than I am. All of Microsoft’s docs are free to browse on GitHub too if we wanted to copy something.

Oh, one other thing we need to do. We need to be careful with Epicor’s (or any other person’s) IP. This is just a true for EpiUsers.help but I wanted to make that clear.

Everything I have written about here is called “conceptual” documentation, in other words, describing things and processes. Where DocFX really shines is that it can read code or a swagger file and generate documentation from that. That’s beyond the scope of what we’re talking about for EpiUsers.help. Don’t get me wrong. It would be really cool to generate documentation for Epicor components (BPMs, Functions, BAQs, Kinetic Screens/MetaFX, etc.) but we have to crawl before we can walk…

4 Likes