Share your Success!

[tmar]

One of the critical mistakes that some companies make is customizing your system to the extent that it either prevents or extremely hinders your ability to move newer software versions and sometimes even apply monthly updates. 

Having witnessed this happen several times when I began to "customize" MAS500 to meet the specific requirements of my company I decided to do so by creating the necessary functionality outside of the MAS500 system but in a manner that would allow our users to seemlessly integrate the results. 

By adding custom tables that link to the standard MAS500 tables, I don't need to worry about updates as the key information that I use to tie the two worlds together seldom changes in releases (things like Sokey, Itemkey, custkey etc).  Adding custom tables in this fashion and using both Customizer and some custom VB code, I've been able to transform the MAS500 ERP into a system that meets our specific needs.

Here are a few examples of functions I've built in:

1. Service- Our service/maintenance paradigm is unique enough that that the Sage recommended partner didn't match up well with our needs.  By adding a few custom tables, a customizer button here and there, and a little vb.net code I was able to create a service & PM tracking system that ties into our customer & SO history as well as tracks incidents by serialized item.

2. Project Management- Our projects are heavily dependant on inventory and a good deal of that is serialized inventory and so the PA module wasn't a good fit for us.  By using the methods for the service system we were able to come up with project tracking & information system that ties in several custom tables with the Sage tables to give project specific information in a manner that our PM department needs to see it, including a small timesheet program.

There are several more utilities that we've developed over the years but the point is that with MAS500 you not only get a stable platform, but you get a platform that is flexible enough to allow sophisticated users to mold & customize their system without fear of becoming locked down from future upgrades. 

Message Edited by tmar on 12-12-2008 02:54 PM

[LouDavis]

Tmar,

It sounds like you've sat in on the MAS 500 SDK course when it was taught by PSG.  Creating your own extension tables was stressed during that class.  If you haven't attended that class, your experience with working with MAS 500 have made you a very wise person.

[tmar]

I'd love to lie to you about how I figured it out myself but I've got to give credit to our VAR (ESC not to name drop).  While fretting over the limitation of only 4 user defined fields in SO Header our VAR said "just create a custom table with all the custom fields you want". 

That was about 60 custom tables ago and it just keeps getting better. 

A few side tips, however for anyone thinking of doing this:

1- Make sure you document your tables

2- It is wise to use a different naming convention at the module level so as to easily be able to view your custom tables without confusing them with default system tables.  For instance my project table is called TCCSProjectMaster (I use CCS, my companyid after the T for all of my tables).

[gmbeauli]

Great input guys and it's definitely in line with the customization approach we want our customers and partners to adopt.

Question for you and others on the community. How do you manage business rule changes that may require a change within the VB task code or a stored procedure? Have you stubbed out those changes within the code to an outside DLL or separate Proc?

Gerald

[tmar]

I usually deal with things like that outside of the system with a separate SP or function.  The only system SP I've modified has to do with creating data for the wrk tables on a system generated report and it is only 1 SP. 

[JeremyHutchinso]

For changes withing standard VB code or SPs, I always put those inline.  I just make sure to surround them with comments:

'_SRC Begin 

 code changes

'_SRC End

Then when it comes time to upgrade, I just search for code '_SRC and move it to the new project/sp in the same place.

[RDCushing]

Indeed, we have always used the methods identified in this thread to extend MAS 500 capabilities. We have a naming convention for what we describe as "extended attribute" tables. An extended attribute table for Inventory records would be, for example, "timInventoryExt_SSS" where the "Ext" portion indicates it contains extended attributes for timInventory and the "_SSS" portion indicating that the table was created by our firm.

In this example, our timInventoryExt_SSSI would bear the same two keys required by timInventory -- namely, ItemKey and WhseKey.

We, likewise, clone and adapt standard MAS 500 stored procedures where changes need to be made and we can call these procedures without having to modify client-side source code.

Thanks for this thread.