Separation of HR & Payroll modules into an app

Following the separation of the domains (Healthcare, Non-Profit, etc.) we have now created a new app to house the HR & Payroll modules:


  • Not everyone signing up for an ERP would want to have HR & Payroll modules. Reduce junk (~10.4 MB).
  • These modules were perpetually overshadowed by other modules and never got an independent identity.
  • Easier maintenance.

Why not standalone?

Having said that, this app is not standalone and needs ERPNext as a dependency. Unlike other modules that were separated from the ERPNext core, HR and Payroll have a high dependency on the core. Some doctypes from HR are also widely used in the ERPNext core.

Some widely used doctypes (Employee, Department, etc.) still remain in the core. You can read more details in the PR Description:

What next?

  • If you are not using the HR & Payroll modules, this change won’t affect you.

  • If you are using these modules, it will work as is in version 13. All bug fixes and security fixes will be backported to version 13 as well. However, when you upgrade to version 14, you will have to install the HRMS app.

  • If you want to raise any new issues or pull requests, please raise them on the HRMS repo instead of raising them on ERPNext.

  • If you face any issues during migrations or app installation do let us know by opening an issue.

  • Star the repo :see_no_evil:


Suppose, I install version 13 and I upgrade to version 14 then install hrms custom app then all data will be there?

Yes. There shouldn’t be any data loss.

All data that is present in v13 should be there after upgrade too.



One more question, Before upgrade to version 14, I have to install hrms custom app?

1 Like

You have to upgrade to V14 and then install HRMS app.

Users can’t install HRMS app on V13 as it is already part of ERPNext in V13.


Just curious to know the use of “full_and_final*” doctypes(eg: full_and_final_asset) in the new app as I do not see any particular documentation for it.

1 Like

This feature was introduced in v14. Documentation for some features is still missing. We will be working on documentation updates soon.

Linking the PR for context:


I’m in favor of this generally, but there are some migration considerations. Generally I think there’s an overuse of the Employee doctype outside of the HR module and it’s better to use User for a number of reasons.

SELECT `tabDocField`.fieldname, `tabDocField`.parent, `tabDocType`.module FROM `tabDocField`, `tabDocType` WHERE `tabDocType`.name = `tabDocField`.parent AND `tabDocField`.options = 'Employee' AND `tabDocType`.module NOT IN ('HR', 'Payroll');

| fieldname     | parent                              | module        |
| custodian     | Asset                               | Assets        |
| from_employee | Asset Movement Item                 | Assets        |
| to_employee   | Asset Movement Item                 | Assets        |
| employee      | Supplier Scorecard                  | Buying        |
| employee_link | Supplier Scorecard Scoring Standing | Buying        |
| employee_link | Supplier Scorecard Standing         | Buying        |
| employee      | Instructor                          | Education     |
| employee      | Healthcare Practitioner             | Healthcare    |
| employee      | Lab Test                            | Healthcare    |
| operator      | Downtime Entry                      | Manufacturing |
| employee      | Job Card Time Log                   | Manufacturing |
| employee      | Activity Cost                       | Projects      |
| employee      | Timesheet                           | Projects      |
| to_emp        | Authorization Rule                  | Setup         |
| employee      | Sales Person                        | Setup         |
| employee      | Delivery Trip                       | Stock         |
| employee      | Serial No                           | Stock         |

Yes, we have considered this and we would be reducing such dependencies in the next phase. This change seemed too heavy in the first phase due to other dependencies on employee.

I see that the Payment Entry doctype has been refactored to allow apps to define a list of doctypes in hooks. That’s great. Can I ask if this is also the plan for the Education module’s Fees doctype?

In the latest v14-beta, the Fees doctype is currently non-functional because all references have been removed from Payment Entries.

This isn’t that hard and not doing it will result in broken apps. I think its better to make people switch when the data model changes, not when it suits them.

Can I separately install/use HR & Payroll software? without installing ERPNext?

I just this doesn’t drag too much time on releasing v14

If I understood Rucha correctly, Employee will remain a part of ERPNext, not HRMS:


That seems to be correct, and the Employee doctype has been added to the Setup module on the develop branch.

I think that makes sense from a design standpoint. Many companies would need to store employee details, without necessarily also using ERPNext for payroll and hr.



There is a simple question, is there a possibility to add the feature of “Share Cost in Payroll” which means dividing salaries on more than one project according to the percentage.

This is unrelated to this issue, please start a new thread (ideally with a longer description of your requirement). I’m interested in this feature, tag me and I’ll help out. @ERP_Implementer1

1 Like

Dear @tmatteson,

Thanks for the clarification, but I saw the topic on the other hand, as this topic talks about the human resources module, so I thought that if it was possible to add a new feature.

Your words will be taken into account and a topic for “Share Cost” will be created and the topic will be shared with you.

Thank you again.


I have opened a new topic …