Select Page
Leveraging Union Queries in Epicor Kinetic BAQs

Leveraging Union Queries in Epicor Kinetic BAQs

BAQs — Becoming One Data

A fundamental value of your Epicor ERP system is the data that it holds — all that data sits there, nicely organized and begging for consumption. But good data needs to be converted into information to be of value. As such, getting good data out of your ERP system is key. Often, it takes a good query to perform that information transformation. A Union query is one tool in the Epicor BAQ toolbox that can perform this action.

Data Server Epicor BAQs
Within the Epicor Business activity query toolset, Union queries combine multiple data sources into a single results set. Union queries are a great way to combine data from different tables that are, for whatever reason, sufficiently similar as to combine them into a single dataset. Some examples might include:

  • You are using the project module and wish to combine project phases and project tasks into one single set of activities
  • You are tracking the completion of manufactured parts in a mixed mode environment, and need to merge the Job Assembly and Job Material tables
  • You are reviewing sales activity for a customer and wish to combine open orders and open quotes

The UNION command in some ways functions like a JOIN command. It is used to select related information from two related tables. The biggest difference is in how the two tables are related and returned. A JOIN returns multiple table data elements combined into a single row, while with the UNION command, the records from different tables are returned as separate rows. It’s important to note the following: because records from different tables are being combined into a single set of rows, the rows returned need to be of the same data type. We will spell this out further below.

Let’s look at the attached Epicor BAQ example and better understand the UNION command in an Epicor business activity query.

The following query combines three sets of supply-side data into a single dataset:

  • Purchase Orders
  • Jobs
  • Inventory
SubQuery1 is the top-level query. It pulls data from the PartBin and PlantWhse tables:
Epicor SubQuery1
SubQuery2 is a Union query, from the JobPart and JobHead tables. Note: the data types are organized in the same order as the top-level query:
Epicor Kinetic SubQuery2
SubQuery3 is also a Union subquery that returns data from the PODetail and PORel tables:
Epicor Kinetic SubQuery3
Note: UNION command requires all selected columns to be of the same data type. If these returned values are not of the same type, you will receive error messages, per the screenshot below:
Epicor Kinetic Union Command
The value of Union queries is far-reaching. For example, the above query can then be used in a job shortage dashboard, such as the one below. In the following dashboard, the main query returns all past-due job material records where the material’s related operations have been started, but the material has not been issued. The main query published out the material part number, such that the child query can subscribe to this value and present the collected supply for the part in question, whether coming from inventory, from a job, or from a purchase order:
Epicor Kinetic Job

Need help with Epicor Kinetic BAQs?

Epicor Kinetic User Summit Fall 2021

Like BAQs? Looking for more Epicor Kinetic tips and tricks?

Meet us at the EstesGroup Kinetic Summit!

ERP Culture & Digital Transformation

ERP Culture & Digital Transformation

Who says you have no culture?

Eric Kimberling and the team at Third Stage Consulting serve as thought leaders in the digital transformation community, helping customers through software selection, change management, system implementation, and the integration of technology and business. Their “Transformation Ground Control” podcast series engages the larger business and technology communities to address various topics related to business strategy and digital transformation. Recently, I was able to sit down with Eric and discuss a topic that had become quite important to me in the field of ERP implementation — ERP culture.

ERP Culture Businessman using a computer to document management for ERP. Enterprise resource planning concept.

What is ERP culture?

In our discussion, I defined “ERP Culture” as the set of attributes or characteristics of the company’s overall business culture that support or inhibit the successful implementation of an ERP system. Over the course of an hour, we covered several of these attributes and how they apply to a given implementation.

This topic formed organically enough — I had recently worked with two companies that had gone live on an ERP system within a similar timeframe. The two companies had a number of striking similarities:

  • The two companies were of similar size.
  • Both companies were privately-owned, family businesses, headquartered in the same state.
  • The firms both worked in roughly-analogous market environments, providing products of comparable complexity.
  • Both companies were coming from antiquated, 40-year-old business systems.
  • They were implementing the same ERP system and using the same system integrator.
  • The companies had similar project budgets and similar core team contributions.

The two companies had so many similarities, and yet one implementation was a ringing success and the other was a frustrating mess. In trying to perform forensics to understand just why one implementation was successful and the other a failure, I began to wonder whether the differences between the two projects were due to the significant differences in the cultural makeup of the two companies. 

