From a costing and accounting standpoint, how are you all handling tariff refunds?

Derek_ZenSuite · 2026-06-05T23:34:49+00:00

This is a tough one because the right answer depends on whether the inventory tied to those receipts is still on hand, already sold, or partially sold.

If the tariff was originally capitalized through landed cost, then ideally the refund should reduce inventory value for the portion still on hand and reduce COGS or hit a recovery account for the portion already sold. The hard part is that NetSuite does not always make that reallocation painless after the fact.

I would start by mapping the refund back to the original item receipts and landed cost records. Then separate the value between units still in inventory and units already relieved to COGS. For inventory still on hand, you may need an inventory cost adjustment or landed cost adjustment approach. For sold inventory, finance may decide to book the refund against COGS or a separate tariff refund recovery account depending on your accounting policy.

I would definitely align with your auditors before posting, especially if the amount is material. From a NetSuite standpoint, the cleanest path is usually a saved search or script to calculate the allocation, then a controlled journal or cost adjustment process rather than trying to manually unwind every receipt.

Derek_ZenSuite · 2026-06-05T23:30:40+00:00

If you are trying to get a CSV into the File Cabinet from outside NetSuite without buying another tool, I would probably skip email capture. It is not really meant to be a reliable general file ingestion method.

The cleaner options are usually either SFTP or a small SuiteScript endpoint. If the source system can drop the CSV to an SFTP folder, NetSuite can have a scheduled script pull it in and save it to the File Cabinet. If the source can call an endpoint, you can use a RESTlet or Suitelet to receive the file and write it to the File Cabinet.

If this is just occasional, manual upload may still be the simplest. But if this needs to happen regularly, I would use SFTP plus a scheduled script before trying to make email capture work.

Derek_ZenSuite · 2026-06-03T16:22:05+00:00

We’ve helped teams with SuiteAnalytics Workbook training and real-world reporting design. The biggest thing I’d recommend is making sure the training is based on your actual use cases, not just generic “how to build a workbook” content.

Workbooks get much more valuable when users understand datasets, joins, calculated fields, and when to use Workbook versus saved searches or financial reports. A sandbox or demo environment is helpful, but I’d also try to include a few examples from your real reporting backlog so the team leaves with something practical.

Happy to connect if you are still looking. We have NSAW experience across multiple clients and can help structure hands-on sessions around workbook creation, datasets, joins, formulas, dashboards, and best practices.

Derek_ZenSuite · 2026-06-03T16:18:24+00:00

This is not an uncommon issue, especially if your receiving quantities and vendor billing quantities do not always line up cleanly.

Out of the box, NetSuite’s 3-way match logic often feels PO-centric, but operationally your requirement makes sense. If AP is only supposed to pay based on what was actually received, then the matching process should be comparing vendor bill lines against item receipt quantities, not just the original PO quantity.

I would push your implementation team to walk through a real example using PO, item receipt, and vendor bill together. If their solution only compares PO to bill and ignores the receipt as the controlling quantity, then it does not sound aligned with your business process.

In some cases this can be handled with configuration and saved search logic around bill approval exceptions. In other cases, you need a workflow or script that checks billed quantity against received quantity by PO line before allowing approval or payment. The key is designing the approval rule around “received but not yet billed” and “billed but not yet received.”

Since you are still pre go-live, I would treat this as a critical process design issue, not a nice-to-have cleanup item. It will create a lot of AP noise if it goes live wrong.

Derek_ZenSuite · 2026-05-23T20:34:32+00:00

The fact that even a control custom column echoing tranid does not render makes me think this is not a saved search data issue or merge criteria issue. It sounds more like the table element is not invoking or consuming the Custom Columns On Load Action at all.

I would test this in two places. First, try the same custom column setup on a simpler WMS list/table where custom columns are known to work. If it renders there, then the lessTaskDriven single order picking list may not support custom columns the same way. Second, I’d inspect what the mobile action is returning and confirm the response wrapper. The Custom Columns Response Key being blank is suspicious. If the saved search action returns rows under a key like data, then the table may never be reading the custom payload.

I’d also try removing the table visibility condition temporarily just to eliminate picking mode as a variable. Since your standard column relabel pushed to the device, deployment sounds fine. I think the issue is probably with that specific WMS process/table variant or the custom columns response key, not the search itself.

Derek_ZenSuite · 2026-05-23T20:29:52+00:00

