>As a consultant, I started working with the MM Framework about 2.5 years ago on a rather large project in a one-man shop. We moved from a FoxPro for DOS to a VFP OO paradigm. (Not easy.) Included in this time was the implementation of Rational Rose, Requisite Pro, custom and third-party development tools, IDE enhancements, and capturing the requirements. In addition, a number of intermediate class enhancements were developed, including a number of touch screen controls.
>
>New management now has the project is under extremely close scrutiny. One of the questions raised was, "Did I know of any projects that had been delivered using the MM Framework?"
>
>I would appreciate your success stories using the MMF to develop software currently in production, especially large projects. I would also be interested in some of the travails that you experienced.
>
>Thank you.


Paul,
I'm a one man shop as well. I've been using the framework for about 2 years (October 1999.) One of my projects is a large application for a catering company that also has a food commissary side to their business. The commissary daily prepares over 15,000 meals daily divided into various 'mealtypes', such as various breakfasts, lunches, evening meals, snacks, and speciality meals such as Kosher and non-milk. They have a fleet of trucks and drivers that deliver the prepared food to Adult and child day care facilities, offices, etc... All Recipies and menus (a collection of recipes) must be analyzed for the nutritional content. The raw materials must be purchased daily for the next day's deliveries based on what the menu is for that day and some items can be purchased in bulk if the menus for the next week are known.

The deliveries are made to an average of 140 stops on each of the 3 deliveries/day (AM/11/PM). These deliveries correspond to Runs. But there are differences there as well - a weekday breakfast run and a weekend breakfast run will be composed of different routes and stops.

Each customer can have multiple ship-to's and each ship-to can have multiple sites to which meals can be delivered. Each Run has multiple Delivery Routes.
Each Delivery Route has multiple stops. Any one stop can be on different routes for different runs. Each customer can have multiple Purchase orders with multiple mealtypes and each mealtype is sold different prices to different customers.

The commissary spends a great deal of time and money developing each menu so that it has all the nutrients, is varied, and no discernable repeating patterns. They would like every customer to just accept the standard lunch menu for the week but some customers swap out one or two items from the standard menu. On their old AS400 system they had to enter the exact menu for every customer. Now they enter the menu once as the Standard Menu and enter the different for the few who make changes. This cut down the time entering menus from approximately 25 hours a week to about 2 hours.

Each site's count of each mealtype are collected by Fax or Phone, usually by customer, and entered throughout the day. Also, each ship-to may not be getting the same selection of P.O. line items as another ship-to for a particular customer. This was a time consuming chore as only one site was entered per screen. Mistakes were next to impossible to correct - mainly because they couldn't see them once they were entered. Their new count entry form's list page shows a grid of all customers for all P.O.'s for every Mealtype and the entry page shows a grid with ship-to's down the left side and the 7 days of the week across. Counts are made directly in the grid and it automatically wraps to the next ship-to's 1st day of the week when the enter key is on the last day of the week for the previously entered ship-to. The entire customer's counts for a specific mealtype is seen at once. Again savings in count entry time, not to mention the savings in count errors, has reduced data entry time by 75% - 80%.

Weekly the A/R department invoices the various customers (counts/mealtype are collected, along with miscellaneous charges) the invoicing can be done in groups and then posted in batch. Invoicing had to wait for production to write up the counts and match up miscellaneous customer charges and send up the hardcopy. The A/R manager can do pre-invoicing to estimate receivables for any date range, Set up specific criteria for which customers get invoiced, Invoice multiple selections, posting after each or in a batch. Next year we are going to insert invoice info directly into AccountMate, their VFP based accounting software; right now I just output an importable text file.

This system was not cheap to build but the ROI, from what I can gather from their estimates of time saved could be about 1 year.

There are 53 tables, 168 views, 52 reports (still adding more), 54 Forms, 120 Business Objects.
This was my first Framework application. For other OOP projects I had previously written two applications from scratch in VFP 5 before this. I considered myself an advanced FPW developer (I used the Codebook 2.5 framework for about a dozen of applications prior to making the OOP jump.) I think that I could now write the commissary application in about 2/3 the time that it took me.

I'd be happy to send some screen shots if you'd like.

Travails? I think I stepped thru just about every line of framework code for the form classes, bizobj's, dataenvironment classes, menus, etc... that I used about 25 times each. But now I know what 3-tier means and that UI stuff is a no-no in the bizobjs and I'm thinking of myself as a professional again instead of the rookie I was feeling like for awhile.