Add “Party Name” field in GL Entry and General Ledger report

[rizwan100mu]

@DipenFrappe @mihir-kandoi

Module: Accounts / General Ledger
Current Behavior
• In GL Entry and the General Ledger report, the column Party always stores and shows the internal party ID (i.e. the value of name of Customer, Supplier, Employee, etc.).
• When name is not the human-readable name (for example, Employee where name is set to National ID or a numeric code), the General Ledger report shows only this code in the Party column.
• There is no separate standard field in GL Entry to store the human readable party name, so reports cannot reliably display both Party ID and Party Name together.
Problem
• For some doctypes like Employee, it is common to use name as a unique code or National ID, while the actual name is stored in a separate field (e.g. employee_name).
• In mixed cases (Customer, Supplier, Employee), the General Ledger report cannot consistently show a clear party name; it only shows the ID/code from GL Entry.party.
• This makes the GL report confusing for finance users, especially when IDs are numeric or national IDs instead of real names.
Requested Change

1. Add a new field in GL Entry doctype:
   • Fieldname: party_name
   • Fieldtype: Data
   • Label: Party Name
2. When GL entries are created from source documents (Sales Invoice, Purchase Invoice, Journal Entry, Payment Entry, etc.), set gl_entry.party_name using the same logic many forms already use:
   • If party_type is Customer, use customer_name.
   • If party_type is Supplier, use supplier_name.
   • If party_type is Employee, use employee_name.
   • Otherwise, fall back to the party document’s name or a generic _name field if available.
3. Update the General Ledger report to:
   • Keep the existing Party column (ID).
   • Add a new column Party Name that reads from GL Entry.party_name.
   • Optionally allow users to hide either column via report column picker.
   Benefits
   • Finance users can see both the internal Party ID/code and the readable Party Name in one standard report.
   • Works correctly even when the party name is a code or national ID and not the actual person/company name.
   • Reduces need for custom reports and client scripts just to show party names from multiple doctypes.