Having once worked in the area of Lean Six Sigma, the idea of “Lean Culture” had been well documented — the notion that a successful implementation of Lean methodologies was highly contingent on the culture of the organization. I tend to think that the same applies to the ERP community: that the success of an ERP implementation rests heavily on the cultural foundation of the implementing organization. That said, what are the elements that comprise the company’s cultural foundation?

ERP Culture & Digital Transformation

Clarity of Focus

Successful companies are constantly separating wheat from chaff — separating key initiatives from tertiary activities. They tend to be good at taking initiatives to their successful conclusion. They are good at avoiding distractions. In the words of Jack Welsh, they “pick a direction and implement like hell.” And when and ERP project occurs, they becomes the primary focus of the organization, and other initiatives get put on hold. Unsuccessful companies tend to be distracted by shiny objects and this distractibility infects their implementation projects.

Attention to Detail

Successful companies are process-oriented — they understand the importance of specific activities and are not prone to “skipping steps.” At times they are methodical to a fault. This is especially the case when you compare them to “cowboy companies” — companies that play it “fast and loose” in their daily business lives. In the execution of an ERP system, these tendencies quickly become evident, especially when implementing ERP functionality such as labor time entry and inventory management. Successful companies take great pride in the cleanliness of the data involved in these processes. Less successful companies tend to let their data devolve into chaos. And you can never successfully implement ERP from a foundation of chaotic data. 

Preparation

Initiatives such as an ERP implementation are not unfamiliar to successful companies, as such companies tend to plan out initiatives before they do them. They understand the value of a plan and its execution. Unsuccessful companies operate like a headless chicken — lots of activity, but very little direction. The value of such a tendency is self-evident: companies that don’t plan to get to a certain point rarely get there. 

Empowerment

The term “empowerment” generally elicits eye rolls in the manufacturing community, as it sounds like something you’d hear in a mandatory diversity training seminar. If I were to give the term a more rigorous operational definition, I would describe it as the tendency to clearly define individuals’ areas of responsibility, making them accountable for clear outcomes in those areas, and providing them the resources and autonomy to achieve those outcomes. Unsuccessful companies tend to have a domineering management style, where a few “alpha dogs” fight over decisions, while the rest of the organization resembles an army of chronically depressed lemmings. A fundamental tenant of implementing Lean is the ability for teams to define the processes in their areas of responsibility. Such is the same in an ERP system, where configuration decisions can greatly impact process performance. Such a monumental task requires a team of individuals that have the responsibility, accountability, and support to see it though. 

Proactivity

By nature, successful companies are proactive — they are perpetually looking to understand how the chess game plays out. The tendency to look ahead imbues the sometimes tedious steps of an ERP project with a degree of value that is easy to neglect. Such companies tend to be quick to solicit and receive feedback. Proactive cultures also tend to be quick to have honest conversations of the state of a project, when things are not going as planned. Such candor is not a mere complaining — it is the willingness to be accountable for uncomfortable circumstances. The opposite of these tendencies is passivity. In a passive organization, individuals might have trepidation or concerns about a given issue, but lack the proactive tendencies to get ahead of these concerns and bring them to the surface

Sense of Ownership

Ownership is the flipside of empowerment. Highly-empowered employees tend to develop a strong sense of ownership. They are not looking to have things done for them — they’re looking to understand the intended outcomes of a given task and take ownership of them. These are the best kinds of team members to have on an ERP project, as they are self-motivated and are constantly looking to move the ball forward. It’s a question of push vs pull:  I’ve had project managers on projects where the team had a lack of ownership, describe the initiative as “pulling teeth” — they were perpetually having to drag the team along. This is generally an indication of ownership issues. 

Cross-Functionality

Companies vary considerably in the degree to which they encourage their employees to understand the overall company processes, outside of their individual silos. Successful companies tend to have a greater degree of cross-functionality then their unsuccessful counterparts. They recognize the value of understanding an organization from front to back.  As a result, their team members are not content to just understand their own small areas of the map — they want to know the whole thing. One of the great outcomes of an ERP project is the level of cross-functionality that it affords.

Cultural Tendencies & ERP Success

An early mentor of mine once told me that an implementation is equal parts technical and cultural, and if you neglect the cultural, you’ll never achieve the technical endpoint that you desire. My life in ERP has proven this maxim time and again. ERP projects are never easy. But if a company lacks some basic cultural tendencies to support a successful implementation, they will find themselves struggling to achieve their lofty goals.

