Here is my new favorite idea that came in from a customer. This is the type of improvement that can make a difference. It doesn’t add new functionality, but makes the functionality that we already have easier to access.
Unified Shipping Entry Screen
(if you agree… please vote for this)
7 Likes
including Customer, Drop, Master Pack, Miscellaneous, Subcontractor, and Transfer shipments
Just chewing on permissions.
I guess that any user that does one can/should/will do any/all of those?
Part Entry is the opposite problem: way too many diverse disciplines controlled by a single app. (Revisions for Engineering, buyers/suppliers for purchasing, manufacturing lot sizes for production, country of origin for shipments, etc.)
And the time phase parameters thing was an odd mashup of read-only and editing for all.
5 Likes
Security and Convenience are natural enemies.
4 Likes
yup… and in my EPIC, i have already addressed the fact that each of these separate functions still need to have role based security around each one. ALSO, I am running all ideas through an AI Analyzer that helps us judge possible problems (IF i had done this with the removal of Landing Pages from the Part screen, we would have taken a second look)… Here are the risks around this idea:
Idea Validation & Risk Analysis
Why might this fail?
- Consolidation may introduce performance or complexity challenges due to very different underlying shipment logic types.
- Users accustomed to the old screens may resist adopting a new UI.
What assumptions am I making?
- All shipment types share enough common workflow elements to justify consolidation.
- A unified screen will be intuitive rather than overwhelming.
- Underlying services can be standardized without major refactoring.
What would a skeptic say?
- “This is too big; you’re merging six specialized screens into one and could create a bloated UI.”
- “Training might not decrease if the unified screen becomes more complex.”
What if only some customers want this, but others strongly do not?
- Some customers may prefer the simplicity of the current, separated screens.
- This could be mitigated by allowing the legacy screens to remain available or by configurable user roles.
What financial risks are there?
- High development and testing cost due to the broad scope.
- Potential disruption to critical outbound shipping operations if not thoroughly validated.
- Carrier integration dependencies may evolve, requiring ongoing investment.
1 Like
Guess I’m a skeptic 
as this was my first thought, “We’ll have to retrain everyone who does these tasks and work to ensure they select the correct type when doing their entry.”
3 Likes
I am not seeing the value proposition of this idea. You need different reference information, and to complete different steps, for each different type of shipment. Far from reducing complexity, attempting to combine interaction with all those different datasets and business objects into a single UI seems like a recipe for massively INCREASED complexity. Now shipping teams will be even more confused, more training will be needed, it will be easier to mess up and enter the wrong thing in the wrong place.
On top of that, all existing custom workflows will have to be redesigned/rebuilt placing a huge development burden on anybody who has customized these. I don’t know anybody who has an appetite for redoing EVER MORE customizations after having to have already redone (or in the process of redoing) everything from crystal to SSRS and classic to kinetic.
Why would Epicor even entertain something like this when there are so many desperately needed improvements languishing in ideas with many many votes? Why would something like this get fast tracked? Can we get the ability to vote against ideas in the ideas site so we can down vote things we don’t want Epicor to waste development hours on?
4 Likes
Oh, yeah, I didn’t think about customizations plus our ebiz (CC processing) and Quick Ship modules either. 
I see where there are disagreements… but if our shipping program had always been unified, i believe that there would not be friction here…
- every shipment has things in common
- a demand (sales order, transfer order, outside processing, etc)
- a ship to address
- a list of parts that need to be shipped against that
- a packslip that needs to be printed showing the contents of the box, where it is coming from, where it is going, shipping methods, etc.
I think that the request was about the fact that if you are in shipping and the fulfillment workbench sent the item to be picked, it would be easy to simply go in and find the next picked item, create the packslip, print the shipping label, and ship it… to the person doing the shipping, they are doing a shipment, and it doesn’t matter that one is a sales order, and the other is a transfer order… same results to that person.
From that point, the process does re-branch out… sales orders need invoiced, etc. but again, the act of shipping is the same in most cases.
BUT this is why we have Epicor Ideas… so we can get feedback and comments. AND this is why we use AI to help us find the possible conflicts to support all possible use cases and gotchas.
Also note that we should continue to keep discussions like this open and not harsh. there are already 11 different organizations that have voted FOR this feature. I know that in my decades of implementing the software, i almost always got the question “why is shipping done in so many apps?”.
Sorry, that is not an option with the Aha platform, but you CAN add comments (like you and one other person already did) to the idea. we do read the comments.
we also take into consideration what customizations this might cause problems for…
OH.. and we have NOT fastracked this. I just thought it was a good idea since i had it requested in person so many times. we are still awaiting votes. There is no Epic Created yet.
1 Like
I’d be worried about these integrations too. Eeek
1 Like
Excellent.
Yes! Epicor (the company) needs more of this thinking. There are a lot of odd/poor design choices from seemingly decades ago, and it is OK to fix them now. It will be difficult and hurt or break other things, but it is worth it.
I think the PO suggestion merge was a good step forward also. I had many purchasing users over the years say, “There are CHANGE suggestions, too?!”
Also, I don’t see why you couldn’t have the unified screen AND the individual ones coexisting for a few years. Pick which one you want to use… or which to prevent users from seeing.
1 Like
I can see the thought behind this, it would be annoying if each PO type had its own screen.
Another good illustration of how its a lot easier to do things the right way the first time around instead of changing them in the future. Hope the kinetic team puts lots of thought into things before adding them, so you aren’t facing more of this situations 2 years down the road.
While I think this idea makes sense, I see it as a nice little UI optimization, which I can’t vote for in good conscience when there are so many other things that are so broken. Maybe later when Kinetic is a little more usable.
2 Likes
I agree it would be different if it had been that way from the beginning but . . . We are where we are. Those aren’t good analogies, suggestions and pos are both the same type of data in the same or similar tables. If you understand epicor data structures, you know that each type of shipment has a completely different data structure. And its never ok to break the software to add new features.
There’s bigger fish to fry right now.
2 Likes
I’m not sure that breaking something as critical as shipping is “worth it”.
1 Like
@aosemwengie1 brings up a good point about data structure. @timshuwy , would you be combining the tables or leaving them be? I know you may not know at this point, just wondering.
3 Likes
Like I say, I don’t think you have to break it - just give both options.
I cannot imagine that the intent is to change the tables. Rather just to give multiple tabs for the various kinds of shipment - like the PO Suggestions app is.
And to be clear, those are different tables for new and change PO suggestions.
I get you all are aggravated about Kinetic, etc., but I don’t think it’s fair to think in terms of “Things are broken, so nothing new or fun can happen until those are fixed.”
A coworker and I were reflecting this morning about the changes in our plant here over the last several years.
- The shop floor (the non-office space) was an utter mess 3 years ago; since then it has been fully revamped for much better production and material flow.
- BUT ALSO, they redid the break room and offices and lobby.
- Historically we looked at production as the only thing that mattered.
- But employee happiness (and impressing visiting customers) is equally necessary.
If you lose sight of that, your company will slowly die.
Likewise, yes fix bugs in Kinetic, but also improve the usability.
1 Like
So we lose the landing pages then? Or it becomes like inspection processing where its loading 5 kinds of data at once and takes forever to load? I don’t see how that is any kind of improvement.
2 Likes
Speaking for myself only, this makes sense if the difference in priority isn’t that great, or if the resources for one thing don’t affect the resources for another. There should absolutely be a level of triage. I see no reason why devs working on adding AI features couldn’t be working on things that are totally broken for example.
I really don’t care how many features my car has if it won’t even run.
But yes, working on more than one thing at a time is certainly needed and a good idea in some situations. Spreading yourself thin when core features are still struggling.. 
Just my point of view.
4 Likes