3.1 Features That Need NetSuite Support

The March 2024 SuiteFoundation study guide asks you to identify NetSuite features that require NetSuite Support intervention. The study method is narrower than a tour of every checkbox. Review the SuiteAnswers topics on enabling Multi-Location Inventory and the other Enable Features topics, and know that some features cannot be fully undone by an administrator after transactions exist. An administrator still does the turning-on. The page is Setup > Company > Enable Features. Several current Help topics reach that same page through Setup > Company > Setup Tasks > Enable Features. Checking a box makes a capability available. Clearing the box later depends on which feature you chose and on the transactions or quantities already saved.

This chapter stays with the two examples NetSuite's own materials use. The March 2024 study notes name Multi-Location Inventory as the inventory example, and the October 2024 sample test uses Multi-Subsidiary Customer as the customer example. Oracle NetSuite Help does not hand you a longer catalog of features that Customer Support must enable, so this chapter does not invent one. Where Help is silent, do not add a Support requirement. Help does require Customer Support for one specific action below, and it does not require Customer Support to enable or disable Multi-Subsidiary Customer. NetSuite's materials still use both features as the published examples: one shows a Support call after inventory has been distributed, and the other shows a feature an administrator cannot fully undo until the related transactions and subsidiary assignments are cleaned up.

Multi-Location Inventory and the quantities you already own

Multi-Location Inventory associates each inventory item and each inventory transaction with a location. You can track purchasing cost, sales income, on-hand quantity, and value for an item in each location, and you can transfer inventory between locations. Reports can filter inventory status, revenue, valuation, activity, and fulfillment by location, depending on the other features in the account. That reporting power is the reason companies turn the feature on. It is also the reason they need a plan before they do it.

Help tells administrators to understand the feature before they enable it. The Locations overview says to read the Multi-Location Inventory topic and decide whether it fits the company. The practical reason is the stock you already have. Enabling the feature does not leave those quantities in a company-wide bucket you can label during a later weekend. After the feature is on, unallocated inventory items are treated as sitting in a null location. Help says to distribute any unallocated inventory before you enter those items on inventory transactions. Until that happens, the quantity is not ready for ordinary inventory activity.

That placement is an Inventory Distribution. The transaction allocates inventory from its original, unassigned state to one or more locations and updates item details and quantities for the locations you choose. A simple distribution sends stock to a single location. A manual distribution lets you enter the quantity for each location. Help recommends doing the work during non-peak hours, distributing all unassigned inventory at one time, and avoiding changes to transactions dated before the distribution. If you change those earlier transactions and then return to distribution, the undistributed quantity can look wrong or negative. The documented correction for that error is an inventory adjustment at Transactions > Inventory > Adjust Inventory. Inventory is distributed only when the stock level is zero or greater. None of those details is optional color. They show why an administrator who checks the box without a location plan immediately owns a data-cleanup project.

An administrator enables the feature. Nobody files a Support case just to check it. Help's inventory-setup table for inventory with Multi-Location Inventory lists the prerequisites by subtab: Locations on the Company subtab; Sales Order, Advanced Shipping, and Advanced Receiving on the Transactions subtab; and Inventory plus Multi-Location Inventory on the Items & Inventory subtab. The Items & Inventory feature list states the same dependency in shorter form. You also need Locations, Inventory, Advanced Shipping, and Advanced Receiving. Enabling Multi-Location Inventory creates system-generated Transfer Orders and Inventory In Transit accounts. Locations themselves are a separate checkbox. Go to Setup > Company > Enable Features, open the Company subtab, check Locations, and save. A location record means an office or a warehouse. Help says not to use a location record for a bin, shelf, or dock inside a warehouse, because that choice causes problems with fulfillments, LIFO and FIFO costing, and reporting. Bins belong to the bin features.

The point where Customer Support enters

Help draws the Support line at disable time, not at enable time. After you enable Multi-Location Inventory and distribute items, you cannot turn the feature off without contacting NetSuite Customer Support. The same warning appears on the inventory setup comparison and on the Items & Inventory subtab. Help does not say Customer Support must check the box. OneWorld adds a planning consequence rather than a different enable path. Help says the Multi-Location Inventory feature is required for NetSuite OneWorld accounts that use the Inventory feature. That is a requirement to track item quantities by location. It does not make a warehouse into the legal entity, and it does not mean the Locations checkbox and the Multi-Location Inventory checkbox are the same switch. The next section separates those ideas.

For this objective, remember the sequence. An administrator turns the feature on. Existing unallocated quantities must be placed into locations before they are used on inventory transactions. After that distribution, Customer Support is who Help tells you to contact if the feature needs to be turned off. An administrator who treats the original checkbox as a switch that can be cleared on Friday afternoon is describing a different product than the one Help documents.

Turning off Multi-Subsidiary Customer

Multi-Subsidiary Customer is a OneWorld feature. It lets one customer record be shared across subsidiaries, so a transaction can use the customer's primary subsidiary or an assigned secondary subsidiary. An administrator enables it without a Support case. Go to Setup > Company > Enable Features. On the Company subtab, in the ERP General section, check Multi-Subsidiary Customer and click Save. Help blocks that enable when an incompatible feature is already on. The incompatible list lives in the Multi-Subsidiary Customer limitations topic. Do not guess the names of those incompatible features on the exam. Know that the box is not always available, and know what the box does once it is saved.

