During a recent ERP selection, we have had the pleasure of looking at several different systems for a local client. But today, I want to share a few of our high-level observations of Epicor. Epicor is consistently coming in at almost double the price point of the other ERP systems that are normally considered for a business of this size. The "problem" is that Epicor is consistenly twice as good. First, each of the other ERP systems lacks one or two key modules -- e.g. payroll, maintenance, or purchasing. When you subtract the price of those modules from Epicor or add the price of a third-party add-on to the other ERP, the price is closer to competitive. Then, you consider how much work the folks at Epicor have put into making the software usable (the other vendors have not kept pace) and you have to add a "time saved" factor to the price of the software. We have seen that the Epicor designers have not rested. They are constantly releasing improvements and we can say that -- mostly in usability, but sometimes even in function -- their software compares well even with players like JDEdwards and SAP. For lack of time, we shan't go into more details, but it wouldn't surprise me if Epicor stay in this game despite their high price. If they can bring it down just a touch, they may win the game. The point -- for your future selection efforts, it may pay to consider Epicor.
We at Deft Flux have been using Ruby on Rails for a new web site. We are developing a web site that will help inspectors of homes and businesses do their jobs better and easier. The site will automate the communications between the inspection requesters, the inspection managers, and the inspectors and make information transfer reliable. But back to Ruby on Rails. After using the Ruby language and the Rails framework for a couple of months now, we are in love. The Ruby language is terse; it is powerful. What else could you ask for? The Rails framework makes it easy tie your object oriented application into your relational database of choice. Moreover, Rails automates your database migrations when you upgrade your application so that you don't accidentally bollix things.
We understand that some commercial languages (e.g. .NET and ColdFusion) and PHP are implementing frameworks like Rails. We are stoked that Ruby on Rails is amongst the pioneers and that the power of the language makes it a pleasure to use.
I know since we posted the JDE date to real date function, everyone has been wondering where the real date to JDE date function is. Well, "ask and you shall receive."
As long as we are discussing JD Edwards running on DB/2. Here's another potentially useful function. This one converts a value from one unit of measure to another based on the F41002 table. It does this by converting the FromUOM to the primary UOM and thence to the ToUOM.
During nine years of blackguarding the J. D. Edwards date format (also known as JDate, also misnamed Julian Date), I have resisted learning to write DB/2 stored procedures because the need to use them while developing OneWorld applications is minimal and OneWorld is the only context in which I have encountered DB/2. Well, I have finally encountered that special confluence of necessity and available time that produces a tool -- in this case a function. I broke down, I learned, and I wrote that JDate to DB/2 Date function. Here is that code, in case you should find it useful:
We here at Deft Flux have always preferred Unix style operating systems and commands to Microsoft. The problem was that our clients always use Microsoft operating systems and until recently, it was always too much of a hassle to get gnu utilities up and running on a Microsoft workstation, especially when you're moving to a new one every few months. Well, since the good folks at gnu started compiling programs for windows and providing installation programs (to cover dependancies), we decided every workstation needs gnu utilities. First, we install gvim because it is the best text editor ever written. Then we install grep, core utilities, and finally sed. Thus we have assembled, on a Microsoft workstation, a group of what are arguably the most useful programs ever written, pound for pound.
If you have ever used the JDEdwards cross-reference facility in an attempt to find where a certain table column is used, you understand that it can be difficult, especially when the alias for your column is common.
Let's say you have a custom table [F550001] that has a column [URRF], and you need to find all programs that use the F550001.URRF. Well, you may have 50 custom programs that use F550001 and there may be 250 programs, native and custom, that use the alias URRF. You can see the difficulty in searching through 50 programs to find 5 that reference F550001.URRF.
If, however, you take the 50 custom programs that reference F550001 and export them to the spreadsheet program of your choice and then export the 250 programs that reference the URRF to another spreadsheet, you can filter the 50 references to F550001 down to only those programs that also reference URRF. Now, you still may have a few extra programs in your list -- programs that don't reference F550001.URRF -- but you now have a much smaller list to work from.
Hello world. Deft Flux is now a real company.