Northern Comfort Planned Apply

Apply thousands of customer or vendor ledger entries — planned in advance, posted in the background, resumable at any point.

Applying a handful of open entries in Business Central is easy. Applying hundreds or thousands of them — a year of collective invoices against one payment, a clearing account cleanup, a data migration leftover — is where the standard "Apply Entries" page starts to hurt: the session blocks other users, the browser times out, and when the posting aborts halfway you are left guessing what was applied and what was not.

Northern Comfort Planned Apply solves exactly this. It is part of the Northern Comfort Finance range of apps and works for customers and vendors alike.

How it works

The app splits mass application into two strictly separated phases:

1. Planning — You collect the entries in a worksheet and group them into applications. Planning is pure staging: nothing is written to the ledger entries, no Applies-to ID is set, no locks are taken. You can plan with a coffee in your hand while the rest of the company keeps posting.
2. Running — When you release and start the batch, a background task posts the applications. You can close the page and go home; the run continues on the server.

Applications

A batch is not one big application. It holds any number of applications, and each one settles exactly one main entry (the remaining-amount carrier, typically the payment) against its own secondary entries. So you can marry five payments to their invoices in a single planning session and let one background run post all five.

Each application carries its own main entry, its own difference and its own posting mode.

Posting mode: pairwise or combined

Mode	What it does	When
Pairwise (default)	Posts the main entry against one secondary entry at a time, with a database commit after every pair.	Everything that needs no difference handling.
Combined	Posts the whole application in one transaction under a single Applies-to ID.	Required as soon as discount tolerance, payment tolerance or a write-off is involved.

Pairwise is what makes a large run robust:

• Every transaction is tiny, so there are no long database locks and no session timeouts — whether the batch has 50 or 5,000 entries.
• If a single pair cannot be applied, it is recorded with its error message and skipped — the run continues with the next pair instead of aborting everything.
• If the run is interrupted (session killed, service restart), you simply resume: only the remaining open pairs are processed, nothing is applied twice.

Combined mode gives that up on purpose, because the standard computes payment discount and tolerance over all entries sharing one Applies-to ID, not per pair. Pairwise processing would produce order-dependent results. That is why any difference handling switches the application to combined automatically — and why the setup caps how large a combined application may get.

Setup

Search for Planned Apply Setup. The record is created automatically on install, together with the number series CFA-APPL (batch numbers look like CFA-A00042).

Field	Meaning
Apply Batch Nos.	Number series for apply batches.
Batch Restriction	How many open batches may exist per account: No restriction, One per account + user, or One per account (global). Delivered as One per account (global). With a restriction active, opening Planned Apply for an account routes you into the existing open batch instead of creating a new one.
Max. Steps per Run	Upper limit of steps per background run, 500 by default. A pairwise application produces one step per secondary entry, a combined one a single step. Larger jobs must be split into several batches.
Max. Entries per Combined Application	How many entries one combined application may contain, 100 by default. Combined posting runs in a single transaction — this limit keeps it inside the posting timeout.
Default Difference Account (Debit)	G/L account suggested when the account is short of the planned amount.
Default Difference Account (Credit)	G/L account suggested when the settling entry keeps a surplus.
Write-Off Journal Template Name / Write-Off Journal Batch Name	Only needed if your General Ledger Setup makes a journal template mandatory on every posting.

Licensing

Northern Comfort Planned Apply is licensed through the Northern Dynamic Licensing app. On first use a 30-day trial is provisioned automatically; afterwards activate your license on the Northern Dynamic Licenses page.

Permissions

Two assignable permission sets ship with the app:

• Planned Apply - Full Access — everything, including the sandbox test data wizard.
• Planned Apply - User — plan, release and run batches; setup is read-only.

Posting the application itself additionally requires the user's standard finance posting permissions.

Step by step

1. Open the worksheet

The action Northern Comfort Planned Apply sits everywhere you would want it:

• Customer Card, Customer List, Vendor Card, Vendor List — opens a batch for that account.
• Customer Ledger Entries, Vendor Ledger Entries — the entries you selected in the list go straight into the plan as one application.
• General Journal, Payment Journal, Cash Receipt Journal — plans a mass application for the customer or vendor on the current journal line. The journal line itself is not touched.

