NorthScope 2026.04.30

Software Version: 2026.04.30 Database Version: 2026.04.30

Release Date: Apr 30, 2026

Improvement

Financial

NS-13846 - Applications: Fiscal Period Checks Now Mind Their Business

Fiscal period validation on AP and AR applications was a little overzealous. Even when nothing financially sensitive was happening, NorthScope would still step in to double-check whether the application date was in an open period—because apparently every action deserved a full audit.

We’ve refined the logic so the validation only kicks in when it actually matters:

• If you’re applying or modifying a Discount (AP) or Discount/Writeoff (AR), NorthScope will verify the application date is in an open fiscal period.

• If no discount or writeoff is involved, the system will step aside and let you proceed without unnecessary checks.

Same protection where it counts, less interference where it doesn’t. NorthScope now knows the difference between a critical accounting event and just getting out of your way.

Sales

NS-13793 - Unapplied Receivables: One Small Column, One Giant Leap for Sanity

After wrestling with a parade of bugs, we decided to take a brief victory lap with something refreshingly simple.

We’ve added a new column—“Doc No”—to the Unapplied Receivable Documents page. It’s displayed by default, right where you’d expect it, quietly doing its job without causing any trouble.

No drama. No side effects. Just a useful column showing the document number like it probably should have all along.

Bug

Fisherman Accounting

NS-13809 - Fish Ticket History: Long Names Welcome

If you had a Dual Permit Holder with a name longer than 20 characters, the Fish Ticket History Inquiry would throw a truncation error and refuse to cooperate. Apparently, anything beyond 20 characters was just too much personality for the system to handle.

We’ve fixed the limitation. The inquiry now supports Dual Permit Holder names up to 100 characters without error.

So go ahead—long names, multiple surnames, or that one fisherman who insists on using all of them—NorthScope can handle it now.

Inventory

NS-13805 - Item Mass Update: No More “While I’m Here, I’ll Delete This Too”

Using Item Mass Update to update attributes or properties had an unfortunate side effect: it cleared out a couple unrelated GL Account values that you never asked it to touch. Helpful? Not even a little.

We’ve fixed Mass Update so it now behaves like a well-trained assistant:

• Only the values you actually update will be changed.

• Everything else—like Purchase Clearing, Inventory Production Offset, and Inventory Valuation Gain/Loss accounts—will stay exactly as they were.

In short: Item Mass Update will update what you tell it to update… and leave the rest alone. A high bar, now successfully cleared.

NS-13813 - Item Delete: Attributes No Longer Chain It to the Floor

Deleting an unused Item record should be pretty straightforward: if it hasn’t been used in the system, it should be allowed to leave peacefully. But if that Item had attribute values, NorthScope was throwing a foreign key error and blocking the delete like a tiny database bouncer.

We’ve fixed the issue so unused Item master records can now be deleted as expected, even when they have attributes assigned. Items that have been used on transactions are still protected, of course. But unused Items that happen to have attributes? They can now exit without the dramatic paperwork tantrum.

Purchasing

NS-13825 - Purchase Orders: Lookups That Don’t “Clean Up” Your Data

Using record lookups on a Purchase Order (like Item, Purchase GL Account, or Distributed To) had an annoying side effect: after saving, a handful of unrelated header fields would quietly disappear. Because clearly, updating one field should definitely wipe out a few others for dramatic effect.

The PO fields impacted included:

• Ship Via

• Buyer

• Purchase Contact Name

• Ship Attention To

• Receive By

We’ve fixed the issue so using lookups will no longer clear out these values. Everything across the Home, Properties, and Attributes tabs will remain exactly as you entered it.

Sales Programs

NS-13781 - Sales Program Settlements: No More Payment Terms Meltdowns

Trying to process a Sales Program Settlement could result in a cryptic error about a PaymentTermSK conflict—which is not something anyone plans for when settling programs.

We’ve fixed the issue so Sales Program Settlements now process cleanly without running into Payment Term conflicts.nSeparately, we found and addressed the same underlying issue affecting AP Settlements, so those now process as expected as well.

NS-13838 - Sales Program Writeoffs: Stop Rewriting History

This one was a bit of a time traveler. After running a Sales Program Rebate settlement with a writeoff, some Sales Orders suddenly looked like they were posted a whole month later—even though the Ship Dates and GL Dates were all set to the correct date. Rude behavior from a calendar, honestly.

The writeoff journal was incorrectly updating the original Sales Order journal, changing its Journal Date, and clearing Journal Entry details. That’s not accounting. That’s a tiny spreadsheet goblin with a marker.

We’ve fixed it so:

• Sales Program Settlement writeoff journals are created separately, as expected.

• The original Sales Order journal remains untouched after posting.

• Journal Date, Journal Entry, and Journal Details stay exactly as they were.

Technical Changes

• No schema changes.

• No config file changes.