We manage properties globally so some of our locations are measured in Imperial and some are in Metric. What is the best way to manage this type of scenario so that our drawing and graphics section labels are not incorrectly sized when they are viewed from other global geographies?
The best way to address this situation is to have 2 sets of labels for your drawings, and 2 sets of labels for your TRIRIGA graphics section. You will need to adjust the height of the label elements to work for both situations. We are considering an enhancement to automatically scale according to the drawing units.
[Admin: To see other related posts, use the Graphics tag or the Labels tag.]
Does anyone know how to prevent the duration field from auto-converting to weeks and years? Just keeping the days entry?
You should be able to select the type of units to display in the Properties box for the field in the form where it displays.
[Admin: To see other related posts, use the Duration tag.]
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.]
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…
After importing a space record using the IBM TRIRIGA Connector for BIM and Autodesk Revit, TRIRIGA displays an incorrect value of the space “area” of the imported drawing.
The fix will involve setting the UOM type for the triBIMFloor and triBIMSpace area fields to Square-Feet, since the values from BIM are always Square-Feet values. This will ensure that the workflow mappings from the triBIMFloor and triBIMSpace records to their respective triFloor and triSpace records will include UOM conversion.
So, for example, if the target triFloor and triSpace records are defined as Square-Meters, the workflow will inherently convert the Square-Feet values (on triBIMFloor and triBIMSpace) to Square-Meter values.
[Admin: A similar article is also posted in the IBM Support Portal.]
IBM TRIRIGA made vast improvements in the globalization of currencies starting with TRIRIGA Application Platform 3.4.2. If you are on a platform version before 3.4.2, we urge you to upgrade to the most current version to take advantage of these enhancements. For the enhancements to work correctly, you must update your environment after you upgrade your platform. The following discussion highlights globalization areas to review after upgrade:
- User Language: A language is defined in each user’s profile record. The language establishes the locale of the user…
- User Currency: A currency is defined in each user’s profile record. When a user creates a record that includes a currency UOM…
- UOM Value: Currency UOMs are defined in the Unit of Measure (UOM) values, which are found in Tools > Administration > Unit of Measure (UOM) > Values…
- Language Code: Review the language codes in Tools > Administration > Globalization Manager > Language Code to ensure that they are correct for your company…
[Admin: To see other related posts, use the Currency tag or Globalization tag.]
We added a new currency and it is not working in production. However, when we copied the production database to a test environment, it does work.
A new currency was created “Serbian Dinar”. It was added to the UOM Values object and to the “Currency” list. The new currency was added to the real estate lease and the payment schedule with no issues. However, when payment schedules are generated and the payment line items are created, the triCurrencyUO field on the payment line item is blank and not updated from the payment schedule.
Clearing the TRIRIGA cache did not resolve this issue. The issue was resolved by restarting the application server.
A query generates multiple SQL statements that translate the UOM for every line in the report, when the user is in British English. The report template executes the exact same SQL over 3000 times.
The report runtime engine needed to make a call to get UOM data from the cache, not query the database. Moving forward, UOM values used in queries and reports are now read from the cache. Previously, they would be queried from the database, leading to a slight performance hit.
When exporting a query with records in a mixture of currencies to Microsoft Excel, the currency will be shown correctly in the currency column for a field. However, the currency symbol will use the regional currency.
[Admin: The same article is also posted in the IBM Support Portal as a technote.]
Is there a list of keywords that IBM Watson Analytics uses in column headers to try to determine properties? Could “Gross” be a keyword for currency? Once set in Watson Analytics, it doesn’t appear to be converted.
For example, look at the out-of-the-box “TRIRIGA Buildings & Space Allocation Data” set. Gross Area shows as currency ($). Others are too: Area/Occupant (Gross), Gross Rentable. But not all number columns are, ones that don’t include “Gross”. The UOM doesn’t appear to be defined in the properties, so it seems like it must be using the column header? I haven’t tried changing the header, but as-is, once exported, is there a way for that column to show correctly as an area instead of currency?
This question is best suited for the IBM Watson Analytics forum. There are posts on that forum that indicate that Watson Analytics does look at column names when deciding whether to add currency values, but I did not see a list of all the special keywords. Other than changing the column name before upload, I don’t know of a way to override those special keywords or modify the UOM that Watson Analytics assigns in the data set. So these questions will be better answered in the Watson Analytics forum. That forum is also the place where you can suggest enhancements around this Watson Analytics behavior.
[Admin: This post is related to the 12.15.16 post about finding information about the IBM TRIRIGA Connector for Watson Analytics, and the 11.15.16 post about the overview and demo. To see other related posts, search “Watson Analytics“.]