💡 [Feature Request] - Allow selecting "Party" in Journal Entries to reflect Credit/Debit adjustments in Party Ledgers

[urstrulypriyankrai]

Summary

Description

Currently, in Frappe Books, the Journal Entry screen lacks a dedicated "Party" (Customer/Supplier) field mapping. While a user can select accounting ledgers like Debtors or Creditors to make double-entry adjustments, these manual entries do not map back to a specific individual customer or supplier profile.

This creates a significant roadblock when trying to handle adjustments such as standalone Credit Notes, Debit Notes, bad debt write-offs, or manual balance routing without altering original sales or purchase invoices.

Current Behavior

1. When a user creates a Journal Entry to credit Debtors (e.g., to issue a ₹10,000 discount/credit note adjustment), the absolute balance drops across the general ledger asset category correctly.
2. However, because there is no way to assign that specific row to a Party (e.g., Shri Krishna Enterprises), the individual customer statement and outstanding balance remain completely unaffected.
3. The Payment Screen workaround is also blocked because the form restricts the "To/From Account" selections strictly to Bank or Cash account types, making it impossible to clear an outstanding invoice value against an Expense account like Discount Allowed.

Proposed Solution

Enhance the Journal Entry line items table to dynamically support a "Party Type" and "Party" column when a receivable or payable ledger account is selected.

• Field Requirements:
  • Party Type (Dropdown: Customer / Supplier)
  • Party (Searchable link field pointing to the selected Party master)
• Expected Outcome: When a Journal Entry is saved and submitted with a designated Party, the transaction should automatically post into that specific Party’s ledger tracking history, modifying their outstanding balance cleanly.

What problem are you trying to solve?

I am trying to issue standalone financial adjustments—such as post-sale seasonal discounts, volume rebates, and bad debt write-offs—to specific customers without modifying or reversing past Sales Invoices.

Currently, Frappe Books prevents this workflow completely. A manual Journal Entry updates the generic 'Debtors' asset account but completely bypasses the customer's individual statement. Meanwhile, the 'Payment' screen forces the user to select only Bank or Cash accounts, entirely blocking the ability to settle a customer's balance against an adjustment or expense account (like Discount Allowed).

This feature would allow small traders and wholesalers to handle standard, everyday credit/debit adjustments quickly and cleanly from a single screen.

Basic Example

An accountant needs to give a flat ₹10,000 seasonal discount to a customer named Shri Krishna Enterprises to lower their outstanding balance.

With this feature, the user would create a Journal Entry:

• Row 1: Account: Discount Allowed (Expense) | Debit: 10,000
• Row 2: Account: Debtors (Asset) | Credit: 10,000 | Party Type: Customer | Party: Shri Krishna Enterprises

Expected Result: * The general ledger balances perfectly.

• Shri Krishna Enterprises' individual customer statement immediately shows a Credit entry of ₹10,000, reducing their total outstanding debt by that amount.

Drawbacks

• Data Validation: The system will need strict checks to ensure that if a user selects Debtors or Creditors as the account, the "Party" field becomes mandatory to prevent mismatched balances between the General Ledger and sub-ledgers

Reference Issues

No response

[ryanduguid]

I traced this through the current journal, posting and party-balance code. Adding a Party field and passing it to ledger postings would still not update the outstanding amount shown on the customer or supplier.

Three existing behaviours matter:

• JournalEntry.getPosting passes only the account and amount. LedgerPosting._getLedgerEntry gets the party from the parent document and combines postings by account within each debit/credit map. Two customers credited to the same Debtors account would therefore need separate posting identities.
• Party.updateOutstandingAmount sums submitted, uncancelled invoice outstanding amounts. A journal ledger entry does not enter that calculation.
• Payment.updateReferenceDocOutstanding reduces specific invoices through payment references. A standalone journal has no equivalent allocation today.

Proposed first implementation:

1. Add a searchable Party link to journal rows for accounts whose accountType is Receivable or Payable. Derive and display Customer/Supplier from that account type, filtering the Party selector by the existing role, including Both. This avoids storing a second role field that can disagree with the account. Use account types rather than the names Debtors and Creditors, so renamed and custom control accounts work.
2. Require a matching party when submitting new receivable/payable rows. Clear a stale party when the account changes, and validate again on submission. Reject party tags on unrelated accounts. Existing submitted journals keep their original rows and remain cancellable without inventing historical parties; legacy drafts need a party before submission.
3. Let LedgerPosting.debit and credit accept an optional row party. Existing callers keep the parent-party default. Within each debit/credit map, group by an unambiguous account-and-party tuple. That keeps two customers on the same account separate while still combining repeated rows for one customer.
4. Use the existing ledger reversal path, which copies the party to the reversed entry. Verify party/account filters in General Ledger, including cancelled journals. Keep this first version in the journal's existing currency model; foreign-currency allocation needs a separate design.

The balance behaviour needs agreement before coding. My preference is to expose a clearly labelled party ledger balance for receivable/payable accounts alongside the existing unpaid-invoice total. In the example, a customer with an unpaid invoice of 20,000 and an unallocated journal credit of 10,000 would show a receivable ledger balance of 10,000, while that invoice would still show 20,000 unpaid. The journal would appear in the party/account ledger immediately. Customer and supplier balances should stay distinguishable for a Party with role Both.

If the intended result is to reduce that invoice to 10,000 outstanding, this also needs explicit invoice references, allocation validation and cancellation handling. It should not silently allocate against the oldest invoice or overwrite the Party total, which the next invoice or payment update would recalculate.

I would cover customer credits, supplier debits, two parties using the same account, repeated rows for one party, role Both, custom accounts, missing/mismatched parties, account changes, cancellation and legacy journals. Existing invoice/payment postings and outstanding amounts must remain unchanged when no allocation is supplied.

Would the maintainers accept party-aware postings plus a separate ledger balance as the first PR, or should explicit invoice allocation be part of the initial scope? Also, is deriving Party Type from the control account acceptable, rather than storing an editable duplicate field?