Skip to main content

​
Overview

“Transaction Generator” in fusionCore is actually two separate packages installed together. Understanding which is which matters, because the first does nothing useful on its own:
  1. Transaction Generator (the base package, managed, namespace FSPTG) is a generic, empty double-entry engine. It defines the Journal Entry Rule, Transaction, and Transaction Entry objects and the batch/real-time logic that turns a rule into balanced debit/credit records — but it ships with zero rules. Installed by itself, it has nothing to do.
  2. fusionCore Transaction Generator Add On (unmanaged, no namespace) is what makes it useful for a fusionCore org. It contributes three things: a one-time setup script that inserts 21 pre-built Journal Entry Rules encoding fusionCore’s standard accounting treatment; extra fields on Transaction Entry that trace each line back to the fusionCore Financial Event and Financial Event Line that generated it; and the wiring that plugs Transaction Generator into fusionCore’s existing Financial Period close process.
Both packages need to be installed for fusionCore’s out-of-the-box accounting automation to work. If your org only has the base package, confirm the add-on and its setup script have also been installed and run.
fusionCore’s standard rules model exchange revenue — dues, event fees, subscriptions, and other order-driven revenue recognized as goods or services are delivered. Basic unrestricted contribution revenue (donations) isn’t in the standard set, but is handled with a custom rule — see the worked example below. Donor-restricted contributions and fund accounting remain outside this accelerator’s scope.
List view of 21 Journal Entry Rule records, each with a Sequence, description, and WHERE Query

21 Journal Entry Rules installed by the fusionCore add-on's setup script

​
Key Concepts

  • Journal Entry Rule — a reusable rule: a target object, a filter (WHERE clause), and a JSON definition of the debit/credit lines to post.
  • Transaction and Transaction Entry — the generated double-entry records. A Transaction’s Total Debits and Total Credits roll up from its entries, and a formula flags any transaction where they don’t match.
  • A record is only picked up once — after a Transaction is generated for it, a date field on the source record is stamped, and the engine skips already-stamped records on future runs.

​
Creating a Custom Journal Entry Rule

fusionCore’s standard rules cover the common accounting treatment for fusionCore’s own objects. Create your own Journal Entry Rule when you need to post entries the standard set doesn’t cover — a different treatment for an existing object, or entries driven by a custom object.
1

Create the rule record

Open the Journal Entry Rules tab and click New.
The Journal Entry Rules list view with the New button highlighted by a red box

The Journal Entry Rules list — click New to start a custom rule

Fill in the basics:
  1. Journal Entry Rule Name 
  2. Sequence number (controls run order relative to your other rules)
  3. Target Object API Name (the object whose records this rule reads)
  4. WHERE Query (a SOQL WHERE clause, without the WHERE keyword, scoping which records it applies to).
  5. Transaction Posted Date Field is required — the field on the target object (or reachable through a relationship from it) whose date becomes the generated Transaction’s date.
The New Journal Entry Rule form showing Name, Active, Description, Sequence, Target Object API Name, WHERE Query, and the Deferrals fields including the required Transaction Posted Date Field

The New Journal Entry Rule form — Name, Sequence, and Transaction Posted Date Field are required

Active is checked by default on a new rule. A rule saved Active is picked up by the very next nightly run. If you’re still designing the rule, uncheck Active first and re-enable it once the debit/credit lines are configured and reviewed.
2

(Custom objects only) Add a Transaction Created Date field first

If the rule targets a custom object rather than a fusionCore object, add a Date field to that object before activating the rule — this is the stamp the engine uses to avoid reprocessing the same record twice. Its API name must match your org’s Transaction Generated Date Field setting on the Transaction_Generator__mdt settings record: in a fusionCore org with the add-on installed that’s FS_Transaction_Created_Date__c; on the base package alone it’s Transaction_Created_Date__c. If you want deferral or default-amount behavior for the custom object, the fields those options reference must exist on it too.
3

Configure the debit and credit lines

Open the rule and click Configure Journal Entries. The top of the modal repeats the rule’s target object and WHERE clause — the filter that decides which records this rule fires on:
Configure Journal Entries modal with a red box around the WHERE Query field, showing the filter for the A/R Payment rule

The top of the Configure Journal Entries modal: the rule's target object and WHERE Query

