Select Page
Much Needed Functionality: Prophet 21’s Rental Management Application

Much Needed Functionality: Prophet 21’s Rental Management Application

To Rent or To Buy – More and More Often, It’s To Rent.

In some ways distribution has not changed over the past 50 years; but in other ways it really has morphed – I know, that statement was non-committal. But take for example product Rental Management. Your customers still want your fantastic product whether that’s cars, industrial equipment, cylinders, furniture, etc. and there is a paper trail to track those rentals and bill appropriately. Unfortunately not many Enterprise Resource Planning (ERP) systems easily track rental products so distributors are forced to look for standalone products and old fashioned paper trails – either way, creating a lot of work arounds or duplication efforts for a company. Epicor recently released a new application for distributors, and I for one, am extremely excited about it.

 

The new Epicor Rentals Management (ERM) solution makes tracking rentals within the Epicor Prophet 21 ERP (P21) simpler and more efficient. ERM handles the actual rental transaction while the P21 application holds all other data like customers, items, accounting, inventory, etc.

 

Prophet 21 (P21) Epicor Rental Management

P21 Rental Management Tracking

Some of the primary benefits of Epicor P21 Rental Management (ERM) are:

  • Efficient Rental Transaction Processing
  • Manages Scheduling and Assignment Processes
  • Flexibility in Pricing Rental Designs
  • Flexibility in Product rentals for day, week, month, mileage, hours used, etc.
  • Simplified contract maintenance
  • Automatic Rental Billing
  • Rental Availability

 

 

What is really nice about the ERM module is that when your customer service or sales team goes to enter in a new rental order, the process is just like any other order in P21 – using the Order Entry Window. With everything setup, the sales associate just enters in the a rental item and P21 switches the order to a Rental Order vs standard Sales Order. Switching to a Rental Order will cause the ERM module to open up and finish the rental processing; with information like state, dates, duration, even serial and lot tracking information.

 

A few of my favorites I’ve seen so far are:

 

Simplified Contract Maintenance

Contracts. Need I say much more before the room starts to groan? Usually contracts are done on paper – sometimes with carbon copies – though often times it’s a matter or printing, signing, and scanning. Thankfully ERM has helped simplify that painful (and let’s face it) rather wasteful process. Within ERM the sales agent can input the data, customer can review the contract and sign for it – making the entire process much simpler. This allows the final contract to be stored electronically with ease, or print or email once finished.

 

 Automatic Rental Billing

The Finance department is going to love this feature. No more grabbing that monthly billing folder / file cabinet / or excel list with customer names and billing frequencies. ERM has automated rental billing which allows finance to set billing intervals and then generate the invoices according to your business schedule.

 

Tracking

Every one loves tracking – dashboards, look up, quick reference, you name it. Having the ability to quickly find the data you need when the customer needs it. The ERM module makes it easy to see rentals by customer, rental product type, etc.

 

Let’s face it, at the end of the day, being a rental business is hard work. Unlike most manufacturers and non-rental distributors – who have little need to track their products once the item has shipped – you need to know who, where, how long, at what price, etc. and then rinse-and-repeat for the next customer. Epicor’s Prophet 21 Rental Management solution solves a large functionality gap for distributors.

 

To end this on a light note; I recently heard a funny rental joke:

 

Why was the mole’s rental fee so costly?

Because he burrowed and never returned

 

Questions or feedback on this article? Wanting more information on Prophet 21 ERP or P21 Rental Management? Let us know in the chat!

The Company You Keep: Deploying Company-Specific Customizations in a Multi-Company Environment

The Company You Keep: Deploying Company-Specific Customizations in a Multi-Company Environment

Setup is crucial for a successful company-specific customization in an Epicor ERP multi-company environment.

Maintenance of the Epicor ERP menu in multi-company environments can be unintuitive, and many customers come to us looking to better understand its capabilities and its limitations.  One area of special frustration is the deployment of customizations in multi-company environments.  Deploying company-specific customizations—especially since ERP version 10.1.600—has been a point of confusion.  Fortunately, once the steps are understood, the act of getting your customizations to the menu becomes less ambiguous, even if a little cumbersome.

 

