I added a new date field, cstReminderDateDA, to a custom business object. For existing records, there is a requirement that cstReminderDate be set to the value of an existing date field (cstDueDateDA) minus 30 days, i.e. cstReminderDateDA = (cstDueDateDA – 30). This would be pretty straightforward, except that both cstReminderDateDA and cstDueDateDA are stored as numeric fields in our Microsoft SQL Server database. How do I populate cstReminderDateDA?
IBM TRIRIGA stores the date as epoch time. See the following wiki link explaining this. If you do some searching, you will find some functions available for SQL Server for data calculations.
[Admin: To see other related posts, use the Epoch Time tag.]
What is the best way to handle calculated fields that need to reference the Current Date or System Date? For example, I have a number field in the Building BO called Building Age. To calculate the Building Age, I had to create another field called “cstCurrentDateDA” to store the current date the Building record was created.
From there, I take the Current Date minus the In Service Date of the building. However, let’s say I wanted the Building Age field to get updated daily. In my current design, I would have to probably create an asynchronous workflow to update the “cstCurrentDateDA” field and then trigger a Save action to get the extended formula against the Building Age field to fire.
Is there a better approach to dealing with field variables that rely on the Current Date or System Date? Instead of creating a custom field to store the Current Date to act as a constant factor?
[Admin: To see other related posts, use the Date tag.]
If a work task has a calendar and the “Planned End” or “Actual End” date-time field values are updated, the “Working Hours” are not always calculated correctly. The working hours do not seem to factor in the calendar hours.
The working hours were not being calculated correctly. The issue was that the values for the calendar fields (Year, Month, Day, etc.) were not being set correctly. The fix was to set the calendar fields exactly as we do for the other calculation methods. Moving forward, we resolved a work task record and Gantt chart issue, where the Actual Working Hours and Actual Working Days were not being correctly calculated when an Actual End date value was entered.
[Admin: To see other related posts, use the Calendar tag or Gantt tag.]
When an “Operating” lease is modified, the new ROU asset balance should be calculated as the amount of change in the liability balance that is added to (or subtracted from) the prior period ROU asset balance immediately preceding the modification. Previously, this was tested on 5/18 for any lease and then still worked appropriately. As of 6/13, this no longer works.
Moving forward, the starting ROU asset value is now calculated correctly when there is an amendment to an “Operating” lease. The changes were made to the following workflows: “triContract – Subflow – Likely Term – Calculate Amend Asset Value” and “triRealEstateContract – Synchronous – triRevise”.
[Admin: To see other related posts, use the ROU tag or Right of Use tag.]
When the “Due Within” from the service level agreement (SLA) on the service assignment matrix (SAM) record contains minutes as well as hours (for example, 4 hours 30 minutes), the minutes component (30 minutes) is getting truncated when this value is being applied to the related work task. In other words, only 4 hours is considered for the total working period, instead of 4 hours 30 minutes.
The platform was only considering whole number hours, not the decimal (0.5) portion. Moving forward, we resolved an issue where the calculation for working hours from the duration ignores the minutes and seconds parts.
[Admin: To see other related posts, use the SLA tag or Agreement tag.]
When a “Finance” (or “Capital”) lease is modified, the new ROU asset balance should be calculated in the same way as future accounting “Operating” lease modifications, that is, the amount of change in the liability balance is added to (or subtracted from) the prior-period ROU asset balance immediately preceding the modification.
Note that this calculation should mirror the calculations that were implemented in TRIRIGA 10.5.2 for future “Operating” lease modifications. Currently, we see that the asset balance is set equal to the re-measured liability balance upon a modification.
Moving forward, when a “Finance” (or “Capital”) lease is modified, the new right-of-use (ROU) asset balance is now calculated correctly. The amount of change in the liability balance is added to (or subtracted from) the prior-period right-of-use (ROU) asset balance immediately preceding the modification.
[Admin: To see other related posts, use the ROU tag.]
The impairment functionality should start as a comparison between the fair market value (FMV) as entered by the user in the Review Assumptions, and the current amortized cost basis of the right of use (ROU) asset for the selected fiscal line item (FLI) period (i.e. ROU asset value in the FLI for the corresponding fiscal period).
Currently, TRIRIGA is comparing the FMV as entered by the user in the Review Assumption, to the FMV as stored/displayed in the Accounting Summary section of the Accounting tab. The impairment should be triggered when the FMV as entered by the user is less than the ending ROU asset in the corresponding fiscal period.
We needed to fix the impairment comparison against the amortized cost (asset value) for the current and new lease accounting standards. Moving forward, the initial impairment calculation no longer compares with the existing fair market value (FMV). Instead, a change was made to compare against the amortized cost.
[Admin: To see other related posts, use the FMV tag or FLI tag.]