I’ve been working with the Made2Manage product for well over a decade and the single biggest complaint I hear about it is that customers can’t get data out of it. The most common complaints I hear are:
- The included reports are too limiting and inadequate for most companies.
- The database is a Visual FoxPro/SQL hybrid and the supported reporting method is VFP which is an abomination before God.
- The database has confusing table and field names. The field names are inconsistent between tables; fpartrev, fcpartrev, frev all represent the same value. Some field names are blatantly wrong, ARITEM.fshipqty is actually the quantity invoiced, not shipped.
- The same data is duplicated in many tables and it’s difficult to know which field you should select.
- M2M report exports (Excel) are difficult to use. The field names are exported directly from the database so you must replace them with English each time (fsono with Sales Order Number). Also, because of the way the Visual FoxPro code is written, many fields from reports will NOT export, so you are stuck editing the VFP code to add them.
- The database lacks primary and foreign keys so reporting systems have no idea how to link the tables. Most often the wizard will link them on the identity_column fields in all tables and this is incorrect.
- The systems that M2M has in place to assist users with writing report code, namely the Data Dictionary and CTRL-F1 field help, are confusing, incomplete, and inaccurate.
- M2M lacks any supported way of archiving your Sales Order Backlog, Inventory Evaluation, or Work In Progress data just to name a few. Therefore, you are stuck in Excel Hell with manual periodic exports if you want to perform any kind of historical analysis.
- Consona offers additional add-on products to facilitate reporting, but they are expensive and are still not easy enough for most users to use.
- If you own FastForms, another add-on product, none of the currently available report options automatically account for that data. This can cause you a ridiculous amount of work adding them to each and every VFP report.
A Simple Example
Keep in mind that I’ve only included a few fields in each table to keep things simple. However, the average user’s eyes glass over when you show them even this simple example. Now, let’s add some possible links to the diagram.
Some issues immediately come to mind.
- Do you know why UTTerms is in red? It’s a Visual FoxPro table and beyond most users’ ability to retrieve, or they hard code the descriptions in the SQL script.
- Can you remember the difference between fenumber and finumber? Think your accountant can? Dream on.
- Is Fsoldby the same field as fsalespn? If so, should you pull it from somast or slcdpm?
- What about Product Class and Group Code? Should you pull them from inmast or soitem? What’s with the inprod table? Many don’t use it and people simply have to memorize the 2 character product class codes instead.
The Bottom Line
What does all this add up to? Money. Companies must either hire a sql server/reporting expert, pay for additional reporting software, suffer without critical information, or endure Excel Hell.
Sure, you can use SQL Server Reporting Services for free (if you are on SQL 2005+), but without someone who knows how to write SQL code and understands the specifics of the M2M database, what good is it? It’s the same problem using ODBC connections with Excel or PowerPivot. If you can’t write the code to import the data correctly, you’re out of luck.
What is the solution to this problem? Well, I’ve been working on this project for almost two years. The project will address all of the issues listed above and more. And no, contrary to rumors it does not involve simply adding cubes or views on top of the normal M2M Database.
I’ve received tons of questions. What is it? Is it a new reporting product? What operating/SQL systems will it require? How will users access it? Will it support all M2M versions? What will it cost?
I promise to finally answer all of these questions tomorrow.