Or start from the overview: search for Northern Comfort Planned Apply to open the batch list, which shows all batches with account, status, planned balance and run results.

2. Plan the applications

The worksheet has three sections — Open Ledger Entries on top, then Applications, then Planned Entries — plus a Steps FactBox.

The planning actions always work on the application currently selected in the Applications list.

Action	What it does
Add as New Application (Shift+F10)	Marries the entries selected in the open entries list into a new application.
Add to Selected Application (Shift+F11)	Plans the selected entries into the application highlighted in the Applications list.
Add All in Current Filter	Plans everything matching the current filter of the open entries list in one go — for example after filtering by document type, date range or a previously set Applies-to ID. Entries that cannot be planned are skipped and counted; the bulk operation never aborts halfway.
Import Entry Nos. from CSV	Reads ledger entry numbers from a file. First column: the entry number. Optional second column: a grouping key — equal values land in the same application. Optional third column: M marks the main entry. Lines that cannot be planned are skipped and listed with the reason.
Remove from Application / Remove All in Current Filter	Take entries back out of the plan.
Move to Another Application	Moves planned entries into the application selected in the Applications list.
Delete Application	Deletes an application with its entries; the entries become plannable again.
Show Only This Application	Narrows the planned entries list to the selected application. Choose it again to show the whole batch.

The main entry is suggested automatically. The app looks at the minority side of the application — if three invoices meet one payment, the payment is the candidate — and among the candidates a payment or refund wins, because the standard only grants a payment discount when the settling entry is one. Otherwise the largest amount wins. Set as Main Entry overrides the suggestion; from then on it is never overridden again.

While planning, the header keeps you honest:

• Applications — how many applications the batch plans.
• Applications with Open Difference — how many will leave a remainder open. Green at zero, highlighted otherwise. A remainder is legitimate for a partial payment, but it should be a decision, not an accident.
• Planned Balance — the running balance over all planned entries. Mainly meaningful for a batch with a single application; per application the difference is shown in the Applications list.

A few rules and warnings along the way:

• All entries of one batch must share the same currency; the first planned entry pins it.
• An entry can only be planned in one open batch at a time; the app names the batch that is blocking it.
• If entries have the same sign as the main entry of their application, a notification warns you: pairwise posting cannot apply such a pair and it will remain open. Switch the application to combined posting if they belong together.
• If an application receives more payment discount than its difference, the settling entry keeps a surplus. It stays open unless you write it off to the credit-side difference account.
• Entries that already carry an Applies-to ID can be planned; a notification tells you the run will overwrite it.

3. Handle differences

When an application does not net out, Handle Difference shows what is missing and what can cover it. Every toggle recalculates the whole cascade immediately — using the same routine the run uses later, so what you see is what gets posted.

The cascade, in order:

1. Payment discount — granted automatically while the apply date is within the discount date, and only if the main entry is a payment or refund. There is no switch for it, because the standard grants it on its own. If it cannot be granted, the dialog tells you why.
2. Grant Discount after Due Date — grants the discount although the discount date has passed. Posts as payment discount tolerance to the discount accounts of the posting group.
3. Use Payment Tolerance — accepts a remaining difference as payment tolerance, bounded by each entry's own maximum payment tolerance from the General Ledger Setup.
4. Write-Off Account No. — writes off whatever is left to a G/L account. Use Default Difference Account picks the debit or credit account from the setup, whichever matches the direction. Note that the write-off posts without VAT correction.
5. Stays Open — anything still left. Zero means the application settles completely; anything else is a partial payment.

The difference can point either way. The account can be short of the planned amount, or the settling payment can keep a surplus once a discount is granted — the dialog names the direction and tells you which of the two default accounts fits.

Any difference handling switches the application's Posting Mode to Combined. Clearing the last handling returns it to Pairwise; you can also override the mode by hand.

4. Release and start

Release validates the plan and locks it. It refuses, with a concrete message, when:

• the batch has no application yet, or fewer than two planned entries;
• an application has no main entry, or contains only its main entry;
• the batch produces more steps than Max. Steps per Run allows;
• a combined application exceeds Max. Entries per Combined Application;
• an application is planned with a write-off but has no write-off account;
• your company requires a journal template on every posting and no write-off journal is set up;
• an application uses discount or payment tolerance but its posting group has no accounts for it.