Scroll down within the same modal to the Journal Entries section. This is where you define each debit/credit line: which side, which field holds the amount, and which field on the target record holds the GL Account. You’ll generally need at least two lines — one debit and one matching credit:
Configure Journal Entries modal with a red box around the first journal entry line, showing a Debit to Cash with GL Account Field and Amount Field set

Further down the same modal: the debit/credit line editor

The field pickers for GL Account, Amount, and the deferral date fields can chain through relationships on the target object — for example, from a Financial Event Line through its Business Unit to a Deposit Account field. Keep chains to 4 relationships deep or fewer.
4

(Optional) Configure deferred revenue

If the rule should split one amount across multiple accounting periods, set the deferral start/end/posted-date fields and a deferral period field on the rule.
5

Activate the rule

Once the lines are configured and reviewed, check Active on the rule. A rule can’t be saved as Active without a target object and a Transaction Posted Date field configured.
6

Choose how it runs

Active rules run automatically every night at 12:00 AM org time in a scheduled batch (the packaged Transaction Generator job, running TransactionGeneratorBatch). For immediate, on-demand generation, add the View/Create Transaction Entries Lightning component to the target object’s record page — clicking it runs the same active rules against just that record.
Whichever way a rule runs, the result is the same: a Transaction record (with rolled-up Total Debits and Total Credits) and its child Transaction Entry lines, linked back to the rule that created them.
A Transaction record showing Total Debits and Total Credits of $6,000, Draft status, its source Journal Entry Rule, and two related Transaction Entries

A generated Transaction, linked to the Journal Entry Rule that created it

​
Journal Entry Rule fields quick reference:

​
Worked Example: Recording Donations

Donations can reach Salesforce in many ways, so this example uses one concrete setup to walk the flow end to end. Foundation of Innovators is an association that collects donations in a fundraising system outside of Salesforce. As each gift is collected, the external system creates a Donation record (a custom Donation__c object) in Salesforce, and the accounting team wants those gifts tracked as Transactions in Salesforce for ease of reporting. A custom rule does exactly that: when a Donation’s Status becomes Received, it posts the gift to the books automatically. The accounting treatment. A donation is contribution revenue, not exchange revenue — the donor receives nothing of commensurate value in return — so unlike dues or event fees there is no service period to defer it over. The rule recognizes the full amount on receipt with a single balanced entry, and configures no deferral schedule:
Point the credit at a contribution-revenue GL Account kept separate from your dues and other exchange-revenue accounts, so audited statements and the Form 990 can separate contributions from program revenue. In this example the accounts belong to the Foundation Business Unit — the same association/foundation split described in Accounting Overview.
Prepare the custom object. The example Donation__c object carries these fields — the two GL Account lookups are what the rule’s journal entry lines will read, and the stamp field is the reprocessing guard from the earlier step: Create the rule. On the New Journal Entry Rule form, enter:
The New Journal Entry Rule form filled with Donation Received, Sequence 100, Target Object Donation__c, a WHERE Query of Status__c = 'Received' AND Amount__c > 0, and Transaction Posted Date Field Received_Date__c, with the unchecked Active checkbox highlighted by a red box

The filled New Journal Entry Rule form — Active stays unchecked until the lines are configured

In this case, the Amount__c > 0 guard matters: without it, a zero or negative amount would generate a zero or reversed entry, which is not the correct treatment for a corrected or returned gift — a returned gift needs its own reversing entry. Configure the two lines. Save the rule, click Configure Journal Entries, and add one Debit and one Credit line, both reading Amount__c:
The Configure Journal Entries modal showing line 1 as a Debit with GL Account Field Deposit_GL_Account__c and line 2 as a Credit with GL Account Field Revenue_GL_Account__c, both with Amount Field Amount__c

The configured lines: Debit to the deposit account, Credit to Contribution Revenue

Save, then check Active on the rule. Generate and verify. With the View/Create Transaction Entries component on the Donation record page (added in Lightning App Builder), a received donation shows a Generate Transactions button:
A Donation record for Rockville Community Trust with Amount $2,500, Status Received, both GL Account lookups set, and the Generate Transactions button highlighted by a red box in the Transaction Entries panel

A received $2,500 donation, ready to post — the component sees the record matches an active rule

