NorthScope 2025.10.20
(Software Version: 2025.10.20 Database Version: 2025.10.20
Release Date: October 20th, 2025
New Feature
Financial
NS-10851 - Check Register Inquiry: Voids Gained a Little Sanity
You know that feeling when you void a payment and suddenly the Check Register Inquiry insists on showing the original amount and the void in the same sign? Rage? Why can’t the inquiry show the void amount as a negative so the original and void sum to zero?!
We’ve taught NorthScope some better manners. Now, when you void or reverse a payment, the Check Register Inquiry will show the original transaction amount as a positive and the void as a negative. And if the void came from a batch that never posted in the first place—well, that’s still going to be 0.00, because nothing from nothing is still nothing.
Fisherman Accounting
NS-13121 & NS-13330 - Fish Tickets: Site Says, GL Account Does (Now with Its Own Settings Screen)
Fish Tickets just got smarter about handling GL Accounts. Instead of making you manually wrangle accounts every time you change the Site Processed, NorthScope now updates the Ticket Line’s GL Accounts automatically when the ticket moves to Approved or Posted. That means the following accounts stay in sync with the site you pick:
- Ticket Line Purchase GL Account
- Ticket Line Program DR Account
- Ticket Line Program CR Account
- Ticket Line Program Company Expense Account
But wait, there’s more: we’ve also added a brand-new configuration screen under Financial → Configuration called GL Account Site. This List View lets you set up exactly which GL Accounts belong to each site. In other words, you tell NorthScope once, and from then on, it remembers—no more scrambling through tickets to manually switch GL Accounts.
Improvement
Sales
NS-12603 - Search Metadata Refresh: A Little Less Chaos, A Lot More Speed
The Sales Order posting process necessarily does a lot of work and it relies on several other, specialized, procedures to complete order posting. One of those procedures (SPx_SOProcess_SearchMetadata_RefreshOrder, to be precise) used to be like that one coworker who always brings everything to the meeting—even stuff no one asked for. Temporary tables would get filled up with all the orders, even when you only needed a single one, and the SQL code itself was still rocking its “vintage” look. Technically correct? Yes. Functional? Sure. Efficient? Could be better.
We gave the RefreshOrder procedure a makeover. It now follows NLP’s current development guidelines (goodbye, legacy mullet). More importantly, it only populates temporary tables for the specific OrderHeaderSKs needed to complete its work, which makes it run a whole lot quicker. And speaking of telling it what to use: the OrderHeaderSKCSV parameter is now required. No more NULL defaults, no more “mystery behavior,” and no more future developers squinting at the code wondering why it behaves differently in one scenario than in another. That’s right, this feature is as much for making NLP’s developers’ lives better as it is for our customers!
Bug
Financial
NS-12555 - Financial Accounts: Spaces and Clones No More
NorthScope allows you to use spaces in your GL Account Segment Names, but a few pages in NorthScope couldn’t cope—they broke in ways that made it clear our NorthScope wasn’t much of a fan of whitespace. While sorting that out, we also noticed another quirk: the Financial Account SQL View generation logic was automatically adding a “Natural Account” segment, even if you’d already created one. That left you with duplicate segments in some of your analysis Pivot Tables, which is about as useful as two steering wheels on one car.
We’ve straightened things out. Segment names with spaces now work without breaking NorthScope screens, and the system won’t sneak an extra Natural Account segment into your reports.
NS-13081 - Journal Entries: No More Post-Posted Editing Shenanigans
Posted transactions are supposed to be like history books: once they’re written, you don’t get to quietly sneak in and change the ending. But NorthScope was letting you do exactly that—editing Journal Entries that were already in statuses like Approved, Ready to Post, Posted, Replaced, or Void. It’s basically like giving someone an eraser and telling them the Mona Lisa is fair game.
We’ve locked things down:
- When a Journal record has a Source Transaction Type and is in one of those locked statuses, the New and Delete buttons are now disabled.
- All grid fields are locked, too—except for Line Comment, because commentary doesn’t have a financial impact.
- Up top, the Header Comment and Reference fields also remain editable, so you can still add notes there, too.
The end result? Your posted Journals stay untampered, while still leaving you room to scribble useful comments in the margins.
Framework
NS-13249 - Header Tabs: The Filter Row Learns Its Place
In screens with multiple header tabs, grids in those header tabs have a quirk: the filter row was supposed to be hidden, but it stubbornly refused to disappear. The Stat Area tab for Fish Tickets made this most obvious, but the issue could crop up anywhere.
We’ve fixed the tools our developers use to build screens in the NorthScope 3 Framework so grid filter row settings now work as intended. If a tab’s design says its grid’s filter row should be hidden, it will actually stay hidden. No more rogue filter rows sneaking into places they don’t belong.
Sales
NS-13342 - Transaction Class: Remit To Finally Remembers Where To Go
When we redeveloped the Transaction Class record view in the new framework, we tinkered a little too much with how property defaults work. The result? The Remit To address started defaulting to “Domestic”—which might not even exist—instead of pulling from the actual Company Address list. Basically, new Transaction Classes were being born with a questionable sense of direction.
We’ve fixed the compass. Now, when you add a new Sales Order Transaction Class, the Remit To address will correctly default to the first remit to address in your Company Address list, just like it’s supposed to. No more arbitrary defaults, no more mystery addresses: the Remit To Address just defaults to the Remit To Address set as the Company default.
Technical Changes
- Please view cumulative schema changes here.
- No config file changes.