Prophet 21 E-Commerce Integration Tips

Prophet 21 E-Commerce Integration Tips

E-Commerce is Drawing Interest from Epicor Prophet 21 Users

Trend lines are never a function of simple math. As much as I’d like my world around me to conform to the simple y=mx+b along a clean Cartesian plane, the world around me thinks otherwise. Life, they say, is non-Euclidean. I would surmise it is also non-Cartesian. So, what does this have to do with Prophet 21 e-commerce integrations?

E-Commerce Distribution Industry Prophet 21 ERP Software

Prophet 21 Trends

A trend of the distribution industry that hit me especially hard at the recent P21WWUG CONNECT 2021 event was the proliferation of e-commerce as a subject of interest, as a pressing concern for members of the distribution ERP community and for solution providers working to narrow the gap between the capabilities of the industry and the changing needs of the market.

E-Commerce Solutions Flow From Online Trends

This should really be no surprise—as soon as the World Wide Web became commonplace in offices and households, the possibilities of virtual commerce enamored businesses and consumers. As such, e-commerce has been a pervading topic for companies, as they try to take advantage of these possibilities. 

 

If a trend-line is a topography, then the recent changes to the landscape have been a shift from a steady incline to a fever pitch.

Distribution Industry, P21 & E-Commerce Challenges

The obstacles to traditional procurement such as labor shortages, delivery schedule changes, shipping land congestion, and limits to brick-and-mortar acquisition that have been prevalent over 2020 and 2021 necessitated an increasing emphasis in e-commerce strategies. These strategies needed to support a type of acquisition and delivery that was quicker, more granular, more flexible, and more reactive to the world around us.

This new emphasis has certainly affected the Prophet 21 distribution community. Distributors are diverging in multiple directions, with working both to satisfy the needs of B2B customers, while also opening up their product directly to consumers through B2C opportunities. On this note, Ryan Horvath of Ripen recently offered some helpful points to consider when approaching a P21 e-commerce integration.

Processes: A successful e-commerce platform must support solid business processes. Before you build out your e-commerce solution, make sure to understand the business processes that they enable.

Platform: There are many idiosyncrasies to a given e-commerce platform, which differentiate one platform from another. Understand these differences before you pick one.

Resources: E-commerce solutions require resources to build, configure, deploy, and maintain.  These resources can be internal or external. Before you begin, build a resource plan to support the creation and support of the e-commerce platform.

Scalability: As I noted above, we are in a period of rapid and radical upheaval. As such, the solution with which you go live may need to shift, scale, or otherwise morph as the needs of the market change. Make sure you’re building a solution that can handle such needs.

Ownership: The ownership of data, solutions, intellectual content, and transaction history may shift, depending on how the solution is licensed and deployed. Consider what you own and what you are giving up, prior to selecting a solution.

Long-Term Cost: Cost is an important consideration, as the cost to maintain the solution can erode into the profitability of the transactions it handles. Consider the long-term costs of your solution before you pick one.

Do you need help with your Prophet 21 E-Commerce Integration?

Ripen is an EstesGroup e-commerce partner, offering digital transformations that drive growth and strengthen brand loyalty. Ask us your e-commerce questions by filling out the form below or chatting with us now. EstesGroup offers enterprise resource planning (ERP) solutions and technology services to manufacturing and distribution companies. Prophet 21 hosting solutions and services bring P21 users into the secure and affordable infrastructure of a private cloud.

 

 

Begin an e-commerce P21 conversation today!

Sometimes privacy settings prevent you from seeing our “Ask Us” form. If you don’t see a form, please chat with us now. (Even if you see the form, chat with us! We love to talk Prophet 21 with everyone!)

ROI of ERP: Software Money Games & Executive Moves

ROI of ERP: Software Money Games & Executive Moves

Once you calculate ROI (return on investment) of ERP software and determine that a new system will result in new profitability, the most important step appears: your software selection decision. But who should make this final and most important decision about the future of your organization? 

Every business has a minimum expected return on investment (ROI) of ERP projects. They have some threshold that allows a potential investment, whether in software or another asset, to even be considered. It takes a balanced software project leadership team to determine if a vendor is providing an enterprise solution that will ultimately result in solid ROI. 

Imaginative visual of business people and financial firms staff. Concept of human resources, ROI of ERP, enterprise resource planning ERP and digital technology

Who are key players and who are “extras” in your ROI journey?

Software implementation team: 

