Workbrain in IE 8 and now 9

Infor is diligently working on the next big Workbrain release that will address many rendering issues seen in the Internet Explorer 8 and now Internet Explorer 9. Many enterprise customers using Workbrain (4.1 or 5.0) haven't switched from Internet Explorer 6. Just see this article: Old and Insecure, IE6 Still Popular in the Enterprise. Nine years after the IE6 release, many customers are ready to move forward.

Resetting a Scheduled Task After it Stops on Failures

 By default, a Scheduled Task will run and fail up to 10 times before it stops running on its own.

The No. Of Failures column turns red and the Task State is Disabled.

In order to reset the task, user intervention is required at this point. There is not an obvious way to reset the No. of Failures column. I actually used to reset this directly in the database because it was not intuitive to me!

My colleagues shared with me that all you have to do is hit the Pause button for the task, and then hit the Resume button to reset the No. Of Failures column and resume the task. Simple Workbrain Hack for today!

Alerts Based on EMP_ID

Rarely can we create a Workbrain Alert without joining database tables in SQL. When we want to send the alert based on an an employee, we must select EMP_ID in the SQL, the EMP_ID has to be selected first, and as of now in the software, the column name has to be strictly EMP_ID. Not doing this and selecting an option that requires EMP_ID, the Workbrain application will throw the following error:

EMP_ID must be one of the columns if recipient roles are populated or self is checked

Auto Recalc Part 2: Weekly Overtime and Holidays

To compound the requirement from the last blog post of paying a premium at the beginning of the week based on the remaining week’s work, an additional requirement was also included. The premium to be paid would actually be based on the overtime, if any, inserted by the weekly overtime rule. This is not a big deal if the overtime is actually added on the last day of the week (Saturday in our case). As discussed in Part 1, when the user inputs clocks onto Saturday, Saturday would be recalculated first, followed by the auto-recalculation of the full week, starting with Sunday, so the premium rule would easily see the overtime that had been inserted by the weekly overtime rule on Saturday.

But suppose this overtime was rolled back to Friday. The client requires that in the scenario that Saturday is a holiday, that the overtime not be applied on the holiday (since the employee is already receiving the holiday rate), but rather be rolled back to the day before. Additionally, the time worked on Saturday count towards the weekly overtime.