Infor Industrial CloudSuite v9.01: First Impressions

During my entire SyteLine career I’ve only worked with version 8, so I was looking forward to seeing what changes there were in version 9.01.  Like most people, I’m somewhat bewildered by the name change from SyteLine to CloudSuite Industrial, but I’ve come to accept that many things in life will never make sense to me.

I first noticed that Infor is using more screen space, which means more fields on each form.  In fact, the forms don’t even seem to have a “box” around them.  The second thing that jumped out at me is the default color scheme: shades of grey, with a small splash of blue hues along the top.  This is a refreshing update.

Being a developer at heart, I was anxious to see how the Design Mode might have changed.  There are more Framework Components which means more options for better looking forms.

The Form Scripting IDE was also updated.  The Object Viewer comes up on the left-hand side be default.  I didn’t have time to see if there was a dark theme.

I noticed these dotted blue lines in Design mode that piqued my interest.  I found out that these were part of the Flex Layout and used as “guides” with aligning labels and fields.  Great idea! In fact these Flex Layouts can even be assigned a name so the versatility is broad.

Last, I want to point out the Event Handlers.  I almost cried when I saw this. They are now grouped together for better readability and organization.  For those programmers among us, this is a welcomed move. It looks great and will speed up development.

To summarize, I’m VERY impressed.  The changes I’ve seen after working with version 9 for one day have me interested and curious to discover other changes.

SyteLine Basics: Add a Field on a Form That’s Not Part of the IDO

Okay, we’ve all been there.  The users have requested that we add a field to a form.  No problem.  You load up the form, zip into Design mode and start looking through the IDO Collection.  Suddenly a grey cloud appears overhead and a single violin starts playing in the background.  The field they want isn’t part of the IDO.

(*Big Overdramatic SIGH*)

So much for a quick 5-minute modification. 

Well…if you’re like me and too lazy to modify the IDO, there is a solution as long as they only want to display the field and not edit it.

It’s possible to bind the field and the IDO Collection in one step.  Let’s look at an example starting with the Item Form.  Assume that the users want to see our #1 ranked vendor for this item.  As you may or may not know, this field is found in the itemvend table and is NOT part of the SLItems IDO (the standard IDO on the Items form.)

First, we need to add an Edit field which we’ll name editVendor as well as a Static field which contains our label of “#1 Vendor”.  Here’s what it should look like:

In the Binding field on the editVendor component, we need to add the following:

COLLECTION(SL.SLItemvends(PROPERTY(VendNum) FILTER(Item=FP(Item) AND Rank=1)))

Here’s a screen shot and unfortunately it runs off the edge of the screen:

This binds the appropriate Collection AND the Vendnum field for the matching Item and where Rank = 1.

Save your form and you’re all set.  You’ve just added a field that is outside the form IDO.

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.)