The Apply Date defaults to the work date and the Document No. to the batch number — both can be changed before release.

In Notification E-Mail you can enter or look up an address (it defaults to your own contact email). When the run finishes — successfully or with errors — a result mail goes there. Leave it empty for no notification. Sending requires a configured email account (Email Accounts page); a mail problem never affects the run itself and is logged to telemetry.

Start launches the background run. Refresh the page to follow along: the header shows Open Steps and Error Steps, the Steps FactBox lists every step with its status, and Run Started At / Run Finished At / Run Duration track the timing.

While a run is active the batch is protected: starting again, retrying, reopening or archiving is blocked ("The background run of this batch is still active…") until it has finished. A crashed session does not block — the check tests whether the session is actually alive.

5. After the run

• Finished — everything applied. The result mail summarizes the run. Archive the batch to clean up the list.
• Finished with Errors — some steps failed. Each one shows its error message in the Steps FactBox. The successful ones are posted and final; the failed entries remain open. You have three options:
  • Retry Failed Pairs — after fixing the cause, run just the failed steps again. Applied ones are not touched.
  • Reopen — back to planning. The applied pairs leave the plan (they are irreversible), the failed entries stay planned, and you can adjust before releasing again.
  • Archive — close the batch; its remaining entries become available for new batches.
• Resume — if a run was interrupted (status stuck at In Progress with no live background session), Resume processes the remaining open steps. Nothing is restarted or applied twice.

The result mail

Subject: Planned Apply batch CFA-A00042: Finished with Errors

The apply run for batch CFA-A00042 (Customer 10000) has finished.
Status: Finished with Errors
Successfully applied pairs: 498
Failed pairs: 2
Duration: 1 hour 23 minutes
The failed pairs are listed with their error messages under Steps in the
Planned Apply worksheet. You can retry them or reopen the batch to adjust the plan.

The mail is sent in the language of the user who started the run.

Good to know

• Planning never touches the ledger. Until you start the run, no Applies-to ID is set and no ledger entry is modified — other users and other batches are unaffected.
• Pairwise means opposite signs. A pair of two same-sign entries cannot be applied by the standard routine; plan them as a combined application instead.
• One currency per batch. Multi-currency applications need one batch per currency.
• The write-off posts without VAT correction. For a difference that needs one, post a credit memo instead.
• The difference preview is not an estimate. Planning dialog, release validation and the run all call the same calculation, so the preview cannot drift from the posted result.
• Telemetry: install, release, run start/end and mail failures are logged to the publisher telemetry — helpful when you open a support case.

Creating test data (sandbox only)

For testing and demos the batch list offers Create Test Entries. It is visible only in sandbox environments and can never run in production.

The wizard creates invoice journal lines for a customer or vendor plus covering payment lines in a general journal of your choice. Beyond the obvious fields (account, journal, amount range, posting date, document number prefix) three of them shape the scenario:

• No. of Applications — over how many payments the invoices are spread. Each payment covers its own share, which gives you one application per payment to plan.
• Payment Terms Code — terms with a discount put a real payment discount on the entries and reduce each payment by exactly that discount: the situation the discount handling is for.
• Shortfall per Payment — by how much each payment falls short. A few cents to test the payment tolerance, a few units to test a write-off, a large amount for a partial payment that stays open. Zero creates payments that settle exactly.

Post the journal and you have a realistic mass-application scenario ready to plan.

FAQ

Why don't I see the "Create Test Entries" action? It only exists in sandbox environments. In production the action is hidden entirely.

Why did my application switch to combined posting on its own? Because you set a difference handling on it. The standard computes discount and tolerance over all entries of one application at once, so those cannot be posted pair by pair. Clear the handling and the application returns to pairwise.

Release says the batch produces too many steps. A pairwise application makes one step per secondary entry. Raise Max. Steps per Run in the setup, or split the work across several batches. The limit exists to keep single runs predictable.

The run finished but I got no mail. Check that an email account is configured (Email Accounts page) and that the batch has a notification address. Mail problems never affect the run; they are logged to telemetry.

Reopen is blocked with "Background run still active". The previous run is still processing. Wait for it to finish and refresh — the message disappears as soon as the background session ends.