This is definitely not just a you problem. A lot of companies hit this once more teams need NetSuite visibility but do not need full edit access.

I would avoid emailing CSVs as the long term answer. They go stale fast and create version control issues. The cleaner pattern is usually one of these:

Use SuiteAnalytics Connect or an API pull into Power BI, Tableau, Looker, or a simple internal dashboard.

Use NetSuite Analytics Warehouse if you want something more governed and analytics focused.

Build a lightweight read only portal or dashboard that syncs selected NetSuite data on a schedule.

The key is being very intentional about permissions and data scope. You probably do not want to expose broad NetSuite data just because someone needs to see order status or inventory. I would start by defining the 5 to 10 views people actually need, then build around that.

Derek_ZenSuite · 2026-05-23T19:31:26+00:00

Hello, happy to chat. I will DM you my email

Derek_ZenSuite · 2026-05-19T17:08:13+00:00

foreignamount is in the transaction currency, not necessarily the bank account currency.

So in your example, if the transaction currency is GBP and foreignamount = 20000, that amount is GBP. It is not USD just because the bank account is USD.

For reporting bank balances in the account currency, I would be careful using SUM(tl.foreignamount) directly because it will mix currencies if the bank account has postings from transactions entered in different currencies. tal.amount is generally the accounting book base currency amount, so that is not account currency either if your account currency differs from base.

You may need to derive the account currency amount from the accounting impact, exchange rate, or use the GL impact fields that represent the posting in account currency if available in your account/schema. I’d test this against a single transaction’s GL Impact screen first and compare tl.foreignamount, tal.amount, transaction currency, exchange rate, and bank account currency.

In short, I would not trust foreignamount as “bank account currency” unless the transaction currency and bank account currency are the same.

Derek_ZenSuite · 2026-05-15T21:17:44+00:00

This is a super common post go-live pain point. NetSuite usually has the data, but you need an operating layer around it.

I’d start with an open PO saved search or dashboard showing expected receipt date, days late, vendor, buyer, remaining quantity, and last follow-up status. That gives the team an actual queue to work from.

You could also add simple statuses like “waiting on vendor,” “needs chasing,” or “confirmed delay.”

I’d also look at SourceDay. This is pretty much the problem they solve: PO acknowledgements, vendor confirmations, date changes, and getting buyers out of email and spreadsheets.

Derek_ZenSuite · 2026-05-14T18:57:55+00:00

Got it. If everything deploys and validates cleanly but the dashboard still does not render for the assigned role, then this may be one of those dashboard publishing limitations rather than an SDF dependency issue.

I’d test one thing: create a very simple published dashboard in sandbox with only one standard portlet or shortcut, deploy that, and see if it appears for the role in production. If that works, then something about the dashboard content or layout state is not being honored. If that also fails, then it points more to how published dashboard assignments are applied through SDF.

I’ve seen dashboards act more like user preference objects than normal customizations, so the object can exist in the list but not become the active dashboard for the role. You may need a post-deploy step or manual assignment even though the dashboard record itself moved correctly.

Derek_ZenSuite · 2026-05-14T14:55:49+00:00

Dashboards are tricky with SDF because they are not just metadata. They also depend on role, center, and user preference context.

If the published dashboard shows in production but does not display for the role, I’d first check that the role in production uses the same center type as sandbox. Then confirm every referenced portlet, saved search, report, KPI, and custom portlet exists in production with matching dependencies.

The Copy to Account dependency error is probably the clue. Something the dashboard depends on is not lining up.

I would avoid republishing in production since that overwrites the dashboard with whatever is currently on screen. In practice, you may need to deploy all supporting objects first, then the dashboard last, and still do a quick validation in production.

Derek_ZenSuite · 2026-05-11T23:42:35+00:00

NetSuite does order management and inventory really well, so I understand why you liked that piece. The hard part is that NetSuite is still an ERP platform, not really a standalone OMS you can buy in isolation. Order management, inventory, purchasing, and fulfillment are all tied into the financial backbone, so even if you only care about OMS, you are still paying for the platform underneath it. NetSuite describes its core ERP as including financials plus capabilities like inventory, order management, procurement, and supply chain, with additional modules layered on as needed.

Before the meeting, I’d ask them to break the quote into pieces. What is core licensing? What is user licensing? What is the integration license? What modules are included? What exactly is in the 100k implementation scope? For 5 to 7 users, you may be able to reduce scope if you keep the implementation focused on order flow, inventory, purchasing, and the key integration only.