When creating customizations, you can develop one that is specific to a single company or one that applies to all companies.  Let’s assume you were making a customization of the Epicor ERP Part Maintenance form.  For instance, perhaps you thought the Part Maintenance form would look better with a big green spot:

Let’s also assume you wanted the big-green-spot version deployed only to the company you were working in (in the case below, this would be the “EPIC06” company).  As such, you’ve saved the customization by not setting the “All Companies” flag and allowing the company to remain the one you’ve been working in.  This creates what is called a “company-specific customization”:

Now, deploying this customization to the standard “System” menu is not possible—the customization is not available when you click the “Customization” drop-down in Menu Maintenance:

To deploy the customization to the currently company without affecting all companies, navigate to the “Actions” menu in Menu Maintenance and select “Copy to Current Company”:

When this is done, the application makes a copy of the system menu.  In doing so, the new menu carries over a number of values from the original menu: the Menu ID, the Name, the Security ID, the Parent Menu ID, and even the Order Sequence is carried over.  But a number of key fields change.  The duplicate menu is no longer a System Menu, as it now has a Module type of “UD.”  The menu no longer applies to All Companies, as the owning company is now the company in which it was deployed. 

Most importantly, the “Customization” drop-down now allows you to select the customization that you’ve created:

When deploying a company-specific customization in a multi-company environment, the above steps allow you to create a menu deployment that will replace the system-based menu deployment for the company in question.  To demonstrate this, log out of the application and back in. 

 

As you can see, only a single menu node for the Part form is displayed:

And when this single node is selected, the customized version of the Part form that was previously created (big green spot and all) is displayed:

If, for some reason, you need to revert to the base “System” menu, you can always delete the duplicated menu from Menu Maintenance.

 

The ability to manage company-specific customizations in a multi-company environment is of great importance, especially in environments where companies have vastly differing business requirements and require highly-specific form deployments.  Such capabilities will keep your requirements aligned with your environments and keep you user base in good company.

Have any feedback or questions about customizations?

Historical Transactional Data Conversion: Prevent the Past from Haunting Your Present

Historical Transactional Data Conversion: Prevent the Past from Haunting Your Present

“I give [this watch] to you not that you may remember time, but that you might forget it now and then for a moment and not spend all your breath trying to conquer it. Because no battle is ever won he said. They are not even fought. The field only reveals to man his own folly and despair, and victory is an illusion of philosophers and fools.” – William Faulkner, The Sound and the Fury

 

Living and writing at a time where the legends of the Civil War and the fables of the Reconstruction were still part of living memory, William Faulkner’s work wrestled with the ideas of history, memory, mythology and heritage, and the challenges of one’s immediate existence amid such a monumental backdrop.

 

The notion of contending with one’s history extends far beyond the literary world, and takes a place of eminence within the world of enterprise system implementation.  Almost without exception, I find myself with customers at the onset of Epicor implementation projects working through options regarding how best to address the management of the historical transactional data from their legacy system.  Customers find themselves in a paradoxical situation: customers want to move forward with a new system that can meet their upcoming strategic goals and initiatives, but they also want to be able to reference the rich history that was built up as part of their legacy system.  It is as if they wish to rip all the lathe, plasterwork, and wainscoting off their old home and slap it onto the walls of their new dwelling.  But as any carpenter would attest, the fit of old materials is never perfect.  Often, is it downright shoddy.

Given the challenges of layering the old with the new, I often work with customers to help them understand the perils and promises of their data desires.  I try to find a way to satisfy the company’s history without compromising the new installation in question.  The fundamental challenge has to do with whether a specific company can bring over historical transactional data from their legacy system.  Transactional data may include Quotes, Sales Orders, Purchase Orders, Work Orders, Shipments, Receipts, Invoices, etc.  In going over the options, there are normally three ways in which a company can reference its historical data as part of a new Epicor implementation:

 

  • The transactional data can be converted using Epicor’s Data Management Tool (DMT).  That is, the legacy data can be manipulated to fit into a format conducive to the setup of the Epicor environment and loaded into the database, as if it were a live transaction load.
  • The transactional data can be loaded into Epicor user-defined (UD) tables and references from within the application using BAQs and Dashboards.
  • The legacy database can be connected to the Epicor application using external data source configurations, and then to queries using external BAQs.

 

