Its true that you can pull RW100 reports into Crystal to use as the data source, however, its my very humble opinion that the only reason you would want to do this is to leverage the work that was already put into the creation of the RW reports. Using the them as a data source can prove to be very time consuming and frustrating. There are Environment and Application patches that must be met, formatting constraints (1 format per RW), file permissions, scheduling and worst of all, once you have linked the RW100 into Crystal, the naming convention of the fields is slightly less complicated than nuclear physics.

If you dont have the infrastructure to support a reporting database (whether a data warehouse, data mart or reporting tables) then this may be a good scenario for using RW100 as a source however I would not say the effort is less complex.

hth
matt

I wholeheartedly agree with Matt's eloquent response; trust me, I've dealt with this issue enough times to know...

I'll also agree with the veterans on this one.

Ditto.

I would also have to agree after I have spent the last week converting our Budget Comparison reports from RW100 into Crystal. I did use the RW100 reports as the data source (mainly because I was under a time constraint and didn't feel like rebuilding the hundreds of rows of data), but it may have been easier to start from scratch. As is, I did have to modify the Row and Format (from 4 to 1) files used like was stated in one of the earlier replies. I was lucky that I didn't need any of the patches installed, and there is a fairly decent KB article (127045 I think) that helped.

To answer the original question:

Should financial statements be built using RW100 and published to Crystal or built from scratch in Crystal to ensure the best performance?

From the experience at my company, the answer should be "both". Reporting to the field and to the executive level is best done in Crystal. Looks great, runs fast, uses ODBC to run real fast, very flexible. But - a set of judiciously chosen RW100 reports should be available for checking that Crystal is not giving false results!

( Value = $0.02 )

We do not have a datamart or custom tables in place for going directly against the lawson GL tables so we use RW100 as a data source for crystal. From our experience RW100 as a data source for crystal is an easier and more accurate source. the RW100 actually calculates current period, year, previous period, prior year and has paramaters to calculate every period and year of the financial data which is actually stored as derived fields in the Lawson native GL tables.

The only issue we have is Rw100 when used as a source could have only one format. the way we have overcome this is to bring back amounts units, budgets etc on one row. Again you may fall into the next limitation which is that RW100 has 233 characters as its max limit. Again what we have done to overcome this is we actually have each field on the report to have a max of 4 digits which means that when you display the output you will be able to see only the last 4 digits of each value but the field stores the entire value which may be equal to a 100 billion. When you output this to crystal, crsytal will show you the whole value of the field. Also on the output when you look at the fields the field names correspond to the actual position no of your format file. So if your format file has current period on the third position, when you bring this into crystal the name of the field will be compute03. We actually like using RW100 for reports which are simple.
Of course going to a datamart solution of custom tables will require a datamart design and also an ETL tool to load data from native lawson tables to the datamart.

Hope this helps.

You don't need a datamart. Even Access is powerful enough to build the derived fields and do calcs on the fly. The derived fields are pretty simple to write. After you write them once in Crystal, you can just copy the formula from report to report.

I am about to rewrite a bunch of RW reports into Crystal. I can not work out where in the RW tables I can find the grouping definitions that are used in our RW reports. For example we have a group of accounts called "ABC" that group is already defined for RW reports - do I need to redefine in Crystal or is that group definition somewhere in the RW tables?

Does anyone know how to use the RW ROWDET tables to rewrite RW reports in Crystal. We have different groupings defined that I can define in a view or I can pull from the RW tables? I am looking for any documentation I can find on the RW data tables?

I got some answers but did more research myself and we have now rewritten 10 reports directly against the LAWSON tables instead of against the RW data source. We create views that take the group structure from the rwrowdet table and allow us to re-create that group structure in Crystal.

this reply is for julia - i'm curious to know more about how you created a view against the rwrowdet table to recreate your grouping in crytal. i'm trying to re-write out income statement in crystal becaues it takes 8 hours to run the RW100 report, but i can't figure out how to get my grouping to work. it sounds like this could be my answer but i'm not sure what info you used to build the view.