I need your input in order to lay this report to rest:
The problem is that ERPNext presently assumes that every body’s fiscal year will begin on the first day of the month. Therefore, when creating Salary slips and doing Process Payroll, ERPNext looks to the fiscal year to determine what start and end date to use.
If you are paying on a monthly frequency, in @gavagai case as reported above, the company’s fiscal year starts on the 16th. Therefore ERPNext uses 16th as the start date and 30st/31st as the end_date.
A temporary dirty fix is to users to change their Fiscal year to the first day of the month or pay twice in a week.
Proposed Solution
I’m proposing to create a new Doctype called Payroll Cycle. Payroll Cycle would encapsulate all the information pertaining to a company’s payroll cycle. Process Payroll and Salary Slip will then make use of information in the applicable Payment Cycle.
The Payroll Cycle would contain the following fields:
Payroll Cycle Name e.g All Employees, Senior Employees, Junior Employees, Contract Employees, etc. The name should make it clear which group of employees the cycle relates to.
Frequency - “monthly”, “weekly”, etc This value can only be set once. The frequency is the interval between payment periods.
Company
Is Active
Apply To All Employees: A check box that is unchecked by default. Useful for organizations that have the same payment cycle for all employees.
Designations. A table containing the employee designations for which this Payroll Cycle applies. An active Payroll Cycle cannot contain a designation that is already contained in another active Payroll Cycle. If Apply To All Employees is checked, Designations will be of no effect.
Payment periods. This a table containing the Payment Period dates for the Payment Cycle. Gaps between dates are not allowed. Payment periods should also be saved on or before the last date of the payment period. e.g, if today’s date is 01.07.2017, you will not be able to add a payment periods for 01.06.2017 - 0.06.2017
The advantage of this approach is greater flexibility.
Please give your feedback concerning the design and possible short comings of this approach. You can also add likes to show your support of the new feature.
Great proposal except that I wonder if designations is the best way to group together employees whose payments should be processed together.
Perhaps a field on Employee should be introduced which is more descriptive of the need to group specific sets of employees together for purposes of generating payments. Perhaps something like “Payroll Group” or “Payroll Area”. Probably should be mandatory as well. This field would then be used as the filter in the Payroll Cycle to specify what group of employees the Cycle addresses.
How would the actual payroll run be performed? Background job? User initiated daily?
Thanks for the feedback @Chude_Osiegbu
Designation is the only field which I think can sufficiently group employees for payment. Also, I cringe at the thought of making users have to manually update a new field for all Employee records. With the present proposal, all that is needed to be done after implementation is to simply:
Create a new Payroll Cycle,
Add the name,
Add the frequency,
Add the designation(s),
Add the Payment Period dates and
Click save.
On second thoughts however, I’ll add to the proposal to add an option to add all designations to a Payment Cycle. That way, organizations that have the same payment cycle for all employees will even find it easier to work with.
Just that job designation isn’t typically the basis for grouping employees for purposes of payroll. Typically you would use concepts like Payroll Areas, Payroll Groups etc. Perhaps one of the following options might be worthy of consideration:
Whatever grouping field is added could then be made optional so that it doesn’t force users to have to update all employees masters before being able to run payroll. For those who would not want to make a grouping, a payment cycle would then be able to be created with a wild-card value for this field such that every employee is picked up. For those who want to make the groupings they could then go and specify the groupings they want.
The basis for grouping could be made flexible based on some/any fields on the Employee masters this would give some people the option to group by say Department, while others could decide to group by Designation or Branch, Employee Number or even Salary Mode.
In addition, the proposal would then involve removing Branch, Department and Designation as “selectors” in the Process Payroll doctype and replacing them with an item table of the different Payroll Cycles we would want to process. As per one of your points, any unprocessed employees selected in the Process Payroll would not then be able to be processed by another Process Payroll run until the former one is completed or cancelled.
This option still has the problem I’m trying to avoid which is forcing users to have to update all their employee records.
I really like this idea. It could make for really flexible pay runs. However, I wish more people would chime in so we can gauge if users actually need such flexibility because this option would add complexity (in the programming). I believe most small and medium companies keep really simple payrolls for administrative sanity, ease of use, bank reconciliation and possibly easier tax returns.
The second option, if implemented also means removing the Branch, Department fields from Payroll process which is not part of my plan. Those fields act as filters so if for any reason there is need to run payroll for just a section of those in the Payroll Cycle, Process Payroll will simply pickup those who match all the fields in the Process Payroll form. There won’t be need to create a new Payroll Cycle.