Skip to main content

Release 1.14.1

General Release Information

Release 1.14.1 (SuiteApp version 1.14.100) was released on January 2, 2026, and includes several enhancements and bug fixes detailed below. Your Production account will be updated automatically, while you will need to manually update your Sandbox account at your convenience. 

Enhancements

FFA-1640: Bulk Approvals Portlet and Page > Display Full Employee Name When Auto-Generated Numbers are Enabled

Previously, when the Auto-Generated Numbers for Employees preference was enabled, the Bulk Approvals portlet and page displayed only the Employee ID in the Requestor, Previous Approver, and Next Approver columns instead of the employee's full name. This has been enhanced so that now the Bulk Approvals page and portlet display the employee's first and last name regardless of whether the Auto-Generated Numbers for Employees preference is enabled. If the Name field on the Employee record is empty, the system will fall back to displaying the Employee ID for identification.

FFA-1894: Prevent Deletion of Accrual Postings in Locked Accounting Periods

Previously, when the accrual preference "Delete Accruals Instead Of Reversing" was set to True in Approval Configuration, the associated Unapproved Transaction Accrual postings would be deleted after the source transaction was approved or rejected. This deletion occurred also when the Unapproved Transaction Accrual posting fell within a locked accounting period. This risked modifying financial data in periods that were meant to be closed for changes. This behavior has been enhanced. A new logic has been implemented to block the deletion of Unapproved Transaction Accrual postings if their associated posting period is currently locked. Now, when a source transaction is approved or rejected, if the Unapproved Transaction Accrual posting is in a locked period, the system will prevent the deletion and will instead generate an Unapproved Transaction Accrual reversal entry. This reversal entry will be generated in the first open/current posting period depending on the Accounting Preferences setup in NetSuite, maintaining compliance with locked periods and ensuring proper financial controls. 

The same adjustment was done for Unapproved Transaction Accrual postings when an unapproved transaction is edited in a locked period.

Bug Fixes

FFA-1772: Double Accrual Postings Resulting from Locking of Accounting Periods

Previously, if an Unapproved Transaction Accrual posting was created in an open accounting period, and that period was subsequently locked before the transaction was fully processed, the 'FFA Accrual Posting Update MR' script would incorrectly treat the original accrual as needing correction. The actual behavior was to reverse the original accrual posting entry and then post a brand new accrual in the next available open period. This resulted in an undesirable double accrual effect across different periods, causing discrepancies in financial reporting. This issue has been resolved. Unapproved Transaction Accrual postings will now correctly remain in the respective period where they were initially posted, even if that period is subsequently locked. The system will no longer generate unnecessary reversals and new accruals simply because the original posting period transitioned to a locked state.

FFA-1773 Accruals Not Reversed

Previously, an issue occurred where Unapproved Transaction Accrual postings were not being correctly reversed or aligned when a transaction's approval spanned across different accounting periods. In specific scenarios, such as when a transaction was created in one month but the period was subsequently closed before its approval, the system would generate multiple Unapproved Transaction Accrual entries without the necessary offset postings. This resulted in duplicate accruals across different periods without a corresponding reversal to clear the initial entry. This issue is now resolved. The logic has been updated to ensure that once a transaction is approved, all Unapproved Transaction Accruals receive an automatic offset posting. Furthermore, the system now ensures the accrual reversal always matches the posting period of the approved transaction.

FFA-1808 Accruals Not Reversed > Error: INVALID_FLD_VALUE","message":"You have entered an Invalid Field Value xxx for the following field: postingperiod

Previously, the system encountered an INVALID_FLD_VALUE error when attempting to generate accrual reversals for transactions approved in periods that were subsequently closed. Specifically, when the 'FFA Accrual Posting Reversal/Deletion MR' script executed, it would attempt to post the reversal to the original period; if that period was closed, the process would fail. This left Unapproved Transaction Accrual postings stuck on the balance sheet without a corresponding reversal. This issue is now resolved. The system will now automatically identify the first open accounting period (or the current open period, depending on the account's Accounting Preferences setup) to post the reversal. This ensures that all approved transactions are properly reconciled without violating accounting locks or requiring the reopening of historical periods.

FFA-1812: SuiteTax Enabled > Accrual Posting Creation is Failing Due to Saved Search Formula Error

Previously, the saved search, 'FFA Unapproved Transactions to Accrue,' contained a numeric formula in its criteria that referenced the field netamountnotax. In environments where SuiteTax was enabled, this field reference caused the saved search to fail, which in turn blocked the execution of the 'FFA Accrual Posting Creation M' script. This resulted in the accrual process being fully halted. This issue has been resolved by updating the formula in the 'FFA Unapproved Transactions to Accrue' saved search criteria. The formula has been adjusted so that the error is resolved in SuiteTax environments while also maintaining the correct functionality for accounts without SuiteTax enabled, ensuring the accrual process runs correctly in all configurations.

FFA-1824 Delete Accruals Instead of Reversing Enabled > Accruals Not Reversed in Closed Periods

Previously, when the 'Delete accruals instead of reversing' preference was enabled with instant accrual creation, the system failed to properly clear accruals if the transaction approval occurred after the original accounting period had closed. In these instances, the 'FFA Accrual Posting Reversal/Deletion MR' script could not delete the original Unapproved Transaction Accrual due to period locks, yet it failed to generate a reversal as a fallback. This issue is now fully resolved. The logic has been updated to handle the transition between open and closed periods: 

  • Open Periods: If the original Unapproved Transaction Accrual posting is in an open period when the transaction is approved, the system will delete the Unapproved Transaction Accrual posting as intended. 
  • Locked & Closed Periods: If the original period is closed, the system will automatically switch to a reversal logic, creating an offset Unapproved Transaction Accrual posting in the first open or current open period to ensure the balance is cleared. 

FFA-1833: Approval Matrix Edit Mode Fails to Load When Subsidiary is Inactive

Previously, a critical error occurred when attempting to load an Approval Matrix record in Edit mode if the matrix was associated with a Subsidiary that had been set to inactive. Instead of loading the record, the page would become blank and unusable. This forced administrators to temporarily reactivate the subsidiary just to edit the matrix. This issue has been fully resolved. The Approval Matrix will now load correctly in Edit mode, even if the linked Subsidiary is inactive. The Subsidiary field on the matrix record will display as empty upon loading in Edit mode. Users must re-select an active Subsidiary before saving any changes to the Approval Matrix.

FFA-1856 Non-OneWorld > Creating Accrual Posting > TypeError: Cannot read property 'save' & 'currency' & 'value' of undefined

Previously, in non-OneWorld NetSuite environments, the 'FFA Accrual Posting Creation MR' script would fail to generate accruals, resulting in various TypeError messages. This was because the script logic was attempting to reference subsidiary-specific fields (like functional currency) that do not exist in single-entity, non-OneWorld accounts. As a result, no postings were created. This issue is now resolved. The system logic has been updated to be fully compatible with non-OneWorld accounts resulting in successful creation of accruals.

Was this article helpful?