BIRT report migration to analytics module fails due to missing calculated fields in wd-r2-2023

Our organization is migrating from BIRT Studio to Workday’s native analytics-report module as part of our R2 2023 upgrade. We have 45 custom BIRT reports that heavily use calculated fields and custom formulas. When attempting to recreate these in Report Writer, we’re finding that many of our calculated field logic doesn’t have direct equivalents.

For example, we have a BIRT report with a calculated field that determines fiscal quarter based on transaction date with custom logic for our non-standard fiscal year. In BIRT this was straightforward JavaScript, but Report Writer seems to have limited calculation options. Several fields that reference other calculated fields in BIRT also seem problematic - the field mapping isn’t clear.

Has anyone successfully migrated complex BIRT reports with nested calculations to the analytics module? Are there compatibility issues we should be aware of between BIRT field structures and Report Writer’s calculation engine?

One approach that’s worked for me is using custom worktags or custom objects to pre-calculate complex values during data entry rather than in reports. For example, if fiscal quarter is used across multiple reports, create a custom field on the transaction object that auto-populates fiscal quarter using business process logic. Then your Report Writer reports just display that field directly instead of calculating it. This is especially useful for values used in filters or groupings.

Report Writer calculations are definitely more limited than BIRT JavaScript. However, most business logic can be recreated using calculated fields with if-then-else statements and field references. The key is breaking down complex BIRT calculations into simpler steps. For fiscal quarter logic, you’d typically use a calculated field with date functions and conditional logic. Can you share what your fiscal year start month is?

For fiscal quarter with April start, you can use Report Writer’s MONTH function combined with conditional logic. Something like: if MONTH(transaction_date) between 4 and 6 then ‘Q1’, if between 7 and 9 then ‘Q2’, etc. For the fiscal year portion, you’d need another calculated field checking if month is Jan-Mar (use prior calendar year) vs Apr-Dec (use current calendar year). Then concatenate both fields. It’s more verbose than BIRT JavaScript but achieves the same result. The bigger challenge is nested calculations - Report Writer can reference other calculated fields but performance can suffer with deep nesting.