Architecture design method for ERP (Enterprise Resource Planning) system

Abstract

The invention belongs to the field of ERP (Enterprise Resource Planning) systems, and particularly relates to an architecture design method for an ERP system, which comprises a split application layer and a split data layer, the splitting application layer splits order management, commodity management, production and purchase, warehouse management, logistics management and financial management into subsystems of an order management system, a commodity management system, a production and purchase system, a warehouse management system and a financial management system. The split data layer comprises an order database, a commodity database, a production and purchase database, a storage database and a financial database, the order database is connected with the order management system, the commodity database is connected with the commodity management system, the production and purchase database is connected with the production and purchase system, and the financial database is connected with the storage database. And the storage database is connected with the warehouse management system. The method is reasonable in design, can enable the ERP to have the characteristic of high expandability, improves the operation performance of the system, and facilitates the version updating.

Description

Technical Field

[0001] The present invention relates to the technical field of ERP systems, and in particular to an architecture design method for an ERP system. Background Art

[0002] The functions of the ERP system are mainly composed of modules such as order management, product management, production procurement, warehouse management, logistics management, financial management, and statistical analysis. The traditional development model is to establish a single-block architecture application with only one database. The code files of each module are in one project. In the early stage of the project, due to the small amount of data, the system performance was normal. However, as time goes by, various data continue to accumulate, and the system runs slower and slower, especially when multiple data tables are jointly queried during report queries, which causes the system speed to become slower and slower, greatly affecting work efficiency.

[0003] The usual solution is to optimize the database. Possible operations include deploying the database separately to a server, separating the application and the database, creating indexes for each table, modifying the data type of the table field, optimizing the writing of stored procedures, etc. Through such optimization, the performance of some functions of the system can be significantly improved. However, we found that the query and export of some data with many associations is still very slow, or after the accumulation of data volume, the originally faster query and analysis also become slower and slower. Finally, after exhausting various methods, the ideal performance speed cannot be achieved, which goes against the original intention of the enterprise to develop ERP, fails to improve efficiency, and affects the advancement of the overall business. Therefore, we propose an architectural design method for ERP systems to solve the above problems. Summary of the invention

[0004] The purpose of the present invention is to solve the shortcomings of the prior art and to propose an architecture design method for an ERP system.

[0005] In order to achieve the above object, the present invention adopts the following technical solutions:

[0006] An architecture design method for an ERP system, comprising a split application layer and a split data layer, wherein the split application layer splits order management, commodity management, production procurement, warehouse management, logistics management, and financial management into subsystems of an order management system, a commodity management system, a production procurement system, a warehouse management system, and a financial management system;

[0007] The split data layer includes an order database, a commodity database, a production and procurement database, a storage database, and a financial database. The order database is connected to an order management system, the commodity database is connected to a commodity management system, the production and procurement database is connected to a production and procurement system, the storage database is connected to a warehouse management system, and the financial database is connected to a financial management system;

[0008] It also includes a Wed module, a sales department, a supply chain department and a finance department, wherein the sales department, the supply chain department and the finance department are all connected to the Wed module, and the order management system, the commodity management system, the production and procurement system, the warehouse management system and the financial management system are all connected to the Wed module.

[0009] Preferably, the split application layer adopts the "microservice" architecture concept to split the traditional large and comprehensive single-process architecture into independent applications according to business modules, so as to achieve smooth system updates and facilitate load expansion.

[0010] Preferably, ERP is also included, and the front end of ERP is treated as a separate application, only accepting simple parameters, and calling the interfaces of other microservice programs in the background to obtain the data required for display.

[0011] Preferably, the microservices are used as a business logic layer, and each microservice is a program that can be deployed independently and provides a data access interface to the outside world.

[0012] Preferably, the subsystems of the order management system, product management system, production procurement system, warehouse management system, and financial management system can be developed and maintained by different teams, using different technical systems and different databases.

[0013] Preferably, the split data layer only allows us to obtain data through the other party's service interface and cannot directly associate with the private database of the other party's service.

[0014] Preferably, the split data layer can deploy multiple databases on multiple servers, thereby reducing the database load pressure.