An enterprise-level software implementation is complex and takes a strong pool of talent. ERP (Enterprise Resource Software) implementation poses high risk to your business if your team doesn’t execute projects with exactitude.

External stakeholders:

We live in an outsourcing world and third-party solutions build external networks of trustworthy stakeholders. Advisory boards and partnered firms will be affected by your software of choice, so be sure to entertain their insight in selection decisions. 

Fellow CEOs, CIOs, CXOs, and the like, might have nuanced experience that will give you valuable insight into how a new system will change your company culture. Deployment decisions can also affect external stakeholders. If you move to the cloud, will your new infrastructure support your third-party integrations?

Internal support and project management teams: 

Don’t simply play “follow the leader” when it comes to software management. Choose the talent that matches the task, and build a team that works well together. A complete software implementation can take years with all configurations and customizations in consideration and can significantly alter every aspect of your culture. Deploy a team that could handle any ERP deployment necessary, and your project will be a success. 

IT experts – internal or external:

EstesGroup assists clients on a daily basis with seemingly “simple” technology decisions. In the ever-changing cyber landscape of ever-increasing cybersecurity threats, it’s critical that the people informing your software project leadership team are highly skilled at both soft IT skills and “hard” hardware skills like cloud migration and data center relationship management. Tech-savvy consultants tend to be gifted at ROI calculations. They can help ensure that your initial investment results in cash flow.

The inclusion of IT experts is especially pressing in an increasingly cloud-centric world in which consumption-based modeling can save you thousands upon thousands of both dollars and hours. Make sure to not only consider current infrastructure needs, but also entertain how technology could change. Will the vendor alter your software and force change? Consider Epicor’s Prophet 21 new client architecture updates of 2021 as an example of vendor interference. 

Cloud experts and cloud migration experts:

Even if you choose an on-premise solution, it’s important to get a cloud migration analysis, assessment, and report. Make sure your software selection and implementation teams understand the differences between public cloud and private cloud deployments. Choose the best platform for your future needs, even if investments costs run higher than your ERP software budget had pencilled in. Project plans should adapt to new information. A few extra dollars now for a high rate of return later most likely won’t break your ROI formula.

Independent enterprise resource planning consultants:

It’s important to find someone who isn’t vested in the software vendor and can therefore give an impartial review of your business needs. Enterprise resource planning software firms are everywhere. Look for one with excellent customer relationships. Testimonials are your best bet for understanding the team members you’ll add by bringing in an IT or ERP consulting firm to help in your software selection process.

Who will complete your system analysis?

You and your software implementation team have analyzed the data and prepared your findings. Now you must make a presentation to your executives for a decision. Regardless of the findings in your analysis, the decision must be made at the executive level. They know this software acquisition is under consideration. Even if the return on investment is low, let the executives make the decision.

Their choice might be to ask for further analysis or more data and the analysis returns to your group. They could ask for some reduction in cost from the software providers or possibly a review of whether some costs could be deferred. At the end, they will let you know whether to request the final purchase documentation or to let your contacts at the software provider know you have chosen not to go forward.

Who will determine executive support?

This executive decision is probably required by the rules your business follows and only this group is authorized to make significant financial decisions. There are practical values, too. If you move on to acquire your software, there will be stresses on people and resources and resistance to change. Unless your executive team fully supports the changes required, you will not have the full support of others in departments and functions around your enterprise.

When you get the go-ahead from your executive team, more work is ahead of you and your team. Begin that work with some communication. Let your employees know the decision was made and tell what will begin to happen. You will start forming work teams. Your expected completion date is some approximate future time. 

Between now and then there is a rough outline of work to accomplish, and you know everyone will do their part because there are benefits for all. It can be helpful to make a list of those benefits.

Who will predict and measure ERP implementation success?

  • Is the software a good fit for your business?
  • Are your current business processes ready for change, or are you in need of a business process review?
  • If the software is complex, like Epicor Kinetic or Prophet 21, do you have an implementation plan that will guarantee good ROI?
  • Do you need legal advice to help you negotiate a solid contract with your software vendor?

Cold hard IT fact: In the current climate of Internet of Things (IoT), one of our contacts was hacked through his refrigerator. The ROI of ERP implementation can quickly diminish when ransomware infects your system.

Is your cybersecurity solution protecting your remote workers from their toasters? Sign up for a free technology assessment with Chris Koplar, our cloud & technology expert, today.

 

Custom Cloud: Public Cloud Choices, SaaS Challenges