Clicking it runs the rule against just this record. The panel refreshes with the two generated entries — a $2,500 Debit to the deposit account and a $2,500 Credit to Contribution Revenue:
The Donation record's Transaction Entries panel highlighted by a red box, showing a Debit of $2,500 and a Credit of $2,500 both dated 6/15/2026 and linked to the Donation Received rule

After generating: one balanced pair of entries, dated on the Received Date

The parent Transaction confirms the entry balances, carries the Received Date as its Transaction Date, and links back to both the rule and the Donation record. The Donation’s FS_Transaction_Created_Date__c is now stamped, so the nightly batch won’t pick it up again:
The generated Transaction record with Total Debits $2,500 and Total Credits $2,500 highlighted by a red box, Draft status, Transaction Date 6/15/2026, and a Reference section linking to the Donation Received rule and the Donation record

The generated Transaction: balanced totals, dated from the gift's Received Date

For the clearest read of the double entry, open the Transaction’s Transaction Entries related list (View All) — the full-width view puts the debit and its matching credit side by side with their dates, GL Accounts, and amounts:
The full-width Transaction Entries related list showing two rows: a Debit of $2,500 to 200-10-1000 FOI SunTrust Bank Account and a Credit of $2,500 to 200-20-2100 FOI Contribution Revenue, both dated 6/15/2026

The full-width Transaction Entries list: the debit and its matching credit, line by line

​
fusionCore’s Standard Journal Entry Rules (Add-On)

Installing fusionCore’s Transaction Generator add-on and running its one-time setup script inserts the 21 Journal Entry Rules below. All of them target fusionCore’s Financial Event Lines, matching on the parent Financial Event’s type and status, and encode fusionCore’s standard accounting treatment — you don’t have to design this rule set yourself. You configure your GL Accounts on Commerce (A/R Account, Revenue Account, Deferred Account, Deposit Account, Write-Off Account, Due From/To Accounts), and each rule picks the right account automatically based on the Financial Event type.
1

Assign the permission set

Assign FS TG AddOn (Read-Only) to users who need to see the reference fields the add-on stamps on Transaction Entries (covered below).
2

Insert the standard rules

Run the packaged one-time setup script that inserts all 21 rules in the execute anonymous window in the developer console. Run it only once per org — running it twice creates duplicate rules, which double-posts every transaction.new FS_StandardJournalEntryRecords().create().insertRecords();
3

Confirm your GL Accounts are configured

Each rule reads its GL Account from your Commerce configuration (A/R, Revenue, Deferred, Deposit, Write-Off, and Due From/To accounts). Missing accounts mean that rule can’t post correctly.
4

Replace the Fetch and Lock buttons on the Financial Period page

The add-on packages its own Fetch and Lock quick actions — installing it does not remove or replace the base ones already on the Financial Period page, so both versions exist side by side under the same button labels until someone swaps them in.
A Financial Period record page with the Fetch and Lock buttons in the action bar highlighted by a red box

The Financial Period page still showing the base Fetch and Lock actions — this needs to change after installing the add-on

In Setup → Lightning App Builder, edit the Financial Period record page, select the Highlights Panel (the action bar shown above), remove the base Fetch and Lock actions, and add the add-on’s versions of Fetch and Lock in their place. Save and activate the page. Skipping this step is easy to miss because both actions have identical labels — see the warning below for why it matters for Lock specifically.
Whether a rule posts “with Deferrals” or “without Deferrals” depends entirely on whether a Deferred Account is set on the Financial Event Line. If revenue is posting to the wrong account, check that field first.
The 21 rules, in the order they run:
Due To/From (rules 13 and 18) posts in addition to, not instead of, the primary entry. A cross-Business-Unit payment matches its ordinary rule (for example, A/R Payment) and the Due To/From rule, generating two separate Transactions from the same Financial Event Line — one recording the cash/revenue, one recording the intercompany offset. This is the mechanism behind the association/foundation Business Unit split described in Accounting Overview — use it when one Business Unit collects money that economically belongs to another.

​
How the Add-On Traces a Transaction Entry Back to fusionCore

Every Transaction Entry the standard rules generate is automatically stamped with lookups back to the Commerce records that produced it — Financial Event, Financial Event Line, and GL Account — so accounting staff can trace a journal line back to the order or payment that caused it without leaving the Transaction Entry record.
A Transaction Entry record's Reference section showing links to the originating Financial Event and Financial Event Line, and a blank Financial Period