[0015] Preferably, if the web module subsystem calls the warehouse management system to obtain data, we need to create a service method in the warehouse module to assemble the data and then return it to the web subsystem.

[0016] Beneficial effects of the present invention:

[0017] 1. Split the application layer to split the traditional large and comprehensive single-process architecture into independent applications according to business modules, so as to achieve smooth system updates and facilitate load expansion;

[0018] 2. Split the data layer. By splitting the data layer, data can only be obtained through interfaces, and the other party’s private database cannot be directly associated. In this way, multiple databases can be deployed on multiple servers to reduce database pressure.

[0019] 3. It can make ERP highly scalable, improve system performance and facilitate version updates. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 A block diagram of an architecture design method for an ERP system proposed by the present invention;

[0021] Figure 2 A block diagram of a warehouse management method for an architecture design method of an ERP system proposed by the present invention. DETAILED DESCRIPTION

[0022] The technical solution of the present invention will be clearly and completely described below in conjunction with specific embodiments. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0023] When a component is referred to as being "disposed on" another component, it can be directly on the other component or there can also be an intermediate component. "Disposed" indicates a way of existence, which can be a connection method such as connection, installation, fixed connection, active connection, etc. When a component is considered to be "connected" to another component, it can be directly connected to the other component or there can be an intermediate component at the same time.

[0024] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art of the present invention. The terms used herein in the specification of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention. The term "and / or" used herein includes any and all combinations of one or more related listed items.

[0025] Embodiment 1

[0026] Reference Figure 1 , an architecture design method for ERP system, including splitting application layer and splitting data layer. Splitting application layer splits order management, commodity management, production procurement, warehouse management, logistics management, and financial management into subsystems of order management system, commodity management system, production procurement system, warehouse management system, and financial management system. Splitting application layer adopts the concept of "microservice" architecture, splitting the traditional large and comprehensive single process architecture into independent applications according to business modules, so as to achieve smooth system update and facilitate load expansion;

[0027] The split data layer includes order database, commodity database, production and procurement database, storage database, and financial database. The order database is connected to the order management system, the commodity database is connected to the commodity management system, the production and procurement database is connected to the production and procurement system, the storage database is connected to the warehouse management system, and the financial database is connected to the financial management system. The subsystems of the order management system, commodity management system, production and procurement system, warehouse management system, and financial management system can be handed over to different teams for development and maintenance, using different technical systems and different databases. The split data layer can deploy multiple databases on multiple servers, thereby achieving load database pressure;

[0028] It also includes Wed module, sales department, supply chain department and finance department. The sales department, supply chain department and finance department are all connected to the Wed module, and the order management system, product management system, production procurement system, warehouse management system and financial management system are all connected to the Wed module.

[0029] In this embodiment, ERP is also included, and the front end of ERP is treated as a separate application, which only accepts simple parameters and calls the interfaces of other microservice programs in the background to obtain the data required for display. The microservice is used as the business logic layer, and each microservice is a program that can be deployed independently. It provides a data access interface to the outside world and splits the data layer. We are only allowed to obtain data through the other party's service interface, and cannot directly link to the private database of the other party's service.

[0030] Embodiment 2

[0031] Reference Figure 1-2 , an architecture design method for an ERP system, including a split application layer and a split data layer, the split application layer splits order management, commodity management, production procurement, warehouse management, logistics management, and financial management into subsystems of an order management system, a commodity management system, a production procurement system, a warehouse management system, and a financial management system, the split data layer includes an order database, a commodity database, a production procurement database, a storage database, and a financial database, the order database is connected to the order management system, the commodity database is connected to the commodity management system, the production procurement database is connected to the production procurement system, the storage database is connected to the warehouse management system, the financial database is connected to the financial management system, and also includes a Wed module, a sales department, a supply chain department, and a financial department, the sales department, the supply chain department, and the financial department are all connected to the Wed module, and the order management system, the commodity management system, the production procurement system, the warehouse management system, and the financial management system are all connected to the Wed module.

