Although we have covered many of the differences between Odoo and other systems in previous blog articles, there are a few essential features where Odoo uses a novel approach. That is sufficient reason to highlight some of these features. In some cases, these elements even replace classic functions, and you may not immediately find specific functions in Odoo simply because they look looks unfamiliar. In other instances, Odoo uses approaches that are fundamentally different. In this blog, I would like to concentrate on Integrated Communication and different View Types of a process, and the option to flexibly combine Groups and Filters.
On the surface, the masks and workflows in Odoo primarily look cool and intuitive. They entail a noticeable reorganization of the daily work processes of its users. Because integrated communication is different, it requires many users to re-think. Basically, however, it is similar to working in Outlook.
The necessary first step here is, of course, to create confidence that the system is actually working. Once you have achieved that, you can start the process of getting used to it.
But let us first discuss the individual features that make Odoo different. Mind you, Odoo did not invent any of them, but rather re-discovered them and integrated them in their unique interpretation of “ERP.”
Integrated communication and version management
The first guiding principle is that communication and version management of a transaction are treated equally. It actually makes sense from the point of view that versions or changes within a process either trigger or are triggered by an exchange of correspondence. This is demonstrated in the so-called “Chatterbox“ below or next to each transaction (depending on screen size and resolution).
Odoo’s option of internal or external integrated communication, regardless of process, type of process, transaction, or master data record, and a readily available follow-up system is implemented more consistently than in any other system I know.
In other words, in addition to the customary points of transfer in any ERP system (order generates reservation, reservation generates delivery, logged times generate billing, invoiced times generate bookings, etc.) Odoo has added a communication system that treats almost everything as some kind of ticket while maintaining communication and versioning in a transparent and chronological order.
So far, we have only known this kind of workflow from CRM or ticket systems, where it is limited to these specific areas of application. Subsequent processes follow the classic route, with Outlook and a connector or some other kind of integration. The consequence, however, is that it is the user who decides which communication is relevant and should be attached, or if the information cannot be displayed chronologically for versioning, since the time of uploading is not or does not have to be synchronous with the change of the transaction.
Since the user is able to distinguish between external and internal exchange of information, it is also possible to include internal queries, releases, and reviews in the chronology. In other words, the versions of a document can be traced completely and reliably, at least in theory, and if the process has been followed scrupulously.
This is a huge opportunity, but often also a huge step to take.
The first thing a user sees when calling up something in his ERP system is a list – the classic concept. If he then clicks on a data record, he is presented with the details in one single view. Odoo, however, takes it a step further and offers various view types, including list, single view, diagram, Gantt, calendar, Kanban, and Pivot.
This means that for each entity (entities can be customers, quotations, orders, deliveries, reorder levels, tasks, invoices, etc.), the system defines at least one list and one single view, and more, if necessary. The user may switch between all available view types. Since grouping options are also included (which will be discussed in the following section), this option can be used for orientation and mass processing, but also for analysis.
By default, Products, for example, are not opened as a list but in a Kanban view. Kanban appears to be intuitive since humans can process images faster than lists. This is easily understandable since every list provides a flood of information that a user needs to recognize before processing it.
Let us look at an example:
As a list, the same example would look like this:
And we all know that other systems sometimes provide not only seven columns as above but sometimes 15 to 20 or even more.
But even for this example, it becomes clear that orientation in a Kanban list is much more convenient. And you have to admit it looks much more attractive!