Part 1: Leasing Software
Earlier posts focused on the best practices followed by ValuD during IBM TRIRIGA application upgrades. In this blog series, we highlight the best practices that ValuD advocates for an IBM TRIRIGA 10.5.3 leasing software implementation…
Part 2: Data Readiness
Our earlier blog focused on the key learning from ValuD’s 10.5.3 implementations. In the next couple of blogs, we list our recommendations for each stage of the implementation life cycle. In this post, we focus on data readiness, data migration, and the design phases…
Part 3: Journal Entries Setup
Continuing with our recommendations for each stage of the implementation life cycle, today we focus on the build process and general ledger (journal entry) integration steps…
Part 4: Testing & Training
In our final blog of this series, we list our recommendations for the last two phases of the implementation life cycle: TRIRIGA testing and training…
[Admin: This post is related to the 01.10.18 post, 08.07.17 post, and 09.24.15 post about the best practices for configuring and upgrading TRIRIGA applications. To see other related posts, use the Best Practices tag or Implementation tag.]
Part 1: Introduction
With 150+ IBM TRIRIGA completed projects across the globe, ValuD has the largest and most experienced team focused exclusively on IBM TRIRIGA. ValuD offers a variety of delivery models to meet our clients’ needs to ensure customer success whether for a new implementation or an upgrade. In the first of a four-part series, we share our best practices for TRIRIGA application upgrades…
Part 2: Lease Accounting
In our earlier post, we shared best practices followed by ValuD during IBM TRIRIGA upgrades. In this post, we highlight the best practices for IBM TRIRIGA 10.5.3 upgrades especially related to FASB/IASB lease accounting standards…
Part 3: Modifications & Metadata
Our earlier posts focused on IBM TRIRIGA application upgrade steps adopted by ValuD. In this post, we share best practices following the actual upgrade process…
Part 4: Record Data
In our last and final post on this series, we talk about record data tips and IBM TRIRIGA application upgrade delivery best practices that ValuD recommends…
[Admin: This post is related to the 08.07.17 post and 09.24.15 post about the best practices for configuring and upgrading TRIRIGA applications. To see other related posts, use the Best Practices tag or Object Label tag.]
There’s an old metaphor originating from Plato that compares the soul to that of a chariot with a pair of winged horses. Chariots of the gods were equipped with two good horses, while us mere mortals were given one good horse and one bad, unruly horse, depicting the conflicts of the soul. Due to this imbalance, we would always face hardships. But those of us who could put that unruliness to use could potentially rise high enough to hang with the gods.
What does this have to do with IBM TRIRIGA and hanging out at TRIMAX this week? Not a whole lot, I just like to throw out fascinating metaphors. However, if you’re looking to power up your facilities “chariot” with the fiercest of good stallions, and corral the unruliness of unused data, you may want to read on.
The five fierce stallions of 2017
When it comes to fierce stallions, why have 2 when you can have 5? And when you’re talking about investments around TRIRIGA, the more the merrier. Here are the top 5 stallions driving the chariot of your facilities management efforts this year:
- 1. New lease accounting standards drive compliance domination…
- 2. Analytics help you understand the performance of your chariot…
- 3. Cloud isn’t just for mythical gods…
- 4. Mobility enables the business to soar from anywhere…
- 5. User experience (UX) drives Herculean engagement…
[Admin: What does TRIRIGA mean? A tririga (trī-ˈrē-gə) is a team of three horses yoked three abreast, commonly associated with the use of chariots during the Roman Empire. To see other related posts, use the TRIMAX tag.]
We have upgraded the TRIRIGA platform to 184.108.40.206 and started upgrading the application from 10.2 to 10.5.2 in incremental order (10.3, 10.3.1, until 10.5.2). To minimize the outage and complexity during production implementation, we have been suggested to take a final OM package after completing 10.5.2 deployment, and apply all the customizations which might have been impacted with the upgrade. This final OM package will contain all the changes from 10.2 to 10.5.2.
Our question is on the patch helpers: Can we run all the patch helpers (from 10.3 to 10.5.2 in order) after importing the final OM package?
Also, we are running the Varchar-to-Numeric script before importing the application upgrade packages. This script is taking a long time (almost a day in two test environments), but when we tried in another environment, it’s running for more than 2 days and still didn’t get executed. Is it normal for this script to run like that? Or will it be an issue? There are no differences between the environments.
I wouldn’t recommend doing the upgrade in one package. Usually, it ends up being quite large and it will cause issues. The IBM-recommended way is to perform each OM, then run the patch helpers. Once you have upgraded the OOB OM packages, you can have one OM which has your custom objects…
[Admin: This post is related to the 10.25.17 post and 04.28.17 post about running “SetVarcharColsToNumeric” scripts. To see other related posts, use the Scripts tag.]
We have already upgraded our platform to 220.127.116.11. We are currently in the process of upgrading our application from 10.3.2 to 10.5.2.
For the application upgrade, we have set up a staging environment with an initial install of 10.5.2 and we have configured all BOs, forms, and other objects to meet our current customization. My question is: What if we import the IBM upgrade OM packages (sequential from 10.4 to 10.5.2) to our current environment (which has all customization)? It would definitely overwrite all the customization and configuration, but does it affect the record data as well (e.g. lease records)?
When it overwrites the customization at the BO and form level, would it corrupt the record data since some of the custom fields on the records won’t exist at the BO level any more? And what happens after we import all our customization back in the current environment from the staging environment?
The short answer is: You wouldn’t apply the IBM upgrade OM packages. Instead, you’d build OMs in your now customized 10.5.2 environment and then apply them to your current environment.
[Admin: To see other related posts, use the Object Migration tag or Upgrade tag.]
I’m having issues with request classes on work tasks. We created a project (including work location). But now, when we create a task from the project, very few of the values (including work location) are mapped onto the null work task. The drop-down that comes from the request class depends solely on this work location.
Also, the work location of the task gets its value from the project (as mapped). But now, when we try to get the drop-down for the request class based on work location, random values are shown. When I reselect the same work location, and then go back to the request class, I see the correct values. Any thoughts on this behavior? How do you get the request class list for the very first time without reselecting the work location in a work task that was created from the project?
[Admin: To see other related posts, use the Mapping tag or Work Tasks tag.]
We have an issue with duplicate opportunity rows in the building’s Assessment tab. The issue seems tied to the building system class smart section and the underlying table reporting against it, T_TR_DEF_LI_IT_TR_BUI_SY_CL, while in a building record, Assessment tab, when we create a new opportunity, fill in the building system class smart section (not the building system item one), and create draft.
If a user then tries to change the building system class, but then decides to not save and instead just closes the form, the row that is entered into the table T_TR_DEF_LI_IT_TR_BUI_SY_CL for the temp data, is not removed when the record is closed without saving. Which results in the opportunity query on buildings displaying the opportunity twice. This seems to be a general issue with the use of these tables, since it also happens when you do the same steps on a work task and a facility project; an extra row remains in T_TR_WO_TA_TR_FACILIT_PROJ.
Has anyone else encountered this issue and found a way to correct it? Using the steps below, can anyone confirm that the issue happens for them as well?
This issue is being addressed through PMR 12839,082,000 / APAR [IJ00504].
[Admin: To see other related posts, use the Assessment tag.]