The primary concern has to do with addressing the desire to actually convert legacy transactional data into Epicor’s database without compromising the historicity of the data itself, and without gumming up the system with a lot of noise.  It’s hard enough to correctly convert live records, much less to convert the mountains of ancient data.  From my own experience and from the experiences of my coworkers, we do not consider it a recommended best practice to convert historical transactional data into Epicor’s standard table structure when implementing Epicor ERP.   The following reasons underlay this recommendation:

  • When implementing or reimplementing, it is often the case that the base setup data values change, in terms of their naming conventions, quantity, values, etc.  This can make the transformation of legacy data labor-intensive and error-prone.
  • ERP data is by its nature integrated.  Loading transactional records can trigger unexpected effects.  For instance, should an Epicor customer elect to import the Purchase Orders from the legacy environment, the system would plan for these POs to be received and alter system planning accordingly.  To avoid this, these records would need to be closed, but the data in question would therefore fail to reflect the original legacy data, in which Purchase Orders were closed through the receiving/invoicing process at a much earlier date.
  • To load transactional data in the form in which it exists in the legacy environment, the entire collection of related records needs to be loaded.  For instance, if a customer wished to have purchase order history, to have representative data in the Epicor environment, the related PO Receipt and AP Invoice records would also need to be included.  This is, among other things, a tremendous amount of work.
  • In some cases, Epicor’s business logic updates fields and does not allow these to be user-updated.  For instance, Sales Order or Purchase Order lines are system-set and not user-modifiable.  This makes it difficult to load historical data that accurately reflects the legacy data: what was PO Line 2 in the legacy system may get converted to PO Line 1, as it was the first line to be loaded.
  • Transactions have general ledger implications.  Loading transactions can thus have unexpected consequences that affect WIP, inventory, and their related GL accounts.  For instance, should the user import Purchase Order Receipt records, the transaction date would not by default reflect the actual date in which the transaction occurred.  Should the customer wish to date the transactions into the past, the necessary fiscal periods would need to be created.  If the load does not include all transactions, the General Ledger would be inaccurate, and would require effort to reconcile and correct.

 

An alternative to performing a DMT table load into the standard tables is the utilization of Epicor UD tables to store this data.  This avoids many of the perils above, but requires the implementing customer to construct querying tools (BAQs and Dashboards) to retrieve and present this information.  Moreover, I’ve found that the actual usage of historical data tends to be less than anticipated.  In many cases, we have found that the actual usage of this data tends to decrease significantly shortly after cutover.  I recently had one customer go to great lengths to convert data to UD tables and construct the necessary querying tools to view the data—only to forget almost entirely about these capabilities amidst the booming buzzing confusion of cutover.  By the time they had settled down, they already had built enough living history into their database to move forward, and the UD tables were all but forgotten.

 

A final option is to access the legacy database using external data source connections and query it using external BAQs.  This option is normally the simplest of the three, as it saves the time of initially converting the data, though it similarly requires the construction of the necessary querying tools to receive and present the data.  Depending on the age and format of the legacy database, the external data source option might not be feasible.  As part of some implementations, I have seen customers convert their legacy databases into SQL format at cutover, for the express purpose of querying their ad hoc history via external BAQs.  In other cases, I’ve seen customers fall back to the UD table option when other options were seen as too labor-intensive.

 

As such, given the other options, I recommend that the conversion of data at cutover be limited to master file and open transactions, and utilize external data source connections to the legacy database, and/or UD table conversion, in order to gain access to historical legacy data.

 

