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.]
The “Grant Security Access – MASSUPDATE” workflow does not filter the groups and licenses correctly, because various tasks in this workflow are not set correctly.
The “Update Records” action on the Grant Security Access form was creating a duplicate of Groups/Licenses on People and My Profile records if the Groups/Licenses selected were the same as the ones added on People and My Profile. Moving forward, we resolved the issue by modifying the workflow “Grant Security Access – MASSUPDATE” to not create any duplicate Groups/Licenses if they are already added to People and My Profile. We also fixed another issue, to create new Groups if the “Clear Existing Security?” check box is checked.
[Admin: To see other related posts, use the Groups tag or License tag.]
When the user go through the Object Label Manager to access a form and change the name. The system allows you to name it the same as another form, resulting in duplicate form names. There is currently no error handling for this. Meanwhile, if you access the form from the Form Builder itself and try naming it the same as another, the system will give you an error.
The issue was that the link into Form Builder from Object Label Manager’s Labeled Objects tab was not passing in the module ID and the BO ID for the form, thus the unique name validation for the module was failing to occur. This fix obtains the the module ID and BO ID for the form selected and correctly passes it to Form Builder. Moving forward, we resolved an issue in Object Label Manager, where opening a form from a link under the Labeled Objects tab would allow a user to change the name of the opened form to a name that already existed in the form’s module.
[Admin: To see other related posts, use the Object Label Manager 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…
Create two capital projects with identical names. Add those two projects to the program. Add funding for the first project from the fund that you created on the program. Add funding to the second project, from the same funding source.
Open the first project again, and you will see the funding you just added to Project 2 is also on Project 1. It does not create duplicate allocation records, but instead, associates the allocation to both projects, causing it to appear in both Project Fund Allocation sections.
[Admin: The same article is also posted in the IBM Support Portal as a technote.]
When the first lease payment date is prior to 1970, the generation of the schedules will cause records to be generated well beyond the number of expected records as well as creating duplicates.
As a temporary fix, create individual payment records for those dates prior to 1970. Note that this can be quite cumbersome if the legacy lease dates are significantly further back in time than 1970. We needed to check if the date is the smallest allowed in SQL Server, “01/01/1753”. Oracle and DB2 allow dates as small as 01/01/0001. Moving forward, we fixed a long-standing issue when creating leases with dates prior to 1970.
Has anyone seen this issue before? After I upgraded from TRIRIGA 3.3.2 to 3.5.1, the BIRT report fails to load due to a duplicate path issue. The file exists, but the path (C:/Tririga_351/userfiles) circled in yellow is duplicated.