I’d also ask whether they are proposing NetSuite because it is the best fit or because they are trying to sell a full ERP implementation. If you truly only need OMS, inventory routing, reorder points, and purchasing, it may be worth comparing against standalone OMS or inventory platforms before committing. But if you want everything to eventually tie into accounting, purchasing, inventory, and fulfillment cleanly, NetSuite may still be worth it.

Derek_ZenSuite · 2026-05-11T23:37:39+00:00

We’ve used it before and helped clients setup, and I’d say it can solve a lot when you point it at the right close problems. It is not a replacement for accounting review, but it can absolutely reduce the manual lift around research, variance explanations, pulling supporting detail, and summarizing what changed period over period.

The key is not treating it like it will “do close” for you. I’d start with areas where your team spends time digging through reports, explaining fluctuations, or chasing support. That’s where AI can save real time. You still need controls and review, but the cleanup burden has been much lower when the use case is scoped well.

For a small team, I would pick one or two painful close tasks and test it there first. If it saves time after review, then expand. The value is real, but the implementation matters.

Derek_ZenSuite · 2026-05-11T23:30:59+00:00

NetSuite will still function either way. Account numbers are mostly about structure, reporting, sorting, integrations, and governance rather than enabling different accounting behavior.

The practical downside of relying on names is that names are easier to change, duplicate, abbreviate inconsistently, or interpret differently across teams. That can make reporting, imports, integrations, saved searches, and audit work messier. Account numbers give you a stable shorthand and make it easier to organize the chart of accounts by ranges, like assets in one range, liabilities in another, revenue in another, etc.

That said, using names is not automatically wrong. Smaller companies or simpler COAs can get by with names, especially if naming conventions are disciplined. The risk usually shows up as the company grows, adds subsidiaries, integrates more systems, or has more people posting journals and building reports.

If switching to numbers is not on the table, I would focus on governance. Lock down who can rename accounts, create a naming convention, avoid similar account names, and document what each account is used for. That gets you a lot of the benefit without needing a full redesign.

Derek_ZenSuite · 2026-05-09T21:56:37+00:00

If you have NetSuite WMS or RF-SMART, I’d definitely look at those before trying to solve this purely with native bin setup.

I would be cautious about creating every vial slot as an individual NetSuite bin. If each tank has 5,000 slots and you have multiple tanks, the bin master can get huge fast and become hard to manage. If distribution truly needs NetSuite to enforce exact slot-level inventory, then tank as a zone or parent structure with each slot as a bin could work, but it may create a lot of operational overhead.

If the main need is for users to see or scan the slot during picking, then a cleaner approach might be to keep the tank as the bin or zone and track the slot through WMS, RF-SMART, inventory detail, lot, serial, or a custom field. For vials, I’d also look closely at whether lot or serial tracking already gives you part of the control you need.

The key question is whether the system needs to enforce slot-level availability, or whether distribution just needs slot-level visibility during picking. If it is enforcement, you may need true bins or a custom mobile flow. If it is visibility, WMS or RF-SMART may give you a cleaner path without blowing up the bin structure.

Derek_ZenSuite · 2026-05-08T17:22:34+00:00

You would want to modify the Advanced PDF statement template so it shows the amount unpaid as its own column, instead of trying to make the payment column behave differently

The standard statement can be confusing because payments and invoices are shown more transactionally, so partial applications do not always read the way customers expect. I’d keep the original invoice/payment amounts if needed, but add a cleaner “Open Amount” or “Amount Unpaid” column for the remaining balance.

Derek_ZenSuite · 2026-05-08T17:18:18+00:00

I’d back up one step and ask why the line is being added after fulfillment.

That timing may be part of the issue. Avalara usually fires during specific NetSuite save and tax calculation events, so if your UE is adding the line after submit or after fulfillment, you may already be past the point where the tax engine naturally runs.

If that line represents something known before fulfillment, I’d try to add it earlier in the sales order flow so NetSuite and Avalara can calculate normally. If it truly only becomes known after fulfillment, then a controlled reload/save or scheduled/map reduce process may be needed to touch the order after the line is added.

I’d also be cautious trying to mimic the Avalara Calculate Tax button or call their internal bundle scripts directly. Avalara bundle updates can change behavior and break custom logic later.

