Configuration Console Tips

Different ways to use a Boolean Derived Field 


You may want to create a Boolean (true/false) derived field to define your multi-conditional criteria

















You can then use the criteria to determine whether or not to display a form section or to display an individual field -










You can also use the criteria to add a field constraint -











You can also use the criteria to restrict an Action - in this case, if the criteria is not true then restrict the Action







Configuration Console Tips

Constraint of values in a field's dropdown list

You can apply a constraint to a field's dropdown so a specific value is hidden on a form.

By applying the constraint as shown, the 'WORKERS COMP' value will not be a valid selection for the user to select (on the form it is applied to), although it is a valid selection in the system.

This type of constraint doesn't include the text you normally apply to an Action or Form constraint.

Configuration Console Tips

Form Configurations

Layout
    single column - fields are presented in a single column
    two column - two fields are presented side by side 
    two column distributed - two fields are presented spaced apart depending upon the width of the fields and form

Add a custom label to a field
    single column
        field name
            label is untranslatable:"Enter_the_label_value"

You can also use 'camel case' so each word is presented in uppercase "EnterTheLabelValue" and the system will automatically add spaces so the display would be Enter The Label Value

Present a field as display only without a label
    field name
        display as text
        no label

Present a field's label in a color or in bold text
    field name
        color is red
        bold

Make a field required
    field name
        required

Add a Header to the various sections of the form
 
    header3 of "ConfidentialityAgreement"
        single column
            field name
            field name
    header3 of "User_Fields_are_Required"
        three column
            user field name
                required
            user field name
                required
            user field name
                required
                label is untranslatable:"DateOfPurchase"

Add Text to the form
    text of "The_following_information_is_helpful"

Add a Blank Line
    blank line
or
    text of "_"

Do something after a field has been updated
    two column
        StartDate
            when value changed
                EndDate = StartDate + 1 year
        EndDate

Make a field visible when another field has value
    single column
        StartDate
        visible when (StartDate entered)
            EndDate

The 'visible when' control is based upon a 'state' of a system value, a field state or a boolean value (which can be defined is a User Derived Field) and can apply to sections of a form or to individual fields

Make a form section visible when a system value exists
    visible when (BenefitEligible.No)
            single column
                text of "OR"

 
Infor GHR and ICIMS - Two Approaches to Integration

I have two difference clients using ICIMS for recruiting and integrating with GHR for onboarding new hires, processing rehires and performing transfers and promotions.

One client is processing a nightly pipe delimited file and the other is using API calls and checking hourly for new transaction data. I'm using IPA to process both integrations.

The client using the file integration is running the transactions through a data warehouse first and performing some edit checks and translations there before sending it to GHR.

The client using API calls is also sending Job Requisitions to ICIMS from GHR, once they're approved, and providing other feedback to ICIMS after the new hire is processed (GHR employee number), using API calls.

For this client, we are also retrieving the PDF documents from the candidates in ICIMS (Education, Certifications & Licenses) and attaching them to the Hire a Resource form. These binary data files are processed via API calls and saved first to the PfiFileStorage before being attached to the hire transactions.

Two clients with different approaches, but both successfully integrating ICIMS and Infor GHR.

Not just answers, providing solutions

Where is the problem? Is it a bug?


I've been involved with a lot of implementations and upgrades over the years and I'm certain that every one of them had hit a snag at one point or another. Whether miscommunication, improper training, or technical issues, all of these needed one step to get to the solution - an evaluation of where the problem lived.

Not just what issue are we dealing with, but where is the actual problem?

Is it a bug?

One project I was involved with had major allocation issues in the storeroom. Items were being allocated to orders before the item was even in stock. This appeared to be a major bug that would require escalation to the vendor before the client could go live, and that was the path the project manager was taking to get to a resolution.

I was one of several supply chain consultants, primarily brought in to help with pre-go live training and go live support. In other words, I was just there to help the team cross the finish line.

I don't recall if I was asked or if I just overheard about 'the bug' that was causing frustration, but I decided to look at the system settings.

The flag that allowed allocation on open PO's was set to 'No' correctly, yet the system was allowing it. That made no sense, so I kept digging and eventually found another setting that seemed to be contrary to the no allocation setting.

I don't remember the actual setting now, but I do remember that it seemed to allow for allocations when an item was on order (not yet received) and so I brought my discovery to the project leaders.

Expecting a high five for my doggedness, I was surprised when I was told that my discovery could not be the cause of the issue since the other allocation flag was set to no.

To their credit, however, they did allow me to run through some system tests and I found that this one setting, against all logic, was in fact where the problem lived.

Issue solved, go live saved, bonus awarded (not really). By this point everyone was just ready to get the issue behind them and focus on the important go live.

Not just answers, providing solutions

Infor Federation Services - Lessons Learned, Mistakes Made


When the company I was with first implemented IFS we made a lot of mistakes, quite frankly because no one told us the right way to do it. We followed steps that seemed to make sense from past processes in the Infor Lawson world, but which didn't work well in this IFS, ION, & BOD world we were moving to.

Security Roles - we created all of the security roles (from Lawson, Landmark, GHR & EAM) in IFS instead of feeding them from these systems via the Security Role Master BODs. This created problems when we later tried to utilize some features of 'role control' from GHR.

You can default roles on job/positions in GHR and we were hoping to automate removing roles when someone changed their job/position. The problem was that the roles in IFS were tied to multiple Logical IDs and simply removing them in GHR (and feeding those updates to IFS) didn't work.

When we removed the role from the user in GHR and sent the process security user master BOD to IFS, IFS didn't remove the role from that user (because it was associated to multiple Logical IDs) and the sync security user master BOD back to GHR added the role again.

Mistake made, lesson learned. Only associate one Logical ID to a Role by using the Sync Security Role Master BOD to add them into IFS with the Logical ID of the sending system.

Another issue we encountered in role maintenance - because we didn't understand our new world - was not cleaning up roles in Lawson that had been added only for the sake of using ISS sync with Landmark.

The old process required all Lawson security roles to be built in Landmark and all Landmark roles to be built in Lawson in order to keep the users in sync via ISS. This is not a requirement when security if maintained by IFS.

This duplication just clutters up IFS by associating both Logical IDs to these roles, especially since most users don't need access to non-GHR/FSM Landmark. [Yes, Virginia, there are two different Landmarks.]

Mistake made, lesson learned. Before migrating to IFS, take a look at your current setup and take the time to clean up what's no longer going to be required.

Not just answers, providing solutions