Custom Cloud: Public Cloud Choices, SaaS Challenges

What to Do When ERP Turns SaaS

I once sat in at a sales conference for an ERP vendor and listened as the CEO explained sales strategy as it related to their ongoing movement to the cloud. He described the situation as one of configurability vs. customizability. There were some customers who could live with and work within the configurable features and capabilities of the base application as they existed “out-of-the-box.” These customers would be targets for the vendors single-tenant and multi-tenant cloud (or SaaS) offerings. For the subset of customers whose needs extended beyond the system’s base configuration, and were in need of custom functionality and integrations, the vendor would still offer the traditional perpetual license. This would allow customers with more complex needs to deploy their applications on-premise or in a private cloud.

ERP Public Cloud Software as a Service

That was the CEO’s perspective. Customers have their own perspective. 

Configuration & Customization to Order

I recently talked with a customer who was struggling to implement the cloud version of an ERP to the vendor’s public cloud. The customer had purchased the software based on a set of assumptions, assumptions that were not instantiated by the vendor’s public cloud (or SaaS) platform. For one, the customer had come from a highly customized in-house suite of applications, and had a highly developer-centric approach to application implementation: if the app didn’t do what you need, customize it so that it would do what you need.

This approach is anathema to ERP implementations in general, and as a customer implementing on a public cloud SaaS platform, the shock was only intensified. The customization toolset to which they believed themselves to be privy to was less than advertised. And the documentation that explained just what was and was not possible was all but nonexistent. As the customer put it, his team’s vast C# skillset went largely underutilized.

Frustrations abounded on all fronts. Creating the necessary reports and labels, whether through Bartender or SSRS had been a disaster, as both the licensing and underlying architecture made for an untenable situation. Development and deployment of new solutions was cumbersome and time-consuming, as it required the vendor to perform the deployment every time a change was made. Similarly, the approved third-party applications that they had purchased in conjunction with the base package didn’t integrate as well as advertised, and they turned out to be even less configurable than the base ERP system.

Worse still, the customer was a user of the ERP’s product configurator module. This mode was itself a mini-development platform, but its features were largely server-side and thus greatly hampered in the vendor’s SaaS platform. The ability to use the module to look up and retrieve data, for instance, was greatly limited on the SaaS architecture, and the customer struggled to construct configurators to handle their complex product needs. Beyond functionality, the overall performance of the application was a drag. For many customers, the move from whip-fast, green-screen legacy platform to a contemporary ERP brings an unfortunate surprise when it comes to basic performance at a user interaction level. But in this case, it was magnified by the performance of the underlying cloud platform.

It was a disheartening conversation and I struggled to offer suggestions, outside of a reimplementation under a perpetual license model. The strange thing was that the customer did not really even come to me looking for help. He was really just venting his frustrations. He had learned enough of the application, its architecture, and the Service-as-a-Software (SaaS) deployment model to know that whatever help he might receive, he was constrained by the architecture to which he had bound himself. The cloud, whose name implies boundless opportunity and possibility, had become a crippling constraint.  

Different ERP systems provide different levels of configurability and customizability. Some systems offer a basic platform with robust tools to use to build custom functionality with which to tailor the base platform. Others provide extensive configurability, as to avoid the need for additional tailoring. The systems that best combine configurability and customizability capabilities stand the best chance of supporting the needs of complex organizations. Even still, the unbridled requirements of a given company can often exceed the combined abilities of an ERP system to handle it.

This may necessitate the need for third-party integrations, to atone for liabilities in the base system. It may require integration to a pre-existing home-grown system, to address the specific needs of the organization. In the most extreme of cases, customers may look to modify the system’s source code to make the system do what it needs. At some point, it should be considered whether such extreme measures justify the investment in ERP at all. Sometimes it is simply a cultural conundrum: if an organization is unable to bend some of its needs to the will of the application, they may truly be better off with a homegrown system, and live with the liabilities that come with such a decision. 

DRaaS for SaaS: When the Public Cloud Vendor Needs to Adapt

Beyond configurability and customizability, the questions of functionality and integration as they relate to an ERP system’s deployment model complicate matters further. The textbook cases regarding ERP customization nightmares from the 1990s all occurred within an on-premise context. The evolution of cloud computing had not yet thrown this new variable into the mix. But with the improvement of server processing power, the expansion of data centers, and the ability to pass larger and larger amounts of data over networks, ERP vendors were able to construct ERP applications that conformed to the public cloud software-as-a-service (SaaS) deployment model.

