Hi, the only other off the shelve i know of is parttrap.
Depending on the industry and the market the whole digitisation piece is already massive
Anyone here using ECC or Magento? Seems like everyone built from scratch!
@enbw - Thanks. I hadn’t heard of PartTrap before. Are you using it?
@TomAlexander - Thank you. We’d like to avoid ServiceConnect due to the babysitting part! I’m OK with outside dev’s or the CSG group helping us get up and running, but we want to own & understand it for future improvements (aka control our own destiny).
@Aaron_Moreng , @josecgomez, @Mark_Wonsil, @Evan_Purdy - Thank you. Our WebSphere handles the ecommerce fine, but it’s not friendly to have non-developers update the website. We’re hoping ECC or Magento would allow normal folks to do it (add/remove parts, images, links, sync with E10, etc. If we did REST from scratch, we’d also need to design a front end UI for ease of use, and I think then it might be simpler to go right to ECC. We just don’t have the bandwidth to do that in a reasonable amount of time.
I think that epicor change their pricing from company revenue to the revenue through ecc. I think that was around 6 to 8 months ago. They have recently offered more attractive propositions. I think it is definitely a weakness of the epicor ecosystem. For example there are lots of third parties offering ecommerce solutions for NAV etc.
1 Like
@askulte - Ag Leader use Storefront from Part Trap for our dealer network to place their orders online. We don’t take many email or phone order anymore, it’s all done online.
@askulte - Absolutely; ownership and understanding is huge. Just make sure that understanding doesn’t end up only living in your head or the next guy will have an awful time trying to maintain it… (speaking as the “next guy”).
Documentation is key, but even when integrations are well documented in the beginning, I think most of us would admit that we don’t do a good job keeping up with maintaining the documentation when changes are made over time. Then you have a bad situation where the documents are saying different things than what the code is actually doing – and that can almost be worse than no documentation at all for newcomers to the codebase.
This could be a whole thread (or book) in itself, but IMHO the best documentation for these things is
- A simple one page map of where any custom code lives / when it executes (if, say, it’s tied to a schedule)
- Clear understandable code where any developer can open it up and understand what it’s doing at a high level just by skimming through it. Nothing’s worse for a codebase newcomer than having to intensely study code line by line to get the faintest grasp on what it’s doing. There are plenty of good design / coding patterns that many people on this site know a whole lot more about than I do, but in my experience with ERP custom code there are two things that have killed me more than anything:
-
Bad names!!! Naming things is a fine art. You don’t have to be Michelangelo, but if you are a 6 year old with a box of crayons, people will suffer.
-
Vestigial / obsolete code serving no actual purpose. It’s truly infuriating spending a bunch of time figuring out what a method or function does, only to realize that it is never actually called anywhere. There’s arguments to be made about preserving history and understanding how code used to work in the past, but at least put it in comments at the end of the script if you’re not willing to delete it.
Sorry for the unsolicited rant… 
2 Likes
Firstly, 25 points for using the word vestigial.
Source Code repositories are for tracking history. < …cough… > DevOps < … cough … >
2 Likes
On the configurator note, i dont know how well parttrap does but it does have some nice features. For example, if it applies, you can have a pdf of an assembly. An exploded view of many parts and you can click on it and order the part for example. Ecc may be able to do this
On a more generic note, anything published to the web you really a developer that knows security inside out and third parties. Third parties to protect you, whether a service like cloudfare and someone to test it.
Doing a diy on iis server in the wild is not advisable.
1 Like
We’ve been talking about implementing a repository / version control system for a while now. Most products out there feel like overkill for us though. Do you recommend anything in particular that is a good fit for ERP system customization / maintenance / integrations, etc.?
In DevOps, source control is the beginning of everything. If you need to repeat something then you need to remember how to do it. People are storing their infrastructure code (ARM templates, PowerShell Desired State Configurations, etc.) in Source Control. Obviously program code is stored in Source Control. Git is the most popular. Services like GitLab and GitHub have added a lot of automation around Git, most importantly web hooks. So now, when a file is checked in, actions can kick off. This includes automated testing, building deployment artifacts, approval, and even deployment.
My Epicor Idea suggestion asks Epicor to make exporting/importing all the Epicor things friendlier to Git - this includes BPMs, Customizations, Functions, BAQs, Configurators, Electronic Interfaces, RDDs, and even DMT files and system settings! Now when a field is renamed or split into multiple fields, it’s really easy to see what it affects. For upgrades, it’s easier to know what has changed and a history of the changes you made, who did them, when they happened, when they were installed.
If you lose a system or somebody copies over your dev system, what happens to your code? Gone.
Need to prove to an auditor you have control of the ERP system???
Keeping things in source control alleviates these issues. Just as we don’t(shouldn’t) make direct changes to our databases, maybe we shouldn’t make direct configuration/code changes to our systems either.
1 Like