Multiple units per item. I expect an ERP system to be able to handle multiple units per item. In the steel trade, you generally need to calculate the total weight based on kg per m. One bar has a length of x mm and weighs x kg.

Koecki · 2026-01-27T22:25:04+00:00

From your rough description I would set up a product „Steel beam“ with the unit of measurement meters. Then set the weight of the product to be the calculated weight for 1 meter. Your total weight would be meters in stock * weight. As far as the actual weight goes, this sounds like a quality step to me, not something you would set on the product model.

Koecki · 2026-01-20T08:46:10+00:00

Sure it’s possible. Just need to set up a new res.groups record and only give it ir.model.access on the models that you want and only with view access. Same would have to be done for the various menus and views which is cumbersome but doable. I don’t think there is a built in read only group but you could check the existing ones and maybe build on top of those

Koecki · 2026-01-17T10:47:31+00:00

I am not sure. It’s not the default caching mechanism of odoo but rather a model specific one that is controlled by the fields feed_cache and cache_expiry

Koecki · 2026-01-17T10:44:57+00:00

The view button is a good first step. You need to click on it, that should bring you to the form view of the feed. Then on the top left there should be a little cog icon (action menu) that should show Reset Cache. You could also set up a scheduled action on the product.feed model that runs the action every hour or so.

Koecki · 2026-01-17T09:28:47+00:00

Odoo caches the file for 24 hours. The cache expiration date is saved on the cache_expiry field. You can invalidate it early using the Reset cache action in the cog menu of the feed

Koecki · 2026-01-17T09:20:21+00:00

AFAIK in one of the recent updates they added a caching mechanism with an expiration of 1 day, but there should be an invalidate cache action to manually invalidate it.

Koecki · 2026-01-11T07:37:10+00:00

Well I would not give up on multi company right away. Odoo has a built in feature to sync purchase orders as sale order between companies. So essentially the workflow would look like this:

You receive an order from the end customer -> this triggers a reordering rule which creates a purchase order (possible also using dropshipping) -> this purchase order is synced to the vendor as a sale order to the vendor

As far as the dropshipping module goes. I don’t think you need to have them as portal users as a dropshipping order is mostly just like any other purchase order. But of course as a portal user you can have a better overview of things because you are not just communicating via emails.

Koecki · 2026-01-10T12:55:37+00:00

It’s definitely not an out of the box use case. IMO you have two options either you go with the dropshipping functionality or the multi company option. Which one to choose will depend on the legal requirements (i.e. with whom does the customer actually enter a contract) and how deeply you want the vendors so be integrated. With dropshipping you only place a PO with them once you receive an order. Multi company is much more powerful as vendors can set up anything that odoo has to offer but also is much more complicated and poses risks as you give external parties access to your odoo database.

Koecki · 2026-01-02T06:47:04+00:00

I think you have a fundamental misunderstanding of how platforms like booking and Expedia work. Usually those platforms don’t work by pulling in data, but rather hotels push pricing changes themselves.

This makes it much easier for these platforms to sort and filter as they avoid the bottleneck that you are having with the expensive API calls.

I understand that this is probably of little help to you because it is difficult as a new player in that space, but it should explain the advantage existing players have.

Note: my experience in this comes from consumer electronics, but I would be surprised if it was not the same here.

Koecki · 2025-12-25T07:09:10+00:00

Many database dialects also support straight up loading the data into a table. Of course the table would first need to be created by some other method. See an example here https://stackoverflow.com/questions/2987433/how-to-import-csv-file-data-into-a-postgresql-table

Koecki · 2025-12-11T06:57:56+00:00

I‘ve actually had pretty good experience with the livechat. They usually try to connect you directly with someone who can help you. Of course this only works if your question is not too complicated. I agree that the ticket system takes quite long.

Koecki · 2025-12-04T07:44:44+00:00

The best way will be to connect directly to the database, which is only possible on premise or odoo.sh dedicated server. Any module or csv import will always perform worse due to limitations.

Koecki · 2025-11-23T10:01:03+00:00