This shift toward a SaaS model allowed for highly available and highly scalable ERP solutions, whose subscription-based model provided ERP services for a monthly rate. But in doing so, the features and capabilities that these vendors offered were often scaled back significantly, when compared to their on-premise, perpetual license predecessors. Similarly, the integration capabilities of such platforms were drastically reduced to the web APIs that the ERP SaaS platform supported. This made the extension of the application’s capabilities much more difficult to achieve. For customers needing robust and expansive ERP functionality, as was the case with my customer above, the results of a mismatch between business requirements, customization tendencies, and deployment models can lead to a perfect storm of failure and disillusion. 

How does one avoid such a problematic situation? To begin with, there are some key questions to answer at the time of software selection before you’ve signed the dotted line:

  • Firstly, you need to understand the background of your own organization. Are you coming from a standard system or from a highly-tailored home-grown system? Are your business requirements of the variety that are commonly managed by a packaged system? Is the shift from your current system to the future system a small shuffle or a quantum leap?
  • You also need to understand your own expectations for the new system: are you trying to fit your organization into the system, or are you trying to tailor the system to fit your business? Do you see an ERP system as a packaged application or a custom development platform? Companies differ in this approach, and this greatly affects how they intend to use the system, so you need to be explicit about your expectations.
  • Finally, it should be noted that in many cases, a software’s public cloud version will differ markedly in functionality from its cloud cousin. As such, be careful to understand the version from which the Sales Engineers are basing their demonstrations. If you’re looking at a cloud deployment, ensure that the sales team demonstrates the application, as you will experience it as a customer, and not the products more robust, on-premise version.

Cloud services are as unique as business processes, and SaaS companies / SaaS, or public cloud, applications aren’t always as “internet connection, web browser, go” like they’re often advertised to be.

If your corporate office is mandating some form of “cloud” solution, understand that not all clouds are created equal. A system’s deployment mode is not as simple as choosing between an on-premise dinosaur and a public cloud popsicle. One significant alternative to the SaaS vs on-premise dichotomy is a private cloud deployment. Private cloud allows an ERP customer to install an on-premise, perpetual license version of the software, but in a virtual cloud environment. This allows customers to leverage the full set of capabilities, functionality, and integration opportunities that the software offers. For customers bent on heavy tailoring and customization, this allows them to leverage the full set of tools tailor the application to the customer’s specific needs. Further still, this model makes integrations much easier, as it provides access to the application and database server layers, as needed, which can greatly simplify integration architectures. 

Cloud Customs of Custom Code

A company’s implementation story should be neither a laughable comedy nor a disheartening tragedy. With planning and discretion, companies can formulate a successful narrative. Are you in search of an ERP story with a happy ending? Talk to us, and we’ll spin you a yarn.

You can consolidate everything from software licensing and updates to hardware inventory management with EstesCloud Managed Application Hosting. We offer custom solutions for web-based transactions. We might not be famous like Amazon web services, but our private cloud, hybrid cloud, IaaS, and PaaS solutions offer you the personal attention of world-class IT and ERP consultants.

ERP Deployment Options & Cloud Services

Infrastructure as a Service

Platform as a Service

Software as a Service

IT Management Models

In pure form, a public cloud deployment limits your control and troubles cybersecurity and compliance management efforts. Know your enterprise resource planning options before you deploy. The cloud should be one of your most powerful tools as you move your company forward. But cloud computing terminology is hazy, and cloud migration can be a step backward if the deployment model isn’t a good fit. Do you understand your cloud options? Our cloud ERP experts can walk you through the cloud spectrum and help you find the best platform for your business. When a complex ERP like Epicor’s Prophet 21 is going through client-server architecture changes, EstesGroup consultants are here to answer questions so that you can focus on your business, rather than on its supporting software.

Feeling the pressure to upgrade your ERP system to a new SaaS version? Know your options before you commit to the public cloud. Get a free demo and consultation with our cloud experts today.

Understanding the New Client Architecture of Prophet 21

Understanding the New Client Architecture of Prophet 21

Software development never stands still. I remember a time where I felt like I had finally come to understand DataSets, DataTables, DataRows and DataViews, only to have a much more experienced developer inform me that the System.Data namespace was old, antiquated, and no longer used in the development of cutting-edge applications. I had walked the prescribed trail, only to realize that it dead-ended in a software swamp.

