Programming Microsoft Great Plains Alba Spectrum
Each ERP application should be open for tailoring:
modifications, custom logic, reporting, integration with legacy systems, EDI
interface, etc. In some cases you may expect special modules or third party
extension, however if you have simple customization need you may undergo
in-house GP programming project to make job done. This article intended to be
orientation session for IT people and internal software developers. In the best
case scenario you should balance external GP consultants and internal programmer
and project managers to realize your projects. Lets begin:
- Great Plains customization tools. GP similar to other
MRP and accounting applications is the combination of proprietary and open
technologies. Main proprietary technology is Microsoft Dexterity, which
requires special license and Great Plains Dexterity certification is
recommended to do Dex programming. Dexterity is core technology, however as
Microsoft .Net platform advances, open technologies open the GP
customization door. Open technologies typically require MS Visual Studio
development skills plus ADO.Net and some SQL scripting expertise. These
tools are: eConnect, Modifier with VBA (this one is not a .Net based it is
rather legacy but should be considered open platform as VBA is popular for
MS Excel modifications). There are other enablers, opening Great Plains
Dexterity objects to MS Visual Studio C# or VB developers use them at your
discretion
- Programming GP Integration Manager. IM could be
considered as end-user tool however it is very powerful and customizable, so
if you are VBA programmer you can consider IM as custom integration
platform. VBA modification can intervene IM events: before document, after
document, etc. Plus you can do incoming records translation create your
customer or vendor translation table in Excel and then import it to
Integration Manager
- SQL Scripting. This technique requires advanced
familiarity with GP tables structure and records distribution. You should
be aware that SQL insert statement simply populates SQL tables, but it
doesnt validate GP business logic. So, SQL scripting may cause data
integrity problem and typically requires longer Quality Assurance (QA) and
debugging cycle. As a hint for you eConnect does validate GP business
logic, so if you could deploy eConnect and not SQL stored procedures you
will be on the safe side of the programming project
- GP reports design. There are several tools and you
got to get the idea on their usability. First of all GP ReportWriter.
This tool is integrated in GP workstation interface you can modify such
popular reports as SOP Invoice, POP Purchase Order, GL trial balance, AP
historical trial balances to give you few examples. RW is Dexterity
application and it has Dex limitations, so if you get to break through, you
should consider FRx for strictly financial reports (linked to General Ledger
GL), Crystal Reports (unlimited in theory, however you have to do all the
work in SQL views or stored procedures from scratch) or Microsoft SQL Server
Reporting Service or SRS (at this time we are inclined to consider SRS to be
catching up in competition with Crystal, especially considering Microsoft
plans to promote its own report design tool)
Andrew Karasev, Alba Spectrum Group,
http://www.albaspectrum.com
help@albaspectrum.com 1-866-528-0577, 1-630-961-5918, serving customers
USA/Canada nationwide: Illinois, California, New York, Quebec, Ontario,
Colorado, Utah, Wisconsin, Florida, Texas. Local service is available in
Houston & Dallas:
Richmond, Sugar Land,
Katy, Rosenberg, Missouri City, Pearland, Friendswood, Meadows, Mission Bend,
Jersey Village, Fort Worth; serving GP customers in Chicago, IL:
Naperville, Aurora, Joliet, Wheaton, Bolingbrook, Romeoville, Lyons, Niles,
Downers Grove, Lisle, West Chicago, Barrington, Schaumburg, Elk Grove Village,
Lombard, Morris, Ottawa, Marseilles, Seneca, Oswego, Plainfield, Darien,
Winchester, Hinsdale