A generated Transaction Entry, showing the fusionCore add-on's reference fields

​
Financial Period Close Workflow

The add-on packages its own Fetch and Lock quick actions on the Financial Period, separate from the base Fetch and Lock actions already covered in Fetching Financial Event Lines and Locking Financial Periods. They carry the same button labels, which makes it easy to assume they’re the same action — they aren’t. Make sure the button swap from setup was actually done before relying on either action below.
1

Fetch

Click Fetch. It runs the identical underlying batch the base action runs, so it links every Transaction Entry whose posted date falls in the period’s date range to that Financial Period regardless of which of the two Fetch actions you have on the page.
2

Lock

Click Lock. Unlike Fetch, the add-on’s Lock action is not interchangeable with the base one — it runs extra validation before it ever reaches the base lock logic: every Financial Event in the period must have a Transaction Entry, every entry must be linked and its parent event Succeeded, and every Transaction must balance. Only then does it lock the underlying Transactions and Transaction Entries alongside the standard Financial Event Lines.
Make sure the base Lock action was replaced with the add-on’s Lock action. The add-on’s version validates that the period’s generated Transactions are in a valid state — linked, Succeeded, and balanced — before locking anything. The base Lock action performs none of those checks, so it will happily lock a period whose Transactions are unbalanced or missing, and locking can’t be undone.
A Financial Period record with Batch Job Status Completed Fetch and a populated Financial Event Lines related list

After Fetch: Transaction Entries for this period are now linked (shown here via the Financial Event Lines they were generated from)

Locking a Financial Period is one-way and has no undo — it permanently blocks edits and deletes on the underlying Transactions and Transaction Entries, on top of the standard Financial Event Line lock described in Locking Financial Periods. Fetch first, review what it linked, and only lock once you’re confident the period is ready to close.

​
Setting references on custom objects

For any new custom objects, you will want to create a Transaction Created date (Transaction_Created_Date) field so that the engine can track processed records that are defined in the Target Object field on the Journal Entry Rule You will also want to ensure that you have corresponding fields on the Journal Entry Rule if you wish to have fields such as Deferral Period, Deferral Offset, Transaction Start Date, Transaction End Date and Default Amount fields included in your Journal Entry Rule for the new custom object

​
Limitations and Common Pitfalls

  • Rules only match Succeeded Financial Events. Almost every one of the 21 standard rules requires the Financial Event to be in Succeeded status — events in any other status are ignored and never generate a transaction.
  • The posted date comes from the Financial Event’s Succeeded date. If that date is wrong or blank, a generated transaction lands in the wrong Financial Period (or none), even if the transaction itself is correct.
  • Deferred revenue only recognizes automatically if the Revenue Schedule field is set. A blank revenue schedule matches neither the specific-date nor the over-time recognition rule, so that deferred revenue is never automatically recognized.
  • Write-offs don’t unwind remaining deferred revenue. The standard Write-Off rule only reverses the Accounts Receivable portion to a Bad Debt account — deferred revenue balances need a manual or custom entry.
  • The Write-Off account should be set up as an expense account. Rule 19 debits it directly for the written-off amount. If your chart of accounts maps it to an asset or contra-asset account instead, write-offs will misstate your balance sheet rather than your income statement.
  • Locking is one-way. Once a Financial Period is locked, its transactions and entries can’t be edited or deleted, and there’s no built-in “unlock” action.
  • You can only close one Financial Period at a time. Trying to close more than one in the same bulk update or data load is blocked.
  • Locking checks are strict — but only if the add-on’s Lock action is actually on the page. If any Financial Event in the period’s range has zero Transaction Entries, or any entry isn’t linked, isn’t Succeeded, or doesn’t balance, the add-on’s Lock action fails with an error naming the specific problem. The base org’s original Lock action has no awareness of any of this and will lock the period anyway — see Financial Period Close Workflow above.
  • A failed batch scope isn’t silently dropped. If part of a nightly run fails, the base engine automatically retries that portion at a smaller batch size to isolate the problem record, rather than failing the entire night’s run.
  • The four report links on a Financial Period need one-time setup. The A/R, Deposit, Write-Off, and Detail Summary Report fields on a Financial Period each read a Salesforce Report Id from a Constant custom metadata record. Until those records are populated with real Report Ids, the fields show “Missing Report Id in Constant custom metadata record” instead of a link.