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?
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.
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 Issues · frappe/erpnext · GitHub. 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.
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
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.
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.)
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 documentbefore 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.
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.
Hello,
If you allow me to add my claim , I’d like payroll to assign salary for each employee so I can see in each employee account (Party) salaries waiting for payment , now it is adding total of all salaries to payroll account.
If cost center can be decided also from payroll that will be great
Though I wouldn’t like to claim that this requirement is not valid, there is a particular reason why salary is not processed like a usual Supplier Invoice or Expense Claim.
In case of Expense Claims or Supplier Invoices, it is very easy to create reports for outstanding payments.
But, in case of Salaries, the usual practice (^) is to bunch them together to show single payment entry.
Even then, the Salary register can actually show the breakup of each individual employee. What it will not show is whether it is paid or not.
I am assuming you are looking for a way to know if it is paid for each employee for each month. Am I understanding correct?
(^) This practice stems from the fact that Salary is usually a more private data than supplier invoices and hence some HR team practice that Accounts (which does the real payment) only deals in moving money from Bank to employee - rather than recording such individual payments in ledger.
@elnaggar What you’re asking about is certainly doable, but it requires a change to core code. In technical terms, you need the Journal Entry created by the payroll workflow to be disaggregated by employee for all payable salary components. Right now, if your payroll liability accounts are designated “Payable” (i.e., requiring a specific party be listed), the Payroll Entry doctype fails with an error message.
I’ve adjusted the Payroll Entry docytpe to respect payable liability accounts, and you can see the code in a pull request I created. It never got merged, for reasons I don’t really understand, but perhaps the code would be useful to you.
Many thanks for your reply , you understanding is definitely right , I got the point that system prefer to make one payment for total salaries though I expected they considered other scenarios like for example in my case we may pay some of the employees and delay others based on cash flow.
I understand that without customized code no way to do that , am I true? can’t I utilize employee cost center to get similar result?