The standard customer form then shows a Subsidiaries subtab. The primary subsidiary is already listed. Each additional subsidiary has to be added on its own. Subsidiaries underneath a subsidiary do not inherit the customer automatically. You can add another subsidiary later. When someone selects the customer on a transaction, the subsidiary defaults to the primary subsidiary, and the user can change it to an assigned secondary subsidiary. Help documents that, on many of the transaction types that support this feature, the subsidiary cannot be changed after the transaction is saved. That lock is why a wrong pilot invoice cannot be repaired by editing the subsidiary field. The transaction has to be reversed or deleted.

Disabling the feature is also an administrator action, but only after the data is eligible. Help lists a fixed sequence. First, reverse or delete all transactions related to customers and their secondary subsidiaries. Second, remove all secondary subsidiaries from customer records. Third, return to Setup > Company > Enable Features, open the Company subtab, clear Multi-Subsidiary Customer in the ERP General section, and click Save. A related rule explains why the first step cannot be skipped. You can remove an assigned subsidiary only when no transactions are linked to that customer and that subsidiary. You also cannot remove the assignment when the customer is also a vendor and vendor transactions exist for that subsidiary. The vendor case is an extra blocker. It does not replace the two cleanup steps.

The October 2024 sample treats those first two steps as the correct pair. Reverse or delete the transactions tied to customers and their secondary subsidiaries, and remove all secondary subsidiaries from the customer records. Two ideas that look tidy are not the procedure. Inactivating the customer leaves the record, the secondary-subsidiary assignments, and the transactions in the account. An inactive customer drops off lists used on new transactions, which is useful when you stop selling to someone, and it is a different task from disabling this feature. Leaving the primary subsidiary and one secondary subsidiary in place also fails the rule. Help says to remove all secondary subsidiaries, not to keep a single extra subsidiary for later.

Cleanup for one shared customer before go-live

Picture a distributor that enabled Multi-Subsidiary Customer for one shared customer, Harbor Retail, during a pilot. The US subsidiary is the primary subsidiary. The Canada subsidiary was added as the only secondary subsidiary so the team could enter one Canadian invoice. The project is still before go-live. The steering group has decided that Canada will not share customer records, and someone asks the administrator to turn the feature off before cleanup week ends.

The Canadian invoice, and the sales order that led to it, are transactions tied to Harbor Retail and the secondary subsidiary. Clearing the feature box while those transactions remain is the trap of deleting the feature flag while secondary-subsidiary transactions are still in the account. Inactivating Harbor Retail fails for a different reason. The name would disappear from new transaction lists, and the Canada assignment plus the posted activity would still be there. Keeping both the US subsidiary and the Canada subsidiary on the customer, then clearing the box, fails the requirement to remove every secondary subsidiary. Deleting the primary subsidiary and leaving Canada behind is the same kind of mistake in the other direction. The primary subsidiary is not the assignment Help tells you to strip off.

The cleanup that matches Help, and that matches the sample key, has two parts, in that order. Reverse or delete the transactions tied to Harbor Retail and the Canada subsidiary. Then open the customer and remove every secondary subsidiary, which in this pilot means remove Canada, so the customer no longer carries a secondary subsidiary. The primary subsidiary remains. If any other customer still has a secondary subsidiary, or any secondary-subsidiary transaction is still in the account, the account is not ready for the final clear. Only after that cleanup does the administrator return to Enable Features and clear Multi-Subsidiary Customer. Help does not insert a Customer Support step into this disable path. The administrator can finish it, and the administrator cannot finish it early.

Which changes an administrator can still finish

Sort an Enable Features change with three questions. Did an administrator turn this on from Enable Features? Does saved data have to be reversed, deleted, or placed into locations before the box can be cleared? Does Help name Customer Support as the way to turn it off?

Locations, Departments, and Classes are administrator features on the Company area of Enable Features. Turning Locations on creates a classification for offices and warehouses. It does not, by itself, distribute inventory quantities into those places. Multi-Location Inventory is also turned on by an administrator, on the Items & Inventory subtab, after the prerequisite features are on. The follow-up work is mandatory. Existing unallocated quantities sit in a null location until an Inventory Distribution places them, and after that distribution Help requires Customer Support to turn the feature off. Multi-Subsidiary Customer is turned on by an administrator and, after the two cleanup steps, turned off by an administrator. The cleanup is not optional, and it is not an instruction to inactivate the customer.

Traps that miss the objective

The first trap is thinking every checkbox is reversible. A box you can check in a sandbox is not automatically a box you can clear after the first invoice or the first inventory distribution. Read the feature's own warning before you tell a client that the choice can always be undone by the same role. Multi-Location Inventory is the published example of a feature that passes out of the administrator's hands once items have been distributed. The administrator enabled it. Customer Support is required to disable it after that point.

The second trap is clearing Multi-Subsidiary Customer while secondary-subsidiary transactions remain. Help will not treat that clear as complete, because a secondary subsidiary cannot come off the customer while transactions for that pair still exist. Inactivating the customer, or leaving one primary subsidiary and one secondary subsidiary in place, are distractors. They feel like progress because the customer list looks quieter or the subsidiary count looks smaller. They are not the procedure. Both cleanup actions are required, and they apply to every customer that received a secondary subsidiary, not only to the one customer in the pilot story.

Use the study guide's framing when the question says a feature needs NetSuite Support. The guide tells candidates to identify those features and points them at Multi-Location Inventory and the Enable Features topics. The October 2024 sample test adds Multi-Subsidiary Customer as a feature that cannot be fully undone while transactions exist. Answer with the behavior Help actually documents. Do not lengthen the list with feature names this objective did not give you.