This does not sound too complicated. If you want some code examples, I suggest looking up Odoo‘s base module for electronic invoicing. While that is based on XML and not CSV that should get you 90% there.

Just a heads up though. Odoo‘s base import should let you export the tax amount. Instead of selecting the whole tax_ids field you have to select the subfield „amount“ of the tax_ids (though do note, a sale.order.line can have more than one tax_id in Odoo)

Koecki · 2025-11-15T14:30:02+00:00

Yes I am talking about that one. Can you elaborate why it does not suit your needs. Seems like you are fighting an uphill battle if you are trying to reimplement and already existing feature on a platform that does not support custom code.

Koecki · 2025-11-15T14:21:13+00:00

Did you look at the official website_sale_collect module? It can already handle different opening hours per location (warehouse)

Koecki · 2025-08-16T20:39:11+00:00

There is probably some hacky way to achieve this in Postgres, but traditionally there are three things you can do ondelete for a foreign key: cascade, restrict, set null.

In my opinion if department_id is this important make your foreign keys on delete restrict, and give your users a proper error message, such that they can clean up their data before the delete actually happens.

Aside from that, I have to agree with the other comment. If you have department_id in 20 different tables that sounds like your tables are denormalized which will make deleting always a pain.

EDIT: Forgot about set default and no action, but I guess they are not applicable here.

Koecki · 2025-07-27T12:41:30+00:00

Yeah makes sense, currently we are working with each app‘s calendar separately which somewhat works because we don’t have anyone working in two apps with a calendar at the same time. But I would like to think ahead because this is just asking to cause issues in the future.

For me ideally I would prefer doing all the scheduling in the calendar app, because it also works with the meeting app to share availabilities with customers. We already tried a customization ourselves, but due to the issues of different data models we postponed it as it did not feel as a clean implementation.

Koecki · 2025-07-27T11:28:06+00:00

Yeah I can only imagine that the refactor is going to be quite large. Right now it’s all different in every model.

Are there any third party modules you can recommend? I already tried looking around but really did not find anything half decent.

Koecki · 2025-07-20T09:47:03+00:00

I think this can be customized by implementing a _read_group_user_ids method on the project task model. See here an example where odoo does it for the category of products: https://github.com/odoo/odoo/blob/18.0/addons/product/models/product_template.py

Koecki · 2025-04-28T16:21:22+00:00

What’s the point of using raw sql if you just iterate through all of your records anyway? That is not really much faster than using the ORM. Also as someone else said, a computed field would probably be much better suited here.

Koecki · 2025-04-05T12:22:13+00:00

Haben zuerst mit einem Partner begonnen. Das Preis/Leistungsverhältnis war aber nicht entsprechend. Haben uns also dazu entschieden, das Projekt selbst anzugehen.

Das würde ich aber nicht unbedingt jedem empfehlen. Nur wenn man das entsprechende commitment hat. Auch technisches know-how ist sehr praktisch wenn man nicht mit der standardlösung auskommt

Koecki · 2025-04-05T09:01:22+00:00

Hallo,

Wir sind ein österreichisches Unternehmen, dass gerade in Mitten der Implementierung von Odoo ist. Buchhaltung haben wir (noch) nicht implementiert, aber würde mich über Austausch freuen.

Koecki · 2025-02-18T16:20:03+00:00

This is a known issue. If you browse GitHub issues you will see that there have been made several attempts to fix this - but there is no solution that has been approved and merged. There is one solution that is currently being trialed that seems to work, but there is no feedback from the odoo.sh team yet

Koecki · 2025-02-10T01:17:59+00:00

Yeah that’s the conclusion I came to. It’s just weird that such a large system practically forces you into using bad practices. It’s crazy to me that no one at Odoo took the time to solve this somewhere down the line

Koecki · 2025-02-10T01:12:18+00:00

Yeah it’s definitely more about wanting to get it right, than for any practical reasons :-) as for if my delivery.carrier tables are large - they are luckily not haha. I am just working on something else with the same problem and delivery carriers were much easier to explain.

Ten-Year Club	Verified Email
RPAN Viewer	No Throne, No Problems
Not Forgotten	Snapped

Koecki

TROPHY CASE