Epicor Archives - Page 7 of 23

Paying the Piper in Epicor E10, Kinetic & Prophet 21

by Brad Feakes | Oct 18, 2021 | Distribution, Epicor, Epicor 10, Epicor Kinetic, ERP, Prophet 21

Best Practices for Paying Supplier Invoices in Epicor ERP

There are many challenges when it comes to paying supplier invoices in Epicor E10, Epicor Kinetic (E11), or in Epicor Prophet 21. In simple terms, a company purchases goods from a supplier according to pre-established and carefully-specified terms. In most cases, a company needs to pay them within the specified terms, waiting as long as possible, as to keep the cash flow within the confines of the company’s banking system for as long as possible.

But the payment must not be so late as to incur the wrath of the supplier and avoid the inconveniences that credit hold will place on subsequent purchases. And the company may elect to take advantage of an early payment discount, if one exists.

Sounds simple enough. But a company also must ensure that invoices are accurate. The amount invoiced must correspond to the quantities that were actually delivered. Some many-to-one complexities muddle the water a bit, given that a supplier invoice may cover several purchase orders and that each PO could be dozens or even hundreds of lines in length.

Supplier Invoices Epicor Kinetic ERP Cloud

Automating the Three-Way Matching Process

At this point, we haven’t even begun to validate the amount that was on the original purchase order. Such is the magic of the three-way match: cross-referencing the information that was on the PO with the information on the receipt and matching both of these with the invoice from the supplier.

The matching process differs by company, as many companies have different rules and tolerances that govern the matching process. This can make the process laborious and time consuming for accounts payable staff, and it’s not uncommon for many accounting departments to spend inordinate amounts of time matching invoices and cutting checks for routine purchases.

Given that the three-way matching process is largely mechanical in nature, one would think that it could be automated. But what would it look like for a system to perform some of the heavy lifting, allowing your AP staff to focus on the critical few problems, without having to grind thought the invoices that went through without a hitch?

Firstly, the system would need to read the invoice. It would need to read and digitize supplier invoices, whether they’re sent as PDFs Word documents, or in some other format.
Secondly, it would need to validate the invoice. It would need to review the past POs and match the invoice lines with the corresponding PO lines, whether they come from multiple Purchase Orders or a single PO.
Thirdly, they’d need to perform the three-way match. Using the rules that your company has configured, the system would need to compare line items from the purchase order, the invoice, and the actual receipt of goods.
Finally, the system would need to generate payment vouchers with the click of a button.

The benefits of such a system should be self-evident. Automation works to secure your supplier relationship, while minimizing invested time and effort. Moreover, such a system would be the kind of repetitive and rigorous data-driven analytical work that computers are made to do:

Processing matched invoices
Kicking out exceptions

Automation allows skilled staff to focus on the real work, not the grunt work.

Are you in search of such a solution? Our supply chain automation partner SourceDay will be presenting a webinar entitled “3-Way Matching Success Through AP Automation” with Epicor ERP software solutions expert Jim Frye.

The webinar will focus on the final stage of the purchase order process: paying supplier invoices. Anyone who’s navigated the perils of accounts payables in Epicor knows the burden of matching purchase orders and invoices. There has to be a better way!

Join Epicor ERP expert Jim Frye to learn how SourceDay helps Epicor customers reduce the time and effort it takes to pay supplier invoices, resulting in early payment discounts, efficiency gains, and hard cost savings. The webinar will cover the following:

The challenges of paying supplier invoices in Epicor
The measurable benefits of faster invoice payment
How to increase operational efficiency and automation

Learn more about Epicor software by attending an EstesGroup Summit! Whether you’re a small business or a global manufacturer or distributor, our world-class enterprise resource planning (ERP) consultants can help you with everything from raw materials management to ERP cloud migration. Our Epicor consulting team can help you move from the paper based systems of the past to the cloud based applications of the future.

BRAD FEAKES

SVP or Professional Services

EstesGroup

TALK TO BRAD

JIM FRYE

Enterprise Sales Director & In-House Epicor ERP Expert

SourceDay

TALK TO JIM

PHILLIP PAVELKA

Solutions Engineer

SourceDay

TALK TO PHILLIP

Leveraging Union Queries in Epicor Kinetic BAQs

by Brad Feakes | Oct 13, 2021 | Epicor, Epicor 10, Epicor Kinetic, ERP Consulting, ERP Implementation

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.

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:

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:

SubQuery3 is also a Union subquery that returns data from the PODetail and PORel tables:

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:

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:

Need help with Epicor Kinetic BAQs?

Ask us about BAQs now

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

Meet us at the EstesGroup Kinetic Summit!

Scaling Up & Scaling Out in a P21 Ecosystem

by Brad Feakes | Oct 11, 2021 | Cloud, Epicor, ERP, Hosting, Prophet 21

P21 System Performance in Accordance

When deploying any enterprise-level application such as Epicor’s Prophet 21 ERP, system performance is an extremely important consideration, one that can have significant impact on the successful use of the application. Memory allocation, transaction logging, network connections and a litany of other factors can affect the user community’s experience of the application. Failures in any one of these areas can bring an application to a grinding halt. This is certainly the case in a P21 environment.

As such, the work of a P21 administrator is critical in the successful deployment and maintenance of the Prophet 21 ecosystem.

While the successful administration of a P21 environment will differ on several factors, such as the version installed, the presence of a middleware server, the use of terminal services, and the use of the legacy desktop application, the actions taken to attain, maintain, and sustain a P21 ecosystem can be summarized by the two following principles:

Scaling Up: Stacking up resources onto a single existing server, user terminal, network, or device to allow it to perform better and bear additional load.
Scaling Out: Branching out by breaking out additional servers, terminals, network connections or devices to improve the capacity and capability of the overall P21 infrastructure.

Scaling up in a Prophet 21 Ecosystem

Scaling up involves the addition of resources, most often to a server, to address issues with usage and performance. In many cases, the performance of a single server, whether it is an application server, a database server or a user terminal, can be improved by identifying the problem in question and judiciously allocating some additional resources, such as RAM, CPU, or storage.

Let’s use the Prophet 21 desktop application as an example. The architecture of the legacy desktop application was such that a single desktop client generally consumed one entire CPU when in use. This creates a challenge for terminal services, given that two users logged into the same terminal server cannot share the same CPU, as is the case with other applications.

To address this, system administrators need to “scale up” and add CPUs to the terminal server, to allow multiple users to work from it in parallel. This is of course easier to do when the computer is virtualized, so admins will want to consider this should they have the need to build out a remote desktop for their user community. Depending on the number of users in your company, such an approach to your P21 environment may be satisfactory.

With the shift from the legacy P21 desktop application to the P21 middleware server, the concern with scale similarly shifts. Scaling up under the modern architecture now involves the resources allocated to a given middleware server to allow it to handle heavier loads. Even here, it is not uncommon that companies encounter scaling issues with the P21 middleware server, as the company grows. In many cases, the answer is not to scale up, but to scale out.

Scaling out in a Prophet 21 Ecosystem

Using the example of the Prophet 21 desktop application, a company can scale up a single remote desktop so high before the additional building blocks no longer elevate its cause. In the case of a remote desktop, a single terminal server can support approximately 12 CPUs to support roughly 15 users working in parallel—any further and the platform begins to bend under the weight of its own design.

In this case, it is preferable to spin up a separate P21 terminal server to support additional user requirements, and to integrate the multiple servers with a broker to create a server farm.

A similar but updated concern relates to Epicor’s middleware application server layer, and the number of users it can support. As with the development of a Prophet 21 server farm for remote desktops, the need might arise to create a load-balanced farm of Prophet 21 middleware servers, in order to meet user needs.

The shift from a 2-tiered architecture, in which the fat client speaks directly to the database to a 3-tiered architecture, where the thin client speaks to the middleware server naturally shifts much of the heavy lifting from the traditional desktop client to the P21 middleware server itself.

Again, the specifications are ambiguous, but we’ve found that often a single Prophet 21 middleware server can be scaled up such that it will support roughly 50 concurrent users before the server can no longer perform any additional heavy lifting. In these cases, it is preferable to build out a new Prophet 21 middleware server in a load-balanced environment.

P21 Economies of Scale

In practice, helping users often involves some combination of scaling up and scaling out. It begins with an understanding of the scope and limitations of the Prophet 21 architecture and an understanding of the size of the user community and their needs. From there, the combinations and permutations become an intriguing and multifaceted challenge for the P21 administrator to circumnavigate.

LEARN WHAT TO DO WHEN YOUR VENDOR OFFERS SAAS ERP

Prophet 21 E-Commerce Integration Tips

by Brad Feakes | Sep 8, 2021 | Distribution, Epicor, ERP, ERP Implementation, Prophet 21

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! Chat with us now to schedule a free consultation with a P21 expert!