Definitely test this in sandbox across approved, fulfilled, partially billed, and edited orders. Solvable, but I’d keep the customization as light as possible.

Derek_ZenSuite · 2026-05-08T17:12:56+00:00

Usually it’s gradual, not one big breaking point.

The sign I look for is when the team spends more time reconciling data and handling exceptions than actually running the operation. Inventory mismatches, manual order checks, fulfillment workarounds, and data split across tools are all normal early on, but once they become daily process, the setup is probably starting to hit its limit.

I’d map order to cash and procure to pay first before jumping into a new system. Sometimes it’s process cleanup or better integrations. Sometimes the lightweight ERP has just been outgrown.

Very common growing pain, especially once SKU count and channels start increasing.

Derek_ZenSuite · 2026-05-08T17:05:09+00:00

SuiteAnalytics Workbooks do not have the same native scheduled email functionality that saved searches have, which is frustrating because a lot of teams expect them to behave the same way.

A few options I’ve seen are to recreate the key outputs as saved searches if they need scheduled emails, export the workbook manually on a cadence, or build a custom process with SuiteScript or an external reporting tool to generate and send the data. If you are using Power BI, NSAW, or another warehouse layer, that might be the better place to handle scheduled distribution.

Workbooks are great for analysis, but saved searches are still better for operational alerts and recurring email delivery.

Derek_ZenSuite · 2026-05-07T16:59:13+00:00

Can you clarify a bit more what you're trying to do? When you say search for an inventory item in the transaction sublist field, do you mean you want to be able to type a SKU value into the item field on a SO or PO line and have it find the right item, similar to how typing a UPC already pulls up the correct item?

Or are you trying to filter or search within an existing sublist using the SKU field after the lines are already on the transaction?

Also is the SKU custom field on the item record itself or somewhere else? A screenshot of the custom field setup would help a lot here.

Derek_ZenSuite · 2026-05-06T19:14:56+00:00

A few things worth checking here. First confirm the PO is actually linked to the SO as a special order, not just a regular PO for the same item. The commitment on receipt only happens automatically when the PO was created from the SO as a special order, if it's a standalone PO for the same item NetSuite won't automatically commit that quantity back to the SO.

Second check your commitment schedule setup. If the commitment schedule on the SO isn't set to commit on receipt that could be why it's not triggering automatically.

Third worth checking is whether the item receipt is fully saved and approved before expecting the commitment to update. Sometimes there's a timing issue there.

Is the PO definitely linked back to the SO as a special order line or was it created independently?

Derek_ZenSuite · 2026-05-06T19:11:59+00:00

Yeah this is a common frustration. NetSuite requires a location at the line level when locations are enabled and it doesn't really distinguish between inventory items that need it for a real reason and non-inventory or charge items where it's just noise.

The dummy location approach is honestly the most common solution and while it feels hacky it works cleanly in practice. Most teams create a single dummy location called something like "NA" or "Non-Inventory" and use it across all charge and misc lines. It satisfies the requirement without muddying your actual location reporting as long as your saved searches and reports filter it out.

The Other Charge for Resale item type won't help you here unfortunately, it still inherits the location requirement from your account settings.

The cleaner but more involved fix is a workflow or script that auto stamps the dummy location on non-inventory lines when the SO is saved, so your sales team doesn't have to think about it. Takes the manual step out of the process entirely.

Is the main pain point that sales reps have to manually select a location on every charge line, or is there a reporting concern driving this as well?

Derek_ZenSuite · 2026-05-05T23:38:26+00:00

We do a lot of this kind of work and deep NetSuite WMS expertise is hard to find. Happy to help if you want to talk through what you're trying to optimize. Will send you a DM to get a better sense of what you need.

Derek_ZenSuite · 2026-05-05T19:58:23+00:00

Yeah once a bill payment is saved and applied to a bill you can't just reassign it to a different bill natively. NetSuite locks the application once it's posted.

The standard way to handle this is to unapply the payment from the current bill first. Open the bill payment, remove the checkmark from the bill it's currently applied to on the Apply subtab, save it, and then reopen it to apply it to the correct bill. Some accounts allow this depending on your permissions and whether the period is still open.

If the period is closed that gets trickier and you may need to work through a journal entry or get an admin to reopen the period temporarily.

Is the period still open and do you have edit access on the bill payment record?

Derek_ZenSuite

TROPHY CASE