-
Notifications
You must be signed in to change notification settings - Fork 7.1k
Migration Guide to ERPNext version 14
As we announced at the last year’s ERPNext Conference, we broke the monolith architecture of ERPNext in version 14 and separated out the following modules into new apps.
- Healthcare
- Hospitality
- Non-Profit
- Education
- Agriculture
- HR and Payroll
- Datev Integration
- Germany Localisation
- E-commerce Integration
How does this change affect you?
If you are currently not using any of these modules, this change won’t affect you.
However, if you are using any of these modules, when you upgrade to version 14, you will have to install the relevant app on your bench.
From the user's point of view, it won’t make any difference, there will be no loss of functionality.
If you want to raise any new issues or pull requests, you will have to raise them on the respective repository instead of raising them on the ERPNext repository.
We have moved all the India Taxation and Compliance features from ERPNext to a separate app called India Compliance which will be maintained primarily by Resilient Tech.
Except for the breaking changes listed on discuss.erpnext.com all the other functionalities are expected to work as they do now. Patches have been put to take care of other changes.
In order to continue the E-Invoicing feature, users will have to subscribe to paid in-app service, your current API credentials won’t be functional along with this app.
Until version 13, the subcontracting feature was managed via the Standard Buying cycle. But in version 14, we have introduced a new module Subcontracting to manage the functionality. We have refactored the entire workflow and introduced two new documents called Subcontracting Order and Subcontracting Receipt.
For the existing users, we also kept the old workflow which they can use to complete the open subcontracting Purchase Orders. But for the new subcontracting orders, they need to follow the new workflow (PO → Subcontracting Order → Subcontracting Receipt).
In version 14, we have introduced a new document Payment Ledger to maintain the links between the Invoices and Payment Entries. Earlier we used to store the information (Against Voucher Type and Against Voucher) inside the GL Entry document, which was a bottleneck for the immutability of the GL Entries. It will also improve the performance of the Payment Reconciliation and execution time of Accounts Receivable/Payable reports.
We still did not remove that information from the GL Entry document, but we will remove those fields after a few months. Hence, if you made (are going to make) any report/feature using that information, please implement that using the new Payment Ledger.
We have done a lot of enhancements in the CRM module. As communications and activities are the most important functionalities of CRM, we have introduced dedicated tabs for Activities and Notes. We have also added a new document called Prospect to maintain the information of the organization. This document shows all the related leads, opportunities and communications in a single place.
In this process, we also made following breaking changes.
- Removed Next Contact Date, Next Contact By and Ends On fields from Lead and Opportunity. Now, it will be managed by new Events functionality. Based on existing data, we have created Events where Next Contact Date was set within the last one month.
- Renamed designation field to job_title.
- Renamed converted_by field to opportunity_owner.
- Lead will be disabled automatically after it is converted to an Opportunity.
Using this feature the GL Entry against a cost center can be split against multiple cost centers. In the Cost Center Allocation document, you can define allocation percentages of the child cost centers. Based on this allocation, the system posts multiple GL Entries against each cost center.
In version 13, we have a feature called Distributed Cost Center using which we can define the allocation percentages between multiple cost centers. Based on the allocation, we used to get the multiple financial reports based on the distribution, but it had no effect in the actual GL Entries.
It has certain drawbacks, like it does not take care of changes in the distribution over time. In the real world, cost center allocation keeps changing over time and based on updated allocation the system should book income/expenses against it, it should not be calculated run-time.
We have added a patch to migrate the existing data which will create Cost Center Allocation records based on the existing distributions.
We have removed Naming Series tool from ERPNext and added the same functionality in the frappe framework named Document Naming Settings.