Sample SQL from a report I once wrote to help with 1099 processing

One of the more amusing points that comes up when talking about the features of Infor M3 is the number of reports that come with the system and are available “out of the box”.

In my experience of many years and many M3 implementations I can say that very few customers use more than a handful of those “canned” reports, and without exception every M3 customer ends up building their own suite of reports, for both daily operational use and management oversight.

Those basic M3 reports typically go through StreamServe and allow users to either receive a PDF via email or a paper printout, both formats which aren’t easy to work with when analyzing large amounts of data. If you have hundreds or even thousands of records to work with, spreadsheets remain a vital tool in most environments.

Once the decision has been made to create a reporting suite against Infor M3, there are some important considerations to keep in mind, however! Be careful to follow these Commandments and save yourself a lot of heartache…

1. Thou Shalt Not Run External Reports Against The Production Database

This is a big big big big “NO”, and should mark the fundamental technical requirement of your external M3 reporting solution. The M3 Grid manages the interaction between the Business Engine and the database, and if you throw database queries from external report users into the mix, you run the risk of seriously reducing system performance for your users.

NOTE: This recommendation does not apply to reporting options within the M3 solution, such as a well-configured List Panel or the use of Ad Hoc Reports, which are managed by the M3 Grid and cooperate nicely with other processes.

I recall one client who regularly experienced slow system performance each morning, as various Crystal Reports ran to completion while users went for an extra cup of coffee or found other things to do rather than try to work within M3. It was one of those problems that started out as a minor annoyance but became worse over time.

The solution? We used BPW (Business Performance Warehouse) to define a datamart that copied selected tables over from M3 each night, and pointed the reports to run off the datamart instead. There are a number of other options you can use to create a parallel reporting database as well, particularly if you are running on SQL Server.

Not only did this allow users to be productive right from the start each morning in M3, but I imagine they saved a bit of coffee expense, too.

2. Honor Thy Users’ Requests For Spreadsheets

One of the big frustrations many M3 users have is the lack of an easy way to get reports in spreadsheet form from the system. Yes, you can dump the contents of a panel into Excel, and there is a cumbersome process that can turn StreamServe output into a spreadsheet, but these are far from ideal.

The reality is that for many situations, users need to be able to work with hundreds or even thousands of records at a time, and spreadsheets facilitate that kind of analysis far better than a PDF or other reporting format.

A tool like Crystal Reports or Microsoft’s SQL Server Reporting Services (SSRS) provide the flexibility for users to get their information in the format that fits them best, whether a PDF or spreadsheet.

3. Thou Shalt Write Proper SQL For Crystal Reports

One issue for you Crystal Reports users is to make sure that report writers understand the M3 database structure and write SQL statements to retrieve only the appropriate information for a given report, and no more!

If you use Crystal’s Select Wizard to pick which tables you need, and then apply filters to determine which records will show on a report, Crystal Reports will try to load those tables in their entirety and then filter down to show only the required lines. This is tremendously inefficient, both in terms of client performance and the amount of network traffic needed to run a particular report.

For example, if you have a daily Open Orders report for your purchasing department to monitor, using the basic Select Wizard in Crystal will cause entire purchase order tables (as well as any other tables you are linking to) to be brought over to the machine running the report, and then that machine will crank through the data and figure out which PO’s are open and which are not.

Instead, report writers should craft a proper SQL statement that retrieves only the data that is needed. This allows the database server to do the work that database servers are designed to do – grab the specific records and fields you need, and then only transmit that information across your network to the Crystal Reports application, which can then do the work of formatting things nicely and presenting the report.

4. Create SQL Views To Define Common Business Terms

Quite often you may need to develop a set of reports that offer different slices and dices over the same data, such as Open Order reports that may be broken out by product line, vendor, facility, etc. General Ledger data is another area where the same records and fields may need to be presented in a variety of ways.

In those cases, defining a View in your SQL reporting database can provide a shortcut for the development of most of those reports. That view can define standard record selection criteria and the fields needed across a family of reports, and be re-used in multiple queries. This reduces the time spent creating custom queries for each report, and avoids the risk of error when reinventing the wheel with every new report.

5. Custom M3 Reporting Is A Necessary Investment

An ERP system like Infor M3 doesn’t just serve as the mechanism that enforces your business rules, it also needs to grow and adapt as your business changes. Your reporting requirements will follow that change as well, so prepare yourself by making sure you have the necessary expertise to present whatever information your key business users need.

If you need assistance with reporting against Infor M3, head over to the Contact page and send a note! I can not only help with designing and implementing a custom reporting solution, but can coach up your technical staff so they can handle your reporting needs going forward.

The post The 5 Commandments of M3 Reporting appeared first on Ready ERP Solutions.

This user had produced a sales invoice with three simple lines, but for some reason StreamServe created a page for each line, rather than printing them together like usual.

What could be the cause of that? All I had done was taken the existing form (OIS199PF) that was used by another division, made a few adjustments for the text in the header and footer, and deployed it for the new division.

StreamServe Help Isn’t So Helpful At Times

After digging through the online StreamServe documentation,  I couldn’t come up with any obvious reasons for these mysterious page breaks. I checked topics like mirroring, page sizing, etc., to see if those might be the problem, but no luck.

I had a suspicion that it had to do with a new text box which I placed in the footer of the document, as that was the only new element in this form. But when looking at it in the PageOut tool, it certainly looked like it wasn’t going off the bottom of the page.

So what could it be?

That’s when I remembered that all of the output elements are placed within the document in two manners. First, we look at the PageOut layout and can visually place an element on a document – and that part looked OK.

But in addition, there’s that Process window at the left side of the PageOut program, which determines the logical structure of the output. When I clicked through the various Label elements to see where the various pieces of text showed up in the structure, I found my answer!

The logical structure for an invoice (OIS199PF) is that you have all your header information at the beginning (customer info, etc.) and then there are a couple blocks which can repeat themselves: OIS1990L (the line item information) and OIS199TL (text notes associated with each line).

What I found was that my new text box looked OK in the visual layout, but in terms of the logical structure it had been created within the OIS1990L block. That meant that each time an invoice line was being processed, StreamServe wanted to print that box at the bottom of the page, and thus we ended up with a new page for each line on the invoice.

A simple “cut & paste” from that section of the structure to the main block (see the pic at right, and the red text included) and things worked as expected.

So remember! It’s not just how elements are placed in the visual layout that matters, but where they appear in that Process view can have a huge impact on your StreamServe output. For those of you who don’t work in StreamServe on a regular basis, that is a very easy item to overlook.

Note: If you enjoyed this post and could use some StreamServe help or assistance with Infor M3 (functional or technical), I am available for part-time after hours consulting! Please send a note through my Contact page or connect with me on LinkedIn for further details!

The post StreamServe Help: The Mysterious Multi-Page Invoice appeared first on Ready ERP Solutions.