Best Of

Hello @User_6YI1X,

Hope you are well. ?

Upon further testing, we noted that the Vendor: Country on the Criteria is the one causing the issue. Joining a field having one-to-many or many-to-many relationship can lead to multiplication of results. Using joining fields on the Criteria is not usable in summarized search, or when you'll use Sum as Summary Type.

For workaround, you can remove the said Criteria filter or export the Saved Search in Excel and make summary report there. Thank you for your understanding on this one. ?‍♀️

Hi @TeresaC- 2025

• NetSuite calculates sales tax based on the Ship To address. If this specific order is shipping to a state, province, or country where your company does not have a registered Tax Nexus, NetSuite will default the tax to $0.
• Even if the customer is set to "Taxable", if the specific items on this Sales Order are marked as non-taxable, no tax will calculate.
• Check the individual line items have the wrong tax code applied

Hi @User_9VVSQ,

Yes, this can be handled using standard NetSuite functionality.

You can achieve the required view by:

• Selecting the required Subsidiary in the Subsidiary Context (for consolidated view)
• Adding Location in the Footer Column filter

This allows you to view the P&L values both subsidiary-wise and location-wise in the same report.

I ended up figuring out that the internal id for the location value I was using has to be a string value, not a number, but only for the WFA script. In the console/client side, it could be a number and still work.

I still find it odd that it behaves differently based on execution method…

Hello @maffooclock,

Good day.

1. Created From field is not available in the Opportunity Record.
2. A 'cases' sublist does not exist in the Opportunity Record as of SuiteScript version 2025.2.
3. You can access the Related Transactions for Opportunity records using N/search module to search for cases related to the transaction record. Here's a sample code that you can use as a reference:

I hope this helps!

Hi @User_NQL2C

NetSuite has created a specific SuiteApp/Bundle to solve this problem. It installs a custom role that mirrors the Administrator's breadth of access but downgrades all permission levels to View. This allows your consultant to see how features, accounting preferences, and workflows are configured without the ability to change them.

1. Log in to NetSuite using your Administrator role.
2. Go to Customization > SuiteBundler > Search & Install Bundles
3. In the Keywords box, search for Admin View or enter the Bundle ID 387772 (officially named the "Administrator - No HR/Employee Access Role" bundle)
4. Click on the bundle and select Install.
5. Once installed, go to the consultant's Employee record, navigate to the Access tab, and assign them this newly installed custom role.

I suggest you add SDF in your Visual Studio Code and import an object script to see and example. For example:

Use the below command and get an object (script) to see
suitecloud object:import -i

Hi @Trixie Amora-Oracle ,

Thank you for sharing the Info. However, this is not our case.

We have investigated and found that the warning is triggered due to a workflow that automatically sets the Location field on the Assembly Build form. Because this location is populated after the form loads, NetSuite does not re-run its internal component availability check. As a result, the system temporarily assumes insufficient stock and displays the warning, even though enough components are available. So that it still proceeds and completes the build successfully.

Recommended Solutions

1. Remove the location auto-population workflow
   1. Allow users to select the location manually
2. Change location to any other available location and then change it back to the appropriate location
3. Use the normal navigation route of Transactions--->manufacturing--->Build Assemblies to avoid this error pop up.

Hello, as checked internally, this is possibly a system limitation related to an existing enhancement: 287759 Reallocate Items Page > Special Work Order Items > Commit Column Greyed Out

In the past, we have filed defects for outsourced manufacturing cases for customers being unable to commit sub-assembly items with work order created from another location then transferred to the Top Assembly Work Order Location. Example: Defect#643096 Special Order items receiving and transferring > Not committing to Work Order/Sales Order after being received
However this was closed and confirmed as currently a system limitation related to Enhancement:287759

If this is the same scenario as the one you are describing, you can vote in the SuiteIdeas page for it to be considered in the roadmap for future releases. (SA 10054)

Hi @Adinath_Bodakhe we have implemented same for one of the client,

Transaction 1: Bill Credit Approvals

Bill Credits to post immediately, we will intercept the save process to neutralize the financial impact.

1. Custom Field Creation:

• Transaction Body Field: Create an Approval Status field (List/Record: Pending Approval, Approved, Rejected). Default to Pending Approval.
• Transaction Line Field: Create a custom decimal field called Custom BC Amount applied to the Expenses sublist. Ensure this is hidden from the standard user interface.

2. Script Execution (Before Submit):

• Deploy a User Event Script on the Bill Credit record.
• Upon the Before Submit trigger (only on "Create" or when Status is "Pending Approval"), the script loops through the expense lines.
• The Logic: It captures the native Amount entered by the user, copies it into the hidden Custom BC Amount field, and then forcibly sets the native Amount to $0.00.
• Result: The Bill Credit saves successfully, but because the lines are $0, there is no posting impact to Accounts Payable or Expense GLs.

3. Approval & GL Trigger (Workflow / After Submit):

• Create a simple Workflow to route the transaction to the approver.
• When the approver clicks "Approve", the Approval Status changes to Approved.
• A Workflow Action Script (or a trigger in the User Event Script) loops back through the lines, retrieves the value from Custom BC Amount, and populates it back into the standard Amount field.
• Result: The transaction updates, the $0 lines are replaced with the actual amounts, and the accurate financial impact is finally posted to the GL.

Transaction 2: Bank Transfer Approvals

We will apply the exact same logic to the Transfer Funds transaction.

1. Custom Field Creation:

• Transaction Body Field: Create an Approval Status field.
• Transaction Body Field: Create a custom decimal field called Custom Transfer Amount.

2. Script Execution (Before Submit):

• Deploy a User Event Script on the Bank Transfer record.
• When a user clicks save, the script captures the native Transfer Amount, stores it in the Custom Transfer Amount field, and changes the native Transfer Amount to $0.00.
• Result: The Bank Transfer records the "From" and "To" accounts but moves $0 between them, meaning the bank balances remain untouched.

3. Approval & GL Trigger:

• Upon Approval, the script retrieves the value from Custom Transfer Amount and pastes it back into the native Transfer Amount field.
• Result: The true amount is processed, and the funds are officially moved between the bank accounts.