Custom Cloud: Public Cloud Choices, SaaS Challenges

by Brad Feakes | Jul 8, 2021 | Cloud, Epicor, ERP, ERP Implementation, Prophet 21, Software

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.

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

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.

[pardot-form id=”3091″ title=”ECHO Demo Request”]

Prophet 21 Event: Servers, Financials & Supply Chains

by Brad Feakes | Jun 14, 2021 | Cloud, Distribution, Epicor, ERP, Hosting, Prophet 21

With summer in full swing, distributors are on the move, crossing docks, splitting shipments, and delivering goods by the truckload to a diverse array of customers. It is a time for expansion—of old trade routes of supply chains and of new opportunities as our reopening country rediscovers its possibilities.

Female Attending a Virtual Epicor Prophet 21 Event

Attend a 2021 Prophet 21 event in person or online

With user conferences back in the schedule for 2021, P21 users are highly anticipating the Prophet 21 user conference P21WWUG CONNECT in mid-August. This event serves as a focal point for the P21 user community and as a bookend for a busy summer. At the onset of the summer season, we thought it would be helpful to host our P21 summer summit as a prelude to the larger Prophet 21 community event. This also gives you the opportunity to open the summer with some new ideas for using your P21 application to its fullest capabilities.

Events like this are a great opportunity to review your application’s capabilities and find ways to improve internal processes, discover ways to reduce costs, and reveal methods to improve information flow and presentation. You’ll also surface steps you can take to better integrate Prophet 21 with suppliers and customers.

Our summer 2021 Prophet 21® event takes place on June 24, from 10:00 AM to 1:30 PM (Central Time). Three panelists will discuss topics pertinent to the P21® user community. The event is free, and all are welcome! This summit will also provide an insider’s view of the Epicor Prophet 21® solution for any distributor who is looking for growth opportunities that only a new software can provide.

Prophet 21 Event Itinerary

Server Best Practices for the Epicor P21 Environment

10 AM – 11 AM (CST)

Daryl Sirota, Executive Director of Technical Services at EstesGroup, will discuss server best practices for P21. Understanding the optimal means for deploying the Prophet 21 application has never been more important, especially with Epicor’s move to a new client-server architecture. Daryl will discuss some of the key considerations when deploying and maintaining your server stack. Daryl leverages 35+ years of IT experience to help customers develop server and cloud architectures that are robust, flexible and reliable. A veteran systems engineer and Microsoft expert, Daryl provides the stable technical foundations that allow customers to focus on their business. Attend this Prophet 21 event if you’d like to know how to create a private cloud for your ERP software.

Creating Financial Statements Using Financial Line Express

11 AM – Noon (CST)

Terri Gage, Senior Consultant at EstesGroup, will discuss the creation of Financial Statements. P21 customers express frustration in successfully creating financial statements, but the often forgotten Financial Line Express can bring ample help to your financial reporting needs. A longtime project manager, implementation consultant, and Prophet 21 specialist, Terri works with organizations to help them successfully implement and fully benefit from the P21 application, actualizing their goals of sustained profitability and business excellence.

Bridging the Gap Between Epicor and Suppliers for Distribution Companies

12:00 PM – 1:00 PM (CST)

Jim Frye, Enterprise Sales Director at SourceDay, will discuss how distribution companies bridge the gap between their Prophet 21 system and their supply chains. Distributors need to do many things to help secure their supply chains as the ground shifts beneath them, automating the mundane and improving collaboration, visibility, and accountability between them and their varied suppliers. Jim leverages 30+ years of experience working with Global Manufacturing Companies, big and small. His passion is to help organizations facilitate growth, reduce operating costs, and increase profitability through supply chain efficiency.

Our event concludes with an open Q&A session, allowing users to raise questions regarding the sessions themselves and the Prophet 21 application in general. Operations management strategies. Cloud server integration steps. Cloud hosting service risks. Prophet 21 cloud platform options. Global supply chain trends. Operation system updates. Dedicated servers, multiple servers, SaaS… from Prophet 21 consulting to server hosting, we have answers to your P21 ERP and IT questions.

Do you have questions you’ve been meaning to ask a consultant, but haven’t wanted to shell out the cash?

Now is your chance to do it–on our time and our dime!

Epicor’s Prophet 21 user community is founded on collaboration.

Come collaborate with us on June 24.

This event can also help distributors who are considering a new enterprise resource planning (ERP) software.