Best Of
Re: AskAGuruLive with Clarisa about Advanced Accounting (March 18, 2026)
TIP 3:
Revenue recognition rules define how revenue recognition plans are generated when an item is sold. The Create Revenue Plans On field on the Revenue Recognition/Amortization subtab of the item record determines when the plan is created. Take note that amount source should be compatible with the create revenue plans on field in the item.
One of the reasons why revenue plan is not generating is either the Create Revenue Plans On field is blank or the combination of Amount Source and Create Revenue Plans On values are invalid. When the combinations are invalid, an error message is logged in the Revenue Arrangement Message subtab for the revenue element. A link to the error message is included in the Revenue Recognition Errors portlet on the Revenue page. Valid combinations are shown in the following table:
Re: AskAGuruLive with Clarisa about Advanced Accounting (March 18, 2026)
Yes, it is mandatory. However, sometimes users with the Period Closing Management permission, when the Allow Quick Close of Accounting Periods preference is enabled, tend to close the period without redoing the tasks because it allows them to close one or more accounting periods with a single click. 😊
Re: AskAGuruLive with Clarisa about Advanced Accounting (March 18, 2026)
Enabling this feature does not significantly impact your current setup, however, please note the following important considerations:
Before enabling Multiple Calendars, if you have any open, standalone adjustment periods, you must modify them to overlap with existing non-adjustment periods.
Review the guidelines below to determine if changes are needed for other standalone adjustment periods:
- Future adjustment periods – Recommended
- Open adjustment periods – Required
- Historical, closed adjustment periods – Optional
You can disable this feature only if you have not yet assigned any new fiscal calendars to any subsidiaries.
Before enabling Multiple Calendars to Production, I highly suggest that you test it first in your Sandbox account.
For more information about the function of Multiple Calendars and Fiscal Calendars, please refer to SuiteAnswer articles below:
Re: AskAGuruLive with Clarisa about Advanced Accounting (March 18, 2026)
TIP 2:
If you’re on Advanced Taxes and the transaction isn’t picking up the right tax code, here are some of the steps you can check to troubleshoot:
1) Start with the Customer record
- Confirm whether the customer is marked taxable (for US nexus).
- Check if there’s a tax item assigned to the customer. If there is, this is the highest hierarchy in the lookup, so it may be what’s getting pulled onto the transaction.
2) Verify the shipping address is complete
- Make sure the customer has a valid shipping address, check if country, city, state, and zip code fields are populated. Missing values here can prevent the correct tax determination.
3) Confirm tax lookup is enabled:
- Go to Setup > Accounting > Set Up Taxes
- Check that ENABLE TAX LOOKUP ON SALES TRANSACTIONS is set to True
4) Check Nexus setup for the Subsidiary
- Make sure the correct nexus is associated with the transacting subsidiary: Subsidiary record > Nexuses tab (add it there if it’s missing).
Re: AskAGuruLive with Clarisa about Advanced Accounting (March 18, 2026)
Hi Nickey,
When you reopen a period, you may need to redo checklist tasks to close the period. Any later closed periods are automatically reopened and checklist tasks for those periods may need to be redone as well before you can close them.
Best practices when you reopen a period include:
- Avoid backdating transactions.
- Don't close an accounting period until the cost recalculation is complete. This includes the standard month-end closing.
- If you backdate a transaction to a date within a closed period, you should first open the closed period before saving the backdated transaction.
- If you post a Transaction in foreign currency and/or intercompany impact, you should re-run the following tasks: Revalue Open Foreign Currency Balances, Calculate Consolidated Exchange Rates & Eliminate Intercompany Transactions to make sure that the balances are correct for the period.
Hope this helps! 😊
Re: AskAGuruLive with Clarisa about Advanced Accounting (March 18, 2026)
Thank you for your question, Nickey! Do you have Multiple Calendars enabled? If yes, you can create a fiscal calendar then assign it to the Subsidiary. If this is not your case, and you will be changing your Fiscal Year Structure, it would entail deleting some of your Accounting Period and Fiscal Quarters.
Requests involving change of an Accounting Period that already have historical transactions should be coordinated with our NetSuite Professional Services Team.
Change in an Accounting Period most especially those which already have records in it would involve modifying child accounting periods and clearing of associated transactions. The impact of such modifications should all be considered first before proceeding with the change. 😊
Re: AskAGuruLive with Clarisa about Advanced Accounting (March 18, 2026)
TIP 1:
If you want to pull allocation details from a Revenue Arrangement (Revenue Elements tab > Allocation Details subtab), the easiest way is to build a Transaction Saved Search. Here’s how you can do it:
1. Go to Lists > Search > Saved Searches > New.
2. Choose Transaction
3. On the Criteria tab (Standard subtab), set:
- Filter: Type: Revenue Arrangement
4. Then switch to the Results tab and look for the joint field Allocation Detail Fields…
5. When the pop-up opens, select the allocation detail columns you want to show in the search results, then Save.
Re: AskAGuruLive with Clarisa about Advanced Accounting (March 18, 2026)
Hi Robert,
This feature is handled by our Order to Cash Team, however, I also checked your concern internally and noted that as confirmed by our Product Management team, the new feature will not be made available in the Release Preview environment. This is due to current AI infrastructure limitations that prevent the feature from being supported in that environment.
Hope this clarifies your concern 😊
Re: Asset Summary Report > Include the reversed disposed asset
Hi @User_CN4QU
Even though you have successfully reversed the GL impact and changed the Asset Status back to Depreciating, the Asset Summary Report in the FAM module doesn't just look at the current status or the GL. The report relies on the background FAM tables—specifically the FAM - Depreciation History records and the background disposal fields on the Asset Record (like Disposal Date, Disposal Type, and Quantity Disposed).
Because the disposal was only reversed via a Journal Entry and not deleted from the FAM subledger, the system still sees the historical "Disposal" event and pulls it into the Disposed column.
To completely remove the asset from the Disposed column and get it sitting correctly in your current listing, you will need to manually clean up the underlying FAM records.
Step 1: Delete the "Disposal" Depreciation History Record
The amount sitting in the Disposed column on the report is being pulled directly from the depreciation history record created during the mistaken disposal.
- Open the affected Asset Record.
- Go to the Depreciation History subtab.
- Look for the line where the Transaction Type is Disposal (there may also be a write-off/depreciation line created on the exact same date—you will want to identify the ones tied specifically to the disposal action).
- Click View or Edit on that history record.
- Hover over the Actions menu and click Delete.
Step 2: Clear the Disposal Fields on the Asset Record
Because the system still thinks the asset was disposed of, it is holding values in specific read-only fields. You must clear the Disposal Date, Disposal Type, and Quantity Disposed, and ensure the Quantity field is set back to its original amount.
Since these fields (along with Reversal Date) are usually read-only on your default form, you have two options to change them:
- Option A (Custom Form): Temporarily customize your FAM Asset form (top right Customize > Customize Form). Go to the Fields tab, find Disposal Date, Disposal Type, Quantity Disposed, and change their Display Type from "Inline Text" or "Disabled" to Normal. Save the form, clear the fields on the asset record, restore the original Quantity, save the asset, and then revert your form settings.
- Option B (CSV Import): Run a CSV update on the Fixed Asset record. Map the Internal ID of the asset, and map the Disposal Date, Disposal Type, and Quantity Disposed fields to be completely blank (or 0 for quantity disposed). Map Quantity back to the original total.
Step 3: Refresh the System Cache for this Asset
To force NetSuite to recalculate and recognize that this asset is fully active again without any disposal ties:
- Edit the Asset Record, uncheck Depreciation Active (set to False), and Save.
- Edit the Asset Record again, check Depreciation Active (set to True), and Save.
- (Optional but recommended) Go to Fixed Assets > Setup > System Setup and click Precompute Depreciation Values to regenerate the forecast cleanly.
Re: Unexpected behavior on findSublistLineWithValue()
Hello,
Upon checking related concern they mentioned that it appears that the behavior of how values are accepted in the findSublistLineWithValue(options) function has changed starting in the 2026.1 release, and this change was not previously documented.
As referenced in SuiteAnswer 45391, the options.value parameter supports multiple data types (number, Date, string, array, boolean). However, the specification only defines the accepted types and does not guarantee that implicit type conversion will occur based on the target field.
Here’s a comparison of the behavior across releases:
- 2025.2: Implicit conversion (e.g., number to string) was observed, although this was not officially documented.
- 2026.1: The behavior now enforces strict type matching based on the field definition. For example, a field defined as NUMBER (such as
refnumber) requires a numeric value or TEXT field requires string value
This updated behavior in 2026.1 aligns more closely with type-safe expectations, while the automatic conversion seen in 2025.2 appears to have been an undocumented implementation detail.
Hope this helps clarify the behavior you’re encountering.










