The ultimate guide for a successful odoo-ERP-implementation   Free Download

Selecting your Software – What you should pay attention to

When you are faced with a choice of software solutions, you should know what precisely you are deciding on. In this blog, we would like to draw your attention to a few parameters that we think are important for such a decision.

In the following, we present comparisons mostly between SAP, Navision, and Odoo. Not just because customers usually include Odoo in their shortlists together with these respective vendors, but also because we are in a position to assess these products based on past migration assignments from these solutions to Odoo. And because they all have a very similar, i.e., integrated, international, and generalized approach. None of these systems focusses on a specific industry sector, area, country, or company size.

Right-to-use vs. Community

One essential difference between Odoo and the „classic“ systems are their respective licensing models. Although you have to pay for licenses in Odoo as well, they are linked to the maintenance contract and the Enterprise package. In other words, if a customer no longer sees an added value in these products, he may either cancel the Enterprise contract or cease to extend it. As a consequence, the warranty expires, and Odoo is no longer obliged to fix programming bugs. The migration of the database has to be done by the customer himself (there are various approaches to solving this issue; they may not be convenient, but there are alternatives!), and the Enterprise modules have to be removed from the server. But the system itself and all its customizations can still be accessed and used!

The classic licensing model of closed systems (such as SAP and Navision) is an entirely different kettle of fish. You only purchase the right of use from these providers with your licenses, and once you stop paying for them, further access is no longer possible.

Migration and Data

Today, IT systems evolve considerably faster than 10 years ago due to the agile approaches in software development. Consequently, the question of updates has become an essential issue in the decision-making process. It is no accident, i.e., that Microsoft has switched Windows to a so-called „rolling release,” where versions have become an extinct species (which is, by the way, a feature taken from the Open Source world).

But new versions do not only have problems with changes in the front-end, but data also have to be migrated. It is, of course, easiest to have your provider operate your solution through a Cloud, which takes care of the whole problem, including the data issue.

However, relinquishing the sovereignty over your data while only being able to buy rights of use creates an unholy alliance, at least in our opinion. This will, after all, lead to a total dependency on the system provider in every respect.

In-house operation, whether on your hardware or in your cloud, would be the counter concept to the above. Here, the possibility to migrate data within the scope of a service contract is incomparable and hard to beat.

Until now, we have always talked about a “migration project,” after all. As the term already implies, a project requires effort and timeframe.

Source Code  – future-proof security

Besides the rather obscure licensing models of many providers and the patent situation, there is another important reason why Open Source has become a worldwide success story in recent years: The source code becomes available with the installation. This is not about transparency, but about two aspects made possible by this fact:

1) Independence

Since the source code is made available with the installation, customers are independent of the provider. As long as the respective software is not a niche solution but finds a broad acceptance (as is the case with Odoo), there are other experts able to provide support and customized solutions – the 1,000 certified Odoo partners worldwide.

2) Future-proof security

Since the source is not only available for the adaptations but for the complete system, the community of platform users as a whole becomes independent of the provider. If there are developments not acceptable to the community or if the provider has financial difficulties, the project will continue under a different name as a so-called Fork, as past examples have shown.

Modular design

Many classic systems still have monolithic cores. This is hardly surprising, since ERP solutions are based on a complex data model, and functions have to be coordinated. As a consequence, these systems cannot simply be broken down into individual parts. We have already discussed this issue in two of our previous blog articles:

What makes IT tick

The openfellas approach to implementation

Odoo, however, has been designed as a modular system from the start. It thus allows the introduction of a jointly discussed foundation. As soon as the system is being used successfully, it can be rolled out further.

As another advantage, adaptations can also be encapsulated as modules, thus simplifying migration. But this, in turn, also increases the system’s complexity with each individual step.

Range of modules vs. functional depth

It is often challenging to draw and define a clear line within a company between certain areas, so that one area is dependent on certain information and the other area(s) only on a defined amount of data, without the need for exchanges between them. This is not possible simply because at the end of the day, everything will end up in accounting anyway, as either revenues or costs, and there is no need to draw lines.

The advantage of a fully integrated system is that the data cannot only be passed on from module to module but that it is not possible to create double entries. For this to happen, though, a system first has to create a basis for complete integration.

If you look at the multitude of available modules, it should be clear – if not Odoo, what else would you choose?

This decision comes at a price. You cannot have all the many, many little functions that have been created in some of the classic systems, because

  1. a) in a modular system, this is virtually impossible due to the set of installed extensions,
  2. b) it would contradict the minimalistic approach.

The trick, one way or another, is not only to introduce a system so successfully that every designated employee is a user working with it, but also to design processes in such a way that they run more efficiently and without error. Pure reason alone will tell you that this can only be achieved with a „less is more“ approach, because functions and automation can much more easily be added than removed.

Localization and accounting

Odoo’s Accounting is GoDB compliant and fully applicable in Germany, despite the still pending certification. Certification, by the way, does not protect against misuse and does not release management from their responsibility.

In the Odoo ERP System, localizations are available for each European country that not only install the country-specific taxes and charts of accounts but also adapts and extends the general financial reports depending on the minimum legal requirements. Additional functions, such as the transmission of invoices via EDI in Italy, are also installed automatically.

Odoo supports multi-currency operations. The core functions, however, are related to Accounting. The necessary functions for complete support include:

  1. Exchange rates between currencies can be maintained manually but can also be automatically reconciled with the ECB on a daily, monthly, or annual basis.
  2. For each client, the main currency may be defined.
  3. A different currency can be specified in the posting record so that the amounts then posted are interpreted in this currency. With each update, the system calculates and stores the amounts in the client’s standard currency in invisible fields, using the exchange rate valid at that time.
  4. All reports and statistics are based on the standard currency.

Modules by openfellas

Over the past 10 years, openfellas have developed a variety of modules that may be used in projects as a basis for implementing requirements or increasing process efficiency. They include automatizations or background calculations that have proven themselves over the years.

Here are some examples:

  • EDI connections to supplier
  • EDI connections to logistic providers
  • Extensions for mapping complex purchasing conditions
  • Exchange Connector
  • Datev Connector
  • Shopware Connector

Odoo Gold Partner

In the last 3 years, Odoo has implemented stricter prerequisites for an Odoo Gold Partnership, which have created some alterations.

Odoo Gold Partners have to register 150 new users every year. On the other hand, a retention rate of 80% has to be achieved; in other words, 80% of the existing customers or Enterprise users have to be renewed every year.

In addition, 3 of a partner’s permanent employees have to be certified for the current Odoo version to maintain the Gold Partner category. During the certification process, each candidate has to answer 80 random questions referring to all existing modules within the current standard. 70% of the questions have to be answered correctly.

This demonstrates that Odoo attaches great value to a qualified consultation within the partnership landscape, to minimize the risk of faulty implementations and to maintain the image of a stable system. SAP and Microsoft have similar requirements.

Another reason to compare like with like. After all, the choice of a partner may be even more important than the choice of a system.

Was this article helpfull information to you? 
Would you mind to leave us a review of your experiences with openfellas?

​​​​​review openfellas

Talk to our experts.

We will find the solution best suited to you and your products!


3 Typische Fehler bei Odoo Projekten