When you add a system filter to a report that has subtotal values (for instance, work tasks material total), the subtotals don’t add up. If you remove the system filters, the values add just fine.
You can reproduce this by creating 3 work tasks and adding a responsible person (for example, Abe Abstractor) that’s easier to spot. Each of the 3 work tasks have one currency: US Dollars, AUS Dollars, and Euro. Create a query report to list all work tasks. Add columns for values like material or time costs. Add a system filter to see only work tasks where the responsible person = Abe Abstractor (or the one you have chosen). The values will not add up correctly. Remove the system filter and it will calculate just fine.
We need to add a description about what is expected when summing non-base currency fields. If you sum a currency field, and it is not the base currency field that other fields convert into the base currency, then the summation of the column will just add the numbers up, without regard to the currency, and the currency UOM at the end of the report will be just the last UOM that happened to occur on the last record before the total row.
[Admin: To see other related posts, use the Currency tag.]
If you open up an out-of-the-box form and go to a locator field in the form, the query that is listed as a part of the field’s “Locator Query” properties may not appear when you click the picker and view the list of queries.
An example of this problem is seen in the triContract > triLeaseAbstract form’s triLocationLookupTX field. The query “Location – Find – Active Property, Building, Structure, and Retail Location or Lease” is listed as the locator query, but if you click the picker next to that field, you cannot actually select that query.
If we need to show all of the queries based on the module, then we need to check if the BO is the base BO, then ignore it and retrieve all of the queries based on the moduleId. Moving forward, we resolved an issue where the locator query against a base BO will now return all of the queries in that module.
[Admin: To see other related posts, use the Locator tag.]
How do I address the cause of currency conversion exceptions that are appearing in my TRIRIGA server.log file so they stop being logged? The exception can occur as a result of currency conversion being done when a user profile has a different currency than the base currency. Here are some examples of the exception seen in the log:
Error in Conversion from >CHINESE YUAN RENMINBI< to >US Dollars< . Using conversion rate of 1.
Error in Conversion from >NIGERIAN NAIRA< to >US Dollars< . Using conversion rate of 1.
There are generally two ways to resolve this:
- 1. Add currency conversion values to allow the currency conversion to take place. The documentation can be found in the IBM Knowledge Center: Currency.
- 2. Confirm every user profile has the same currency as the base currency. The base currency is defined in the TRIRIGAWEB.properties file.
Also, check for duplicate UOM values for currency. This could explain the exception if the first two options fail to resolve the problem…
Running queries for non-base language users (such as British English) will execute multiple calls to the IBS_SPEC table unnecessarily.
We needed changes in platform to cache many of the frequently-hit items in Classifications and My Profile, so that it reduces pressure on IBS_SPEC. Moving forward, the IBS_SPEC table is no longer queried multiple times when Classifications are included in reports. Classifications are considered metadata and the values will now be cached for a default of 24 hours.
[Admin: This post is related to the 02.20.17 post about a query generating multiple SQL statements when the user is in British English.]
When a query is run that displays relative date-time stamps, there are some cases when the resulting records are opened, the date-time stamps shown are different…
Report query against multiple BOs reads the metadata from the base BO. For the date-time values to work correctly, the “Relative” field property in the base BO should match with the other BOs in the same module.
In TRIRIGA 188.8.131.52, when a user renames a geography record or attaches it to a new parent, the path value (triGeographyLookupTX, for example) won’t be updated automatically in the associated records (locations, triPeople, triContactRole, etc). So I’m working on a solution to update all of the path values of associated records when a geography has been modified (by associating to a new parent or being renamed).
But now I’ve found another issue. When the geography is attached to a new parent, triPathSY is recalculated correctly in the base language, but not in the secondary language (French, in our case). So when I tried to update the path values of associated records, I can’t get the new path in the workflow.
After testing, renaming the geography (by modifying the triNameTX) and triSave does recalculate the path on both the base and secondary languages. So I want to trigger the same procedure before populating the new path to the associated records. Do you know how to trigger the recalculation of triPathSY in a workflow?
I am a newbie to TRIRIGA, so this may seem a very basic question. But how is the Accounting End Date changed? Here is the scenario. We have a lease with the original expiration date of 31/03/2016. However, under the terms of the lease, this can be extended on a yearly basis, so we would like this now to end 31/03/2017. We can amend the Base Lease Expiration Date. However, this does not update the Accounting End Date, which still shows as 31/03/2016.
While the lease record is in “Draft”, the Accounting End Date is editable on the Accounting tab. That field becomes read-only when the lease is “Active”, but it can be changed by doing a “Review Assumptions”. Then you will see the field as editable on the form that pops up. When submitting, it writes back to the Accounting End Date on the Accounting tab and processes accordingly. That is the simplest way to change the Accounting End Date.