Try ERPNext Buy Support Partners Foundation

Payroll Entry - Editing List of Employees

Background:

  • On ERPNext Cloud (erpnext.com) hosting
  • Version 12.9.3 and Frappe Framework on v12.6.1

I was able to successfully create Salary Slips, corresponding Journals and Bank Entry, using the information available (this post and this article) and support from ERPNext Support Team.

And I also understand that while in [New Payroll Entry->Get Employees->Create Salary Slip->Submit Salary Slip-> Create Bank Entry] flow, manual edit of a draft Salary Slip (say, after “Payroll Entry -> Get Employees -> Create Salary Slips”) doesn’t work. “Submit Salary Slip” overwrites the edited draft Salary Slip.

But, what I couldn’t understand why I cannot edit the Payroll Entry to select (or de-select) employees against whom processing needs to be done. As correctly mentioned here, segregation on basis of predefined filters (Department, Grade or Designation) is definitely possible, but not sufficient.
The Payroll Employee Detail embedded in Payroll Entry is read-only. With no edit of any rows allowed even before “Submit Salary Slips” is done.

Use-cases: There are cases where we need to manually edit certain employee’s salary slip before submission (*). As the process of PayrollEntry->SalarySlip->BankEntry doesn’t allow hand-modified Salary Slips, I would like to remove these employees from processing (Payroll Entry … ) and process them manually (Edit Salary Slip -> Submit -> Create Journal Entries).

(*) in particular a case where we wanted to reduce the tax of an employee for a particular month for his/her financial reasons. It might not be a correct way to increase in-hand, but that is a secondary point.

Anyone can point me to any literature or manual where this reasoning can be concluded?
Or, is it just something we haven’t come around developing yet?

1 Like

Welcome to ERPNext shreyansh!

“Anyone can point me to any literature or manual where this reasoning can be concluded?”

A search like this https://github.com/frappe/erpnext/issues?q=is%3Aissue+is%3Aopen+manual+payroll

finds these example dialogues that help identify the nature of the ‘manual payroll’ problem, with options to implement and manage it:

Thanks for contributing to the discussion, perhaps other will chime in…

Hello @clarkej

Thanks for taking out time to search on my behalf.
I had searched and read through most of those before posting - to try and understand the rationale behind original restriction (which apparently I couldn’t figure out from these postings). I was thinking of investing my effort to solve with my limited capability.

Nevertheless, thanks for directing.

I think you bring up a valid use scenario. For now the easiest approach to this could be a Process Payroll for the Month in the Employee Master with a Yes/No option and extending the Predefined Filter to include this Custom Field. I know it’s not a very elegant solution, but maybe the easiest to implement.

Either ways you should put in a GitHub https://github.com/frappe/erpnext/issues. You can put in both options, or whatever option you think serves you best.

The other option is to not submit the salary slips when you click the Process Payroll button and then manage the payslips that you want not submitted or changed manually.

Not the best of solutions, but maybe your GitHib issue will gain traction and this will get built.

Hope this helps.

Thanks

Jay

Sure. Thanks for suggesting. I will put it up and also link to pages which Clarkej had suggested.
Though I am not really a developer in true sense, I would be happy to contribute and fix/feature this, if I can get my head around it :slight_smile:

You can just put the business need and put in some mock up screens about how you see it getting implemented. Some developer will pick it up when s/he is ready for that.

Thanks

Jay

If you delete a Salary Slip created by Payroll Entry while it’s still in draft stage, it will be excluded from the Journal Entry. This is a clumsy solution, though, in part because the employee’s name is still listed.

The way to customize individual salary slips is with the “Additional Salary” doctype. You can either add new earnings/deductions, or override existing ones. Again, not the most intuitive approach, but it works.

Actually the intent was to delete the row in the Payroll Detail table (in Payroll Entry). That way Payroll record doesn’t have entry for that employee and hence missing journal is not relevant.
Though, this does have a fallout - payslip for that employee, row for whom was deleted, might remain in draft and referenced to this Payroll entry.

Even in this case, the Payroll Entry submission (Submit Salary Slip button) is designed to overwrite the already created Salary Slip in draft - that is, in my observation, it rewrites all the entries in the draft salary slip and submit them before returning control back to user.
Is my observation wrong?

Or, maybe you are hinting at an external to Salary Slip “Additional Salary” which can be created post submission of Payroll Entry but which is equal impact of a component?

Correction: actually the row is expected to be deleted before clicking create salary slips so my point of salary slip in draft is invalid.
Create Payroll > Get Employees > Delete rows fro Payroll Details table > Create Salary Slips > Submit …

Right, I understand. That’s a better solution in every way, because then the Payroll Entry document accurately represents the salary slips that have been created.

But, it is possible to manually delete the Salary Slip you don’t want between the “Create Salary Slips” and “Submit Salary Slips” steps. If you do that, the deleted salary slip will not be recreated or reflected in the journal entry. (As said, this is misleading, though, because the employee’s name will still be listed in the payroll entry, even though no slip exists and even though the journal entry does not include him/her.)

The trouble is this line in the code:

When the “Submit Salary Slips” button is pressed, the Payroll Entry re-fetches all employees, just like it originally did when pressing the “Get Employees” button. If instead the slips were created according to the employee details child table, the problem would be fixed without too much difficulty.

The issue here is not the Payroll Entry doctype but the Salary Slip doctype itself. When generated by a Salary Structure, Salary Slips are not intended to be edited manually (though this isn’t indicated clearly, and that could be improved). To modify a salary slip, you’re supposed to create an Additional Salary document before going through the payroll entry process. You could also do it when the Salary Slips are in draft phase, but not after they’ve been submitted.

The name here is a little misleading. Additional Salary is often used for bonuses (hence the name), but it can be used to manually adjust any earning or deduction.

Thanks for the point out. I was reading through code and this helps me find direction.

Your point is valid where we need “additional earning or deductions”. But there would be other cases, like mine, where changes to payout are required. In my case, it was modification of taxation - which is why it cannot be treated as “additional salary”.
So, ideally - you are correct that additional salary can suffice. But some real-life situations/use-cases won’t fit on this.

It will work for changes to payout, including tax. Just make sure the “Overwrite Salary Structure Amount” option is ticked. The functionality is what you want, I believe. It’s just the name that’s misleading.

Interesting. I didn’t think of it that way earlier. Thanks a lot.
I will attempt in my environment and update here.

Apologies for delay in replying.
I tried with “Additional Salary” as a Component and I was able to achieve one part of my requirement of changing taxation of a particular employee - for whom the “Payroll Entry” -> “Bank Entry” process was to be done. @peterg thanks for that input - it was most useful.

I will create a github entry for allowing edit of the employee list generated for a payroll entry. That is definitely a good feature which can provide some flexibility to HR module for salary processing.

1 Like