[0032] In this embodiment, the application layer is split, and the "microservice" architecture concept is adopted to split the traditional large and comprehensive single-process architecture into independent applications according to business modules, so as to achieve smooth system updates and facilitate load expansion. ERP is also included, and the front desk of ERP is treated as a separate application, only accepting simple parameters, and calling the interfaces of other microservice programs in the background to obtain the data required for display. Microservices are used as business logic layers, and each microservice is a program that can be deployed independently, providing data access interfaces to the outside world. The data layer is split, and we are only allowed to obtain data through the other party's service interface, and cannot directly link to the other party's service's private database. The subsystems of the order management system, product management system, production procurement system, warehouse management system, and financial management system can be handed over to different teams for development and maintenance, using different technical systems. Using different databases and splitting the data layer can deploy multiple databases on multiple servers, thereby reducing the database load. Assuming that the web module subsystem calls the warehouse management system to obtain data, we need to create a service method in the warehouse module to assemble this data and then return it to the web subsystem. The warehouse management method first obtains the material code of the local inventory table and the warehouse name field information of the warehouse table, and after paging, it is finally ready to return 20 data to the Web module. The material ID in these 20 data is used as a parameter to request the commodity module subsystem. The commodity subsystem returns the commodity information related to these 20 material IDs to the warehouse management module, and then the warehouse management module reassembles the two field data of material name and category required for the list to realize the data that will eventually be returned to the Web subsystem.

[0033] In the present invention, the traditional large and comprehensive single-process architecture is split into independent applications according to business modules, so as to achieve smooth system updates and facilitate load expansion; the data layer is split. By splitting the data layer, data can only be obtained through interfaces, and the other party's private database cannot be directly associated. In this way, multiple databases can be deployed on multiple servers to reduce database load pressure; thereby, ERP can be highly scalable, improve system performance, and facilitate version updates.

[0034] The above is a detailed introduction to the architecture design method for an ERP system provided by the present invention. This article uses specific embodiments to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present invention, several improvements and modifications can be made to the present invention, and these improvements and modifications also fall within the scope of protection of the claims of the present invention.

Claims

1. A method for designing an architecture for an ERP system, characterized in that: It includes a split application layer and a split data layer. The split application layer splits order management, product management, production procurement, warehouse management, logistics management, and financial management into subsystems of order management system, product management system, production procurement system, warehouse management system, and financial management system. The split data layer includes an order database, a commodity database, a production and procurement database, a storage database, and a financial database. The order database is connected to an order management system, the commodity database is connected to a commodity management system, the production and procurement database is connected to a production and procurement system, the storage database is connected to a warehouse management system, and the financial database is connected to a financial management system; It also includes a Wed module, a sales department, a supply chain department and a finance department, wherein the sales department, the supply chain department and the finance department are all connected to the Wed module, and the order management system, the commodity management system, the production and procurement system, the warehouse management system and the financial management system are all connected to the Wed module.

2. The architecture design method for an ERP system according to claim 1, characterized in that: The split application layer adopts the "microservice" architecture concept to split the traditional large and comprehensive single-process architecture into independent applications according to business modules, so as to achieve smooth system updates and facilitate load expansion.

3. The architecture design method for an ERP system according to claim 1, characterized in that: It also includes ERP, and the front end of ERP is treated as a separate application, which only accepts simple parameters and calls the interfaces of other microservice programs in the background to obtain the data required for display.

4. The architecture design method for an ERP system according to claim 1, characterized in that: The microservices are used as the business logic layer, and each microservice is a program that can be deployed independently and provides a data access interface to the outside world.

5. The architecture design method for an ERP system according to claim 1, characterized in that: The subsystems of the order management system, product management system, production procurement system, warehouse management system, and financial management system can be developed and maintained by different teams, using different technical systems and different databases.

6. The architecture design method for an ERP system according to claim 1, characterized in that: The split data layer only allows us to obtain data through the other party's service interface, and cannot directly connect to the private database of the other party's service.

7. The architecture design method for an ERP system according to claim 1, characterized in that: The split data layer can deploy multiple databases on multiple servers, thereby reducing the pressure on the database load.

8. The method for designing an architecture for an ERP system according to claim 1, characterized in that: Assuming that the web module subsystem calls the warehouse management system to obtain data, we need to create a service method in the warehouse module to assemble this data and then return it to the web subsystem.

Images