Currently in ERPNext:
-
Party Types include Customer, Supplier, Employee, and Shareholder.
-
Account Types mainly revolve around Receivable, Payable, Equity, Bank, Cash, etc.
-
Employee advances / employee-related balances and Shareholder-related balances (dividends, capital, loans from shareholders, etc.) often require manual selection of Party Type + Party in Journal Entry (and similar documents).
-
There is validation that Party Type / Party can only be set on Receivable / Payable (and sometimes Equity) accounts. This creates friction:
-
Users must remember which account belongs to which party type.
-
No automatic suggestion of the correct Party Type when an account is selected.
-
Mapping between Account Type ↔ Party Type is incomplete or not intuitive for Employee and Shareholder (unlike the clearer Receivable → Customer and Payable → Supplier relationship).
-
This leads to extra clicks, higher chance of errors, and inconsistent data entry, especially in high-volume journal entries, payroll-related journals, dividend payments, shareholder loans, etc.
-
Proposed Improvement
-
Enhance Account Type (or introduce clearer mapping)
-
Support / document dedicated or clearer Account Type options (or Account Type + sub-classification) that map cleanly to Employee and Shareholder.
-
Examples of desired clarity:
-
Employee Advance / Employee Receivable / Employee Payable style accounts → clearly linked to Party Type = Employee.
-
Shareholder-related equity / payable / dividend accounts → clearly linked to Party Type = Shareholder.
-
-
Keep existing Receivable → Customer and Payable → Supplier behavior intact.
-
-
Auto-populate Party Type (and optionally Party) when selecting an Account
In Journal Entry (and ideally Payment Entry / other relevant vouchers):-
When user selects an Account in the Accounting Entries table:
-
System should automatically set the correct Party Type based on the Account’s type / configuration / mapping.
-
If possible, also suggest or pre-fill Party when there is a strong default (or leave it blank but with the correct Party Type already set so the Party link only shows the right list).
-
-
This should respect existing validation (only allow Party on Receivable / Payable / Equity where appropriate) but make the correct choice automatic.
-
-
Better Party Type ↔ Account Type configuration
-
Make the mapping in Party Type doctype (or a new settings area) more explicit and extensible so implementers can define:
-
Which Account Types are valid for each Party Type.
-
Default Account Type for each Party Type.
-
-
This will make it easier for custom party types in the future as well.
-
Benefits
-
Faster and less error-prone data entry in Journal Entries.
-
Cleaner party-wise reporting and outstanding tracking for employees and shareholders.
-
Better user experience for payroll-related journals, employee advances, dividend payments, capital transactions, and shareholder loans.
-
Reduced training burden and fewer support tickets around “why can’t I select the party?” or “wrong party type selected”.
-
Aligns with the existing smart behavior already present for Customer / Supplier.
Use Cases
-
Booking employee advances or recoveries via Journal Entry.
-
Recording dividends payable / paid to shareholders.
-
Shareholder capital introduction or withdrawal.
-
Any multi-party journal where the account clearly belongs to Employee or Shareholder.
Current Workarounds (that this feature would eliminate)
-
Manually selecting Party Type every time.
-
Client scripts to restrict or default Party Type.
-
Using generic Payable / Receivable accounts and relying on user discipline.
Would the community and core team consider this enhancement? Happy to provide more detailed flows, mock-ups, or help test if this moves forward.
Thanks!