Be updated, subscribe to the OpenKM news

Integration of document management system and ERP

Written by Ana Canteli on April 29, 2022

Application integration projects are goals that all organizations reach sooner or later. Initially, provisioning and configuring the suite of applications a company uses start intuitively or casually. They are generally based on the previous experience of their members when not letting themselves be carried away by attractive offers or effective marketing promotions.

 Then, over time, the staff and especially the managers and middle managers, realize the practical and opportunity cost of not investing in interoperability. Users are obliged to change the application every two times three, collect information from one side, transfer it to another to continue with the work; with all the dangers that this implies: malpractice, lack of compliance, risk in data protection management, loss of information, to name just a few.

For all this, it is not uncommon to find companies that have ERP and document management systems in their suite of programs. And although, at first, it may seem that both software overlap. A multitude of advantages can be obtained from their integration.

Benefits of the integration between a document management software and an ERP

• Immediate access: thanks to the integration, a user can start a business process from an application, knowing that the company's program platform will help them carry out their work quickly and easily.
• Time optimization: due to the benefits derived from the improvement of interoperability, the time invested in queries and locating, distributing, and sending files is considerably reduced.
• Better traceability: an integrated software suite improves documentation tracking and control.
• Improvement of sophisticated processes: such as storage elimination or file expurgation and getting better reports or metrics. Thanks to the integration, these objectives can be addressed globally.

Integration process

When considering the possibilities and even the suitability of integration, it is necessary to consider many factors.

To begin with, the ideal approach is that human resources have a certain degree of experience, both from the technical point of view and from the end-user, to determine the starting point, the objectives, and the technical, human, and calendar mean of milestones to be pursued. We can ensure a feasible, reliable, and harmonized integration between all the parties involved.

Another element to take into account is the documentation of each solution. A priori, all ERP and document management software worth their salt today should have resources to facilitate integration with third parties. OpenKM is a document management system that, through the OpenKM Knowledge Center, provides access to the set of available resources to extend and expand the functionalities and possibilities of the document manager. A priori, the same should be expected from the ERP provider.

At OpenKM, we have extensive experience in the field of integrations. The OpenKM team is prepared to lead integration projects and play accompanying roles in the integration process.

In this scenario, we have many possibilities, so we will address the most critical cases in this post.

In the OpenKM Kcenter, we will access the complete API of the document management system. Also, the SDKs in Java, .NET, and NodeJS. In the case of PHP, OpenKM provide examples of the methods upon the clients' request.

As we said above, there are several scenarios for integrations.

Scenario 1: Shared folders

We have the ERP, where the organization manages documentation such as invoices, delivery notes, etc. An integration option is shared folders. In a shared folder of the ERP, we deposit a series of files, with a CSV for each file. Here OpenKM, through a process that is activated periodically, reads the content saved in the shared folder, from where the contents are transferred to the document management software.

Scenario 2: UID

The document management system selects a document in output status, stipulating an ERP identifier in the CSV. OpenKM generates an exchange file, where the ERP identifier corresponds to the UUID (Unique Universal Identifier) ​​in the document manager. And the integrations between applications, we look for the other application to register the UUID in a table or other means within its system. Once this occurs, access to the document saved in OpenKM is immediate.

Scenario 3: API

If we use the API, the case will depend on the options provided by the ERP; the programming language, among other aspects. Some allow the OpenKM libraries to be used directly in Java, NodeJS, and NET. In other cases, integration requires more development. -The ERP in this post represents any application you want to integrate with OpenKM-. Said application would have a programmed event that would be activated to make an API call. For example, if I want to upload a document, I would call it the "upload document" method. We could upload document metadata, and the document manager could respond with the UUID, being the identifier captured by the ERP, although this does not have to be the only option. It may be that from the ERP, we are only interested in making queries to the document manager based on the metadata. In this scenario in the ERP, we do not store any OpenKM identifier; We only work with metadata (date, invoice number, etc.). These data, through the API, are used to retrieve the information.

There are essential factors such as the volume of files per day. That will determine if the integration has to be run in real-time or in batches. For example, a financial institution that uploads 20,000 documents a day. In this scenario, it is unlikely that the organization will need to import the documents in real-time. It may join outside business hours; it also has advantages since a load of operations will not negatively affect the performance of the hardware for the users.

Customization

Customizations are also a factor to consider. The user does not see the OpenKM interface directly but instead sees another application that uses the API, which acts as an intermediary. It is another use case in which we have to consider the load caused by having users connected directly to the document manager, which is different from the use of specific actions available in the API.

The method that offers the most potential is to upload a document. OpenKM will do the creation of the route and the insertion of metadata. With the OpenKM API, the organization will be able to create high-level methods to upload documents with a binary file, the metadata - including everything necessary. Later, when a user uses the document manager, it does everything internally so that the process is transparent for the user is achieved through the plugin architecture.

A practical example could be the treatment of identification documents in a public administration. If a person has a national identity document, the standard method will be followed. If a person does not have said document, data such as a photograph, name, surnames, date, and place of birth may be requested. With these data, the system can create the identification document. If the person has an identification document, the system responds with the information. 3 Methods to address the three possibilities that can occur in the same case; that the user fulfills the condition, that the user does not complete it, and that what is necessary can be done so that it does.

We find all the information we need to use this option in the documentation. In this case, the REST plugins are the most interesting since a class is created and copied to the service that allows the desired tasks to be carried out. This way, we avoid making 4-5 calls to the API, which is an appropriate option for some instances. Otherwise, you call more complex methods responsible for performing more sophisticated tasks.

The underlying philosophy is that the OpenKM API has methods for, for example, uploading documents and adding metadata. But when you want to integrate the document manager with an application, it is more interesting to create a method, a custom API call, to which you send some inputs to obtain the desired outputs. If you manage to save the number of calls, we will be able to optimize performance, especially when handling large repositories.

If you want more information or have any questions regarding the possibilities of integrating OpenKM into your suite of programs, do not hesitate to contact us.