Setting Party Type and Party on the Accounting Entries on the Journal

[maovidal]

Is your feature request related to a problem? Please describe.

The journal created by Payroll Entry from Salary Slip does not set any information about the Party Type and Party on the Accounting Entries.
Please see:

That information is necessary in the Accounting side for most cases. ie: ERPNext uses them in Trial Balance for Party. Many other already implemented reports can benefit from that info on Accounting module.

Let me further justify it with an example: Lets say that one of the Salary Components is a deduction to pay a Health Insurance. In our country, we should track the amount collected for every one of those Health Insurance providers (Indeed, that applies for any of the Salary Components), and most of the times, every Employee can select the provider of those.

Having the generated Journal contain that information on its Accounting Entries that would be easy to report for any purposes.

One way to achieve that tracking with the current version of HRMS is to set extra Accounts for every Party involved. But that would be cumbersome to implement as there are many combinations of Accounts to set on every possible Salary Component and subsequent Salary Structure. Not to mention the need to re-assign that resulting Salary Structure to match the Employee preference of parties involved in case of a change request.

Moreover, an additional benefit to address this use: the current version of HRMS requires that the Account Type is not set for the Accounts (BTW it seems it is not documented). Otherwise the process in some cases fails silently when generating the Journal (I have experienced this with the current 15.10 version). See: https://discuss.frappe.io/t/salary-isnt-posted-in-general-ledger/90677/9, #177, #280. Also, others have expresed this requirement #859.

Describe the solution you'd like

My proposal in detail:

• A new DocType called something like EmployeeProviderType is just a collection of the available types of services that an Employee can select. ie: Health Insurance, Employee Fund, Risks Insurance, Retirement Mandatory Fund, etc... That can be set by every ERPNext implementator according to the local requirements.

• The Employee can now have a table where it can be assigned rows with the above EmployeeProviderType and a Supplier. Let's calle this table: EmployeeProviders. That election of Supplier can be changed at any time.

• On the Salary Component, on its Accounts section, along the Account, the EmployeeProviderType can be optionally be set by the implementor. Note: If none is set I would argue that the accounting entry should use the Employee for the Party Type and its Employee for the Party.

• Then, when the journal is being created by Payroll Entry, the script only has to check if the EmployeeProviderType is defined on the Accounts section of the Salary Component and set the Party Type as Supplier and set the Party to the one from EmployeeProviders that matches the EmployeeProviderType.

How does it sounds?

To me:

• It won't break anything on the current implementation, as the EmployeeProviderType is optional.
• It would set the missing information on the Accounting Entries used by the reports that may require them.
• It would remove the bug in HRMS that requires Accounts with no type set.
• It would provide flexibility for many use cases.

Describe the alternatives you've considered

All this could be implemented using Frappe customization capabilities, except for the server script that generates the Journal entry. If there would be any way to configure that script to accept custom fields for Party Type and Party on every Salary Components, that would suffice. But it would require extra steps for the implementor to deal with the sourcing of the fields when - to me - it is always about the Parties involved in a registry.

Additional context

Here is a manually generated Journal with the expected Party Type and Party that would allow to use ERPNext reports with that info:

[ruchamahabal]

#228

Employee wise accounting entries is already available

[maovidal]

Employee wise accounting entries is already available

That's right... Still it is missing that the script takes care of the rest of the entries of the Salary Components, not just the one related to the salary.

[maovidal]

I'm trying to figure it out a way to implement the journal modifications for our use case described above without changing the current HRMS source code v15.11.0.

One way I have experimented is to use a Server Script whose work is to intercept the the Journal or its GL Entry via the Validation event, but I have to make sure that the script performs changes only for those cases where that Journal is being generated by the Pay Roll entry (as we should not mess up the any other Journal entry)

Edit: I was able to solve it using that Server Script for the Journal Entry validation event. It checks over the whole accounts field the presence of reference_type with the value Payroll Entry. Any match, means it was produced by the Payroll, and from there, I make the adjustments to the Party Type and Party as needed for every record on accounts.

However, to me it does not seem the right way to solve it as it relies on matching records, instead of providing the right content from the start. I think all of us can benefit if the HRMS app can provide the Journal generated with proper parameters.

I don't feel confident enough to provide a proposal over the code, but if someone else is interested on this, I'm eager to learn and help.

[maovidal]

A recent validation enforcement for accounts that are not payable / receivable breaks the Server Script that we previously implemented.
In order to keep track of the Party (Provider) for every kind of deduction, we have created extra accounts to be able to identify them. But is is not ideal, as every employee can select different providers for the multiple deductions we have.