When it comes to the art of crafting prose, William Faulkner forgot more than most of us remember.  Elsewhere in his works, Faulkner wrote that “[t]he past is not dead. It’s not even past.”  In a similar vein, the attempt to bring old historical data into a new ERP system is itself an act of rewriting history.  And in doing so, one sacrifices accuracy for availability.  Also, when implementing a new system, a company quickly learns that the high cost of retaining history is something they would soon like to forget.  As a company builds a new history in its new system, the old history becomes less and less valuable, with such surprising rapidity that the old soon takes its place at the back of the database, taking up space and gathering data dust, like a childhood diary left on a top shelf and forgotten.

 

Do you have questions about the Data Management Tool or best practices for data conversion? Or do you want to talk with the author about anything Epicor related? Chat with us now!

Announcement: EstesGroup Awarded Epicor Managed Hosting Partner Certification

We are proud to announce that EstesGroup is an Epicor Software Corporation Certified Managed Hosting Partner. EstesGroup is certified to host Epicor ERP and host Prophet 21 ERP systems.

 

We are the only Epicor Partner to be Certified for Epicor Hosting, Epicor ERP Sales & Implementations, and Prophet 21 ERP Sales & Implementations.

 

This accreditation means that EstesGroup has met and exceeded Epicor Software Corporation’s rigid data center and expertise capability requirements for being awarded Certified Hosting Partner status. To learn more about these requirements please contact us.

 

“We are honored to be an Epicor-Certified Managed Hosting Partner for Epicor Software Corporation, and the only hosting partner to be certified for Epicor ERP and Prophet 21 ERP systems,” said Bruce Grant, CEO of EstesGroup. “Our company has both functional and technical consultants on staff who know Epicor ERP and Prophet 21 systems.  This means we not only know Managed IT, but we know the industry’s best-practice business processes and the underlying software as well. We provide a full-service solution to fit our clients’ needs.”

 

Epicor Software’s Chief Information Officer Rich Murr said, “Epicor and I would like to congratulate EstesGroup for becoming a Certified Epicor Managed Hosting Partner. EstesGroup has a long history in working with Epicor Software Corporation and our clients as a reseller and implementation consulting organization. Last year they became the first and only US Partner to be certified in Epicor ERP and Prophet 21, and now they achieved Hosting Partner for those products as well. EstesGroup continues to provide clients with a solid foundation of experienced consultants and high level hosting standards. We are looking forward to continued growth and excellent service with the EstesGroup team.”

 

EstesGroup is Certified by Epicor Software Corporation to host and manage clients’ Epicor ERP and Prophet 21 ERP systems. As a Certified Managed Hosting Provider, EstesGroup guarantees better than 99.5% uptime Service Level Agreements (SLAs) for clients’ ERP systems (to see EstesGroup’s 99.7% SLA click here).  EstesGroup is also a Microsoft Cloud Services Partner with SQL Administration, Security Administration, O365, MS Exchange, and Disaster & Recovery expertise.

 

To learn more about EstesGroup’s EstesCloud Epicor Hosting, visit our Epicor ERP Hosting page.

Contact EstesGroup today to learn more about Epicor ERP Hosting or Prophet 21 ERP Hosting.

 

 

 

 

 

About EstesGroup

 

Headquartered in beautiful Loveland Colorado, and established in 2004, EstesGroup (www.estesgrp.com) employees averages 25+ years of discrete manufacturing and distribution industry experience which they leverage to ensure client success. Their employees are spread-out throughout the United States which maximizes talent and local presence for their clients. EstesGroup is a certified reseller, certified implementor, and certified hosting provider for Prophet 21 and Epicor ERP 10. They implement full service cloud, hosted, or on-premise solutions based on client needs and requirements.

 

 

About Epicor Software Corporation

 

Epicor Software Corporation (www.epicor.com) is headquartered in Austin, Texas, and is a manufacturer of Enterprise Resource Planning software solutions. Today, over 20,000 customers in 150 countries around the world rely Epicor’s  expertise and solutions to improve performance and profitability.

 

Epicor and the Epicor logo are trademarks of Epicor Software Corporation, registered in the United States and other countries. Other trademarks used are the property of their respective owners. The product and service offerings depicted in this document are produced by EstesGroup and/or Epicor Software Corporation.