TRIRIGAFEEDIA is an experimental WordPress hub that collects feeds from multiple IBM TRIRIGA forums, blogs, and channels into a single, searchable, and social stream. Its WordPress stream also feeds its Facebook @TRIRIGAfeedia. Welcome!
“Best blog a TRIRIGA developer can get. Check it out!” ~Mani Sanjeevi 01.12.15
Is it possible to (OM) migrate integration object records? I’ve created two integration objects in my Dev environment. But I’m not sure which BO to use to (OM) migrate my two records to my Test environment.
[Admin: To see other related posts, use the Integration Object tag.]
If a query section exists in a record, that query section has a “Find” and “Remove”. If that query has a “Group By” in it, the “Remove” will issue a MID error (even though the removal actually takes place) if filter criteria are applied before clicking “Remove”.
The problem does not occur if no filter criteria are applied before clicking “Remove”, or if the query associated with the query section does not have a “Group By”. This problem was seen in multiple releases including TRIRIGA 22.214.171.124 and 126.96.36.199.
We needed to change the submit of the page method to “Get” for non-state-changing actions like “Refresh” or “Clear Filter”. The “De-Associate” action on the “Group By” report no longer throws any exception after applying a filter to the query.
Out-of-memory errors can occur as a result of a report running, but we cannot identify which report. So we need a way to identify the report that is running, who ran it, and how long it is running, so analysis can be provided.
In the TRIRIGA 3.5.1 release, a new flag was added to reports to enable them to be tracked over time. This tracking includes who ran the report, when it was run, and the total duration the report took to complete. By default, this is disabled. However, it may be a good idea to enable full tracking across all reports in the system to help trace performance issues, and usage over time…
[Admin: This post is related to the 04.19.17 post about tracking the report runtime history, and the 10.31.16 post about using the report run history to track performance.]
If you add a single quote to a query name and click “Where Used”, it causes errors. I suspect this is due to the SQL generated, as it would require an extra single quote to pass the string correctly. If you add another single quote, to ‘escape’ the character, it will work correctly. This is an amendment to the SQL query that is generated when clicking “Where Used”. Additional logic is required where it searches for a single quote and then if it finds one, it adds it to the SQL generated.
We needed to update the SQL call to allow for a single quote in the parameter. Moving forward, the issue is resolved where the “Where Used” tab throws an exception if the report has single quote (‘) in the name.
In Space Assessment, when creating a new assessment, I want to be able to save the floor plan on <triplat-graphic> as a PDF. Is it possible to do so?
There is no TRIRIGA UX feature to export a floor plan to PDF at the moment. One possible way of doing this is to create a page containing only the floor plan and use the browser (for example, Chrome) to export the page to PDF…
In the TRIRIGA 10.4.1 Lease > Accounting tab > Schedule Summary section, there is the “Total Rent Present Value” field. In 10.5.2, that field is no longer there, but there is the “Current NPV of Rent” field. What is the difference between the two? Why are they different?
I can’t reply to the specific changes, but since 10.4.1 was released in 2014 and 10.5.2 was released in late 2016, there were scenario enhancements and more scenarios covered in TRIRIGA for Lease Accounting in the releases in between. The Lease Accounting wiki has information about the changes in these releases and might be helpful for questions similar to this (i.e., what is the difference between releases)…
Looks like the difference between present value (PV) and net present value (NPV) is the “net”. The latter “net” basically accounts for the initial capital/investment. As for “why” the change, I’m not sure, but it might be a more useful or accurate value for newer lease calculations/standards…
Both represent the Net Present Value (NPV) for the Operating/Finance schedule. The field from 10.4.1 and 10.5.2 is the same, but the label has changed in 10.5.2. In 10.4.1, it represented the Net Present Value at the time of lease activation and was not updated even if there were review assumptions performed. In 10.5.2, after the new accounting standard finalized, the current NPV now represents the NPV (liability as it is known) either at the time of first activation of the lease, OR after any recalculations might have impacted it due to performing the review assumptions. For example, at the start, it might be $30,000 and 1 year later, the NPV changed to $21,000, due to review assumptions that represent the “current” values at that point. By comparison, in 10.4.1, it would always show as $30,000.
[Admin: This post is related to the 02.22.16 post about the latest information on lease accounting.]