SyteLine Basics: Turning a Report into a Grid

Taking a report and creating a Grid form is one of the most common requests I’ve gotten as a SyteLine Programmer. I get it: daily reports are so 1980’s, outdated almost as soon as they’re printed. These days it seems users don’t even want a Grid…they simply want to use the Grid to create a spreadsheet.  Once they have the data in a spreadsheet, then they can control how it looks and functions.

Anywho…let’s get back to the issue at hand.

The first thing to do create a CLM (Custom Load Method) stored procedure that gives you all the fields you need for your Grid.  Using the stored procedure from the report is usually a good place to start.  In my (very simple) example, I’m going to center everything around the job table.  As input parameters, I’ll use the From/Thru range on the Job Number, Job Suffix and Job Date.

Now, here’s where things get interesting.  Infor, by way of the Mongoose Framework (which I really like), makes you add your Custom Load Method to an IDO as a Method.  Even if all your fields are coming from the Custom Load Method and you want to define these fields as unbound properties.  The downside to this, is that an IDO must have a primary table associated with it; even if you’re not going to use it.  So theoretically, you could add our Job Grid CLM to an IDO built around the Employee table.  It wouldn’t make sense, but it would work.  Of course, you would never do this in the real world; you want to look for an existing IDO that has something to do with your grid.

In our case, we’re working with the job table, so it makes sense to use the SLJobs IDO. Go into this IDO, Check it out, and add our CLM as a method.

The cool thing is that you can hit the Resync Parameters button and the program will automatically read the stored procedure and pull in all the input parameters for you.  This saves you a little bit of typing. (Yeah!)

Next, we must define out output parameters.  Because our Grid is a read-only format, the easiest way to get this going is to define our fields as Unbound.  You can do this by going into the New Property tab.  Go ahead and enter each field individually and be sure to select the correct Data Type. 

Now it’s time to reflect for a moment.  An experienced SyteLine programmer and anyone in their right mind is going to ask why I’m setting up these fields as unbound.  The reason is simple: I want a quick and dirty way to build my grid.  Plus, I know that once the users see this, they’re going to ask for about 300 modifications before the dust settles.  At this point, I don’t want to modify my IDO to make this work, when I don’t know what my final grid may look like.  I like the flexibility to simply modify my stored procedure.  I realize that there may be better ways to approach this, but this is the process that I’ve settled into. 

Your Property Grid should look something like this:

Now that we have our IDO ready to go, we need to create our Grid Form.  Once you get used to the Mongoose Framework (did I mention already that I really like this framework?) this is easily done in about 10 minutes.  Again, our input parameters are Job, Suffix and Date.  I also like to add a “Refresh” button, which lets the user refresh the collection in case they want to change the parameters.

Here’s how to add the Custom Load Method on your form.  In my example, I’ve name my CLM “_ABC_CLM_JobGridSp”.  (I’m using a standard of having the first 3 letters of any custom stored procedure as the company or project name.)

Here’s the input parameters of Job, Suffix and Date.

And here’s what the Refresh Button Event Handler looks like:

And that’s it.  You’re ready to rock and roll.  From now on the Users won’t have to print a report, they can simply go to our Grid and lookup the information.

(Fade to Black.)

Leave a Reply

Your email address will not be published. Required fields are marked *