IV94038: Copied template is saved but does not display changed name


After changing the name and copying a template, the name change is saved in the database for the copied template. However, it displays a “Copy of” the original name. In other words, the name stored in the database is different from what is being displayed in the TRIRIGA interface. So when you copy a template, it fetches a different name from the database and concatenates “Copy of” with that name. This seems incorrect from the front end.

Moving forward, we fixed an issue where the capital project template name was modified and then copied, but the copied template was not created with the modified name. This happens only for non-US English users only.

[Admin: To see other related posts, use the Templates tag.]

Continue reading

How are currencies handled in a globalized TRIRIGA environment?


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.]

Continue reading

IV93379: Record name change is not being reflected via web services


When a record name is changed in the record itself within TRIRIGA, the new name is reflected, but when querying the record via an integration URL for an XML output (e.g. f=xml url parameter), the specId is still referring to the record with the original name. This happens with localized users…

When a record name is changed, it is not being reflected when requested via web services. The issue was that integration query URLs were not returning localized values when the response is in XML format. The fix adds two new URL parameters that can be used to localize XML results. They are f=xml-loc and f=pxml-loc…

Continue reading

Is there a way to modify the localized expiration message?


We encountered the following issue with our French client. The session expiration message isn’t being properly displayed, as seen below. Is there a way to access the localized text and modify it through Globalization Manager perhaps? Or is it hard-coded?

Votre session expire à
01/25/2017 14:18:21
Cliquez sur OK avant expiration de la session pour continuer. Si votre session est arrivée à expiration, tout le travail non sauvegardé a été perdu. Cliquez sur OK pour ouvrir la session. Cliquez sur Exit pour fermer la session.

[Admin: Compare with the correctly-rendered text below.]

Votre session expire à
01/25/2017 14:18:21
Cliquez sur OK avant expiration de la session pour continuer. Si votre session est arrivée à expiration, tout le travail non sauvegardé a été perdu. Cliquez sur OK pour ouvrir la session. Cliquez sur Exit pour fermer la session.

Continue reading

IV92257: JSON result of a query not reflecting the correct names


When you run a query expecting JSON results, via the integration object external URL functionality, the modified names of the roles are not being reflected. That is, the original name is displayed in the result query. This happens for localized users only. Meanwhile, US English (US_en) users observe the proper changes when refreshing the query results…

Continue reading

What is the best practice for localized data loading?


As I’ve understood it, both the integration object and DataConnect allow you to import localized data (except business key fields, I think). In addition, we have another option to use the Globalization Manager to import traditional data. I found it’s pretty cool. We will only deal with the localized data, with less impact for the non-localized data. Before going forward with an option, I’d like to know what’s the best option for you guys?

Importing by using the Globalization Manager updates the L_ tables directly. If your data does not include localized values that need to be concatenated, for example in a formula, the Globalization Manager import is your best option.

However, if your data includes localized values that need to be concatenated through a formula, or if your data needs to be processed by workflow before it is added to the TRIRIGA tables, then you should use either the integration object or DataConnect.

[Admin: This post is related to the 03.02.16 post about best practices for integration optimization.]

Continue reading

IV91564: Modified building name search for localized users fails


If a parent building has been renamed, a localized user cannot find that parent building in the lease by searching for it. You may test directly in Portfolio > Locations and may be able to find that for a localized user, the name of the building is modified. But that change does not flow to the column named “Building”. That is ultimately the building name used in the query inside the Lease record…

The root cause is that the query that displays the list in Portfolio > Locations is “Location – Manager Query – Manage By Hierarchy”. The field that is displayed in the column labeled “Building” is triParentBuildingTX. In the Data Modeler for Location > triBuilding, the Localizable property for triParentBuildingTX field is not selected.

Continue reading