Crystal Reports for Microsoft Dynamics GP 10.0 – Overview for Develope…

Crystal Reports for Microsoft Dynamics GP 10.0 – Overview for Develope…




Microsoft Great Plains has long tradition to deploy Crystal Reports, where it’s encased reporting tool ReportWriter does not provide required reporting flexibility, especially for high quality reports with graphical elements, such as logos, progressive fonts, plus where you need progressive reporting logic. Report Writer can only deal with Dexterity tables from one GP module. Crystal Reports allows you to build any SQL query you need and join “cross-modules” tables, including custom tables and tables and data in heterogeneous databases environments: Oracle, DBII, Pervasive SQL, Ctree, MySQL, and other ODBC compliant platforms. Let’s review Crystal Reports design techniques:

1. Designing Report vs. Query Building. If you are new to Crystal Reports design, we certainly understand the temptation to use wizard to create report. Unfortunately, we saw the results, when programmer was very disappointed and ended up complaining that report shows “duplicate” records, doesn’t show “all the records”, etc. You should probably think about what report designer is and what it is not. Crystal Reports is excellent report designer, but in order to provide report designer the records set you should use other tools. Let’s move to the next use.

2. Stored Procedures and SQL Views; unions. The most flexible query building instrument is stored procedure. Crystal Report should submit parameters to stored procedure and so create applicable records set for the report. In SQL View you can use Crystal Report parameters for limiting view results to be included in the report. Stored procedure, comparing to the SQL view, allows you to use internal permanent tables to build the most complex consequence set – in view you can not use temp tables. Unions allows you to combine Work, Posted and Historical transactions, for example to be included in report.

3. Example One. Imagine you would like to characterize SOP work and historical invoices in the same report. You should create SQL view, where you will unionize SOP10100 and SOP30200 tables, assuming that you would like to show each invoice total in the report.

4. Example Two. Imagine, you are selling serialized items and you would like to show the report on Item history: from whom and when it was purchased, to whom and when it was sold. In this case you create cross modules SQL view, where you join POP receiving lines and SOP historical tables.




leave your comment

Top