Epicor Prophet 21 Warehouse Worker

The implications of such rapid movements in application development are significant, as software vendors often find themselves down similar dead ends and are forced to backtrack their way out of them. I liken software applications to my great-grandaddy’s venerable old axe: two new heads and seven new handles later, yet still seen by everyone in the family as the same axe.

Like the axe, Epicor’s Prophet 21 ERP application has been refitted over time. P21 helps distribution companies with a variety of features and capabilities. But like many such applications, the vendor found that over time, there was a need to reshape the application as to better position it for future use. Limitations to the existing architecture could not support the long-term needs of the industry. For that reason, Epicor has been reworking and fine-tuning its P21 architecture, moving towards a more scalable, interoperable and accessible application. Understanding where P21 has been and where it’s going can be of great use for customers, as to help them chart a course for the future. 

The Old Prophet 21

Epicor’s E10 application followed an infrastructure that separated the user client, the application server, and the database itself. For someone coming from Epicor 10, P21’s original architecture might look a little strange. Traditionally, P21 employed a fat client architecture, in which a large amount of business logic was housed in the 32-bit client itself, and this client communicated with the database. A liability of this approach was the difficulty in deploying a full API that could be accessed externally. Also, this model created natural limits to the number of clients that could share a single terminal server, due to the size and scope of the fat client.

The New Epicor Model

As Epicor sought to develop a more robust and accessible platform, changes were made both to the client and the overall architecture. Epicor’s updated architecture inserted a new layer, referred to as the “Middleware Server,” that serves as an intermediary between the client and the database, and provides the foundation for API-level interactions. 

Logic that had previously resided in the “fat client” desktop version was moved into the middleware layer. This architecture more closely resembles Epicor’s E10 application server-based architecture. Communication with the middleware server occurs using Secure Socket Layer (SSL) protocol. This allows you to connect without the need for direct access to the network or a VPN connection. A web connection and an SSL certificate are all you need.

Beyond the API benefits, another benefit of this approach comes from performance, as the middleware server supports as much as twice as many clients as can be supported by a terminal server with the traditional fat client. For customers with high user counts, Prophet 21’s new architecture supports multiple load-balanced middleware servers.

Client Types: Understanding Your New P21 Options

From a client interaction perspective, two new options were developed to support the new architecture:

  • Web Client: The web client is a browser-based capability, allowing customers to access their system from a PC, a tablet or a mobile device.
  • Hybrid Client: The hybrid client meets the needs of customers who like the look and feel of a traditional desktop application, but wish to leverage the capabilities and features of the updated web client. The hybrid client installs like a normal Windows application, and connects directly to the middleware server, without the use of a browser.

Desktop Client – A Line in the Sand

Initially, Epicor’s web client lacked some of the functionality available with the traditional client, making things like DynaChange screen modifications difficult to accomplish without a traditional client. But as Epicor ramped up the capabilities of the web client, these differences have fallen off, such that as of spring of 2021, new P21 features will be available only in the web and hybrid clients. 

Epicor will slowly migrate away from traditional desktop application. By the fall 0f 2021, Epicor will no longer develop and release new versions of the desktop client. By the end of the year, Epicor will no longer release fixes for the desktop client. For P21 customers, this will require all users to migrate to the new architecture, both to retain support and to capitalize on the benefits of the newer releases.

The bottom line for P21 customers is clear: they can migrate to the new architecture or else work on the legacy platform, in an unimproved and unsupported state. In making this move, there are a few additional considerations to be made relative to the Prophet 21 deployment options available.

SaaS or Private Cloud Hosting for Epicor P21 Applications

Customers may opt to choose Epicor’s SaaS solution and place their application under Epicor’s control. This amounts to making two significant shifts, and many customers may not be sufficiently confident in Epicor’s SaaS solution to make the move. For customers suspect of SaaS, but looking for cloud options to host their new P21 architecture, private cloud hosting for ERP combines the new architecture with P21’s full functionality, without the hardware investments that come with an on-premise install.

Do you need help understanding your P21 deployment options? Do you need help migrating your existing architecture to take advantage of Epicor’s new features and capabilities? Give us a call — we are the #1 Prophet 21 consultancy in the nation, and we’d love to make you our “client”!

Warehouse & Inventory Management

Are you a wholesale distributor and planning for new P21 features and capabilities? Please take our survey as a step towards understanding the new client architecture of Prophet 21 and how it relates to your future!