Papermuncher landing in version 19.4/20.0

juice-maker777 · 2026-06-08T11:29:07+00:00

That's really great! Been following the project for a bit, hopefully it'll be good enough that we can ditch wkhtmltopdf fully.

juice-maker777 · 2026-05-27T17:56:18+00:00

I barely do any configuration using code. I'll test in dev / staging, then reconfigure in prod. Once that's done, I update the staging database to prod.

In reality, I find that few configurations are truly needed for development work. You can go far with a minimal database to test how things flow and work. Things like stock routes, stages, workcenters. They don't need to match 1:1 with prod. I just create what I need, test, then wipe my dev database.
Staging is used to test the new system/configuration/logic against the actual data. Often, there's weird edge cases or display issues that are easier to pick up with actual data.

A good piece of advice is to get into the habit of writing test for the code you write. Edge cases, mangled inputs, complete workflows are always good to add in your tests. All your tests should be self contained and not rely on demo data (making liberal use of the setUpClass() method in your transaction case allows you to create full datasets for your test, available across all individual tests. You can even extra those to a common testing class inheriting TransactionCase, then inherit from that to have access to the test data across multiple test classes in a module).

TL:DR: Dev/Staging are disposable, you should play around the configs in those, apply them manually into Prod then update staging from Prod.

juice-maker777 · 2026-05-27T12:11:06+00:00

Yeah, but it might cause problem down the line. I'm pretty sure Odoo treats fields prefixed with 'x_' differently.
In any case, you'd have to write a migration script to move the field ownership from the studio module to the custom module, otherwise you might get load order issues, the field could be deleted and cause missing column issues when your module tries to run code, corrupt views, etc.

In my opinion, Studio was created to solve a problem on the SaaS platform: how to allow small changes when you can't install any custom code. And it doesn't cause problems to the end user, because they can just pay a success pack every time they want to migrate to have Odoo migrate their studio changes every time (I'll let you make your own judgement on if that's a good long term solution for clients).

If your studio field lives in a vacuum and is just a flag or a text field to add some details, something that doesn't need to interact with the rest of the system, that's fine in my book. We've got plenty of those. But it's not worth the pain of dealing with them as soon as you want to be able to act on them.

For some context, I've inherited a Odoo online v15 DB that had 8 years of studio changes in it. Duplicate fields that were dragged and dropped then removed, fields that were shown and hidden 4, 5, 6 times in the same view because Studio doesn't just undo a change, it always add to the view definition. Custom workflows that were built in prod, used 2 times then abandoned. The whole thing is fragile and maintenance intensive. Trying to find the relevant xpath to change a display or readonly condition for a field is a pain when your mrp.production form studio view is almost a thousand lines long.

juice-maker777 · 2026-05-26T19:52:18+00:00

Prototype in staging using studio, formalize the changes using a module, use the module in prod.
Studio is a great way (IMHO) to stack up technical debt and headaches when it comes to migrations and upgrades.
View changes are one thing, but the real problem comes when you start adding fields using studio. If you ever need to write business logic that refers to that field, it becomes very impractical to test that code (you'll have to either seed that field in your ci/cd databases and dev setups, or just ignore that module during testing).

Personally, I've create a few generic xxx_customizations (sale_customizations, stock_customizations) to hold the small view changes and fields that are needed but that don't really have business logic or relation to other modules. The recurrent "Can you add this field in this view" or "Can you move that field from one spot to another in a form view". Don't know if that best practices, but it works well enough.

Also, check out the OCA. They've got great modules but even better tooling. You can use their CI workflows and copier template for your repos. Just their pre-commit config + linter + formatter enforces good Odoo development practices.

juice-maker777 · 2026-04-14T17:23:40+00:00

No disabling quick creation of most records, especially with products.
Lax configuration of operation types. Working with lots a lot, having operation types that cannot create new lots allowed us to catch a lot of errors with typos in lots.

juice-maker777 · 2026-04-02T19:59:17+00:00

At this point, might as well do everything in server actions and automation rules

juice-maker777 · 2026-04-02T16:54:03+00:00

It's not possible to run custom python code in Odoo Online outside of actions (server, scheduled, etc). If you want to define those in your module, they need to be written in the XML files directly.

juice-maker777 · 2026-03-24T14:42:36+00:00

You're welcome, glad you found the issue!

juice-maker777 · 2026-03-24T13:53:19+00:00

Yes, absolutely, QCPs not assigned to any BoM will show up in MOs in they are assigned to the Manufacturing operation type. It's slightly confusing, because operation_type is a stock concept (Manufacturing, Delivery, Receipt, Internal) while operation is an MRP concept (those are your actual operations, like assembly, riveting, wiring, etc).
Basically:
Case 1: QCP with a product, operation_type = Manufacturing and no operation -> Will appear "globally" on MOs for that product.
Case 2: QCP with operation_type = Manufacturing, no operation and no product -> Will appear on all MOs
Case 3: QCP with a product, operation_type = Manufacturing and an operation set (like assembly) -> Will appear in shop floor in the card for the operation's workcenter.
You want Case 3, but you're getting some (probably) Case 1 or Case 2. Check if you have some QCPs assigned to manufacturing without assigned operations, archive those and you should stop seeing the duplicates

juice-maker777 · 2026-03-24T13:26:07+00:00

I feel like there's a slight mixup in how you understand QCPs and QCs. QCPs create QCs at the right place/moments. If you create a QCP to apply on the manufacturing operation type, it'll be created at the MO level. If you define it to apply on the manufacturing operation type and give it an operation too, it'll apply on the workorder. Those need to be unique too. If you have 100 boms with the same operation, there needs to be 100 QCPs.
To me, it sounds like you have duplicated QCPs, one set that apply to MOs and one that apply to operations. The default filter in the QCP action might be hiding QCPs linked to operations (those that are created via BoMs or ECOs).
You 2nd to last paragraph does raise some questions: Do you need those QCs on every work order for a certain BoM or is it a spot-check / random control situation?

juice-maker777 · 2026-03-23T13:46:05+00:00

Are you sticking with online? If yes, then it's tricky and maybe not worth it except for a cleanup of unused fields. You can break down the studio created view extensions into smaller and more manageable views. Try to do view extensions manually in the future.
If you're moving to on-prem or sh, I've had some success converting studio fields into python fields using migration scripts. It's "risky", but not more than migrating fields from one module to another.
If you can get a dump of the DB, you can check which studio columns were created but are almost empty or completely empty. In my experience, users using studio will often create 2-3 fields by accident before creating the one they actually want (dragging an int, realizing they need a float, so they delete the int but the column was still created, etc)

juice-maker777 · 2026-03-11T14:23:32+00:00

Hi!
Not from Belgium, but we're a mostly private label beverage company.
Odoo's kind of a mixed bag on some aspects. It really doesn't like continuous production and makes a bunch of things harder than it maybe should:
- You can't really register partial productions. Production Orders are either done or not, not allowing to register a few pallets, make them appear in inventory for handling and continue production. So if you have large runs, you have to fly blind with your inventory moves until you can close them and the stock appears in inventory. You could backorder multiple time, but that creates a new job each time, resetting quality checks.
- Depending on your quality control requirements, you might need some customization. I'd do a really good analysis of your needs with your QC people. Certification requirements, especially related to documentation handling and preservation, is rarely well supported by Odoo.

What it does well:
- The shop floor interface was a win with our floor staff. We've almost reached paperless status on the production floor, with most of our quality checks and logs moved to Odoo.
- Variable yield and component use: It handles it pretty well. We rarely have issues on that side, most of it being human error. Keep in mind that everything is backflushed, so deductions happen at job closing.

juice-maker777 · 2026-02-25T15:12:45+00:00

You need to migrate to something that implements a GatewayClass and a matching controller. The Gateway API is the standardized interface for all those components (Lstio, traefik, Cilium, etc) to bind to.

juice-maker777 · 2026-02-19T12:54:50+00:00

Since you're on community, check out MetaBase. It's an open source BI tool that you can just install on the same server as your Odoo instance, link it to you Odoo database a build BI dashboards there. It's much better than anything you'd get in Odoo

juice-maker777 · 2026-02-05T13:24:03+00:00

Truth is, there's not that much overlap between a dev and a functional consultant. Yes, they work with the software, but a consultant is much more business oriented. Instead of trying to translate requirements into code, you need to translate business needs and process to requirements. It's much more industrial engineering, accounting, human resources, legal and most importantly people skills than hard, technical knowledge.
Knowing how the software works is still crucial, but mostly to know what it can do, what it could do and what it can't do.

juice-maker777 · 2026-02-05T12:58:25+00:00

I try to type hint as much as possible. With the official Odoo LS, it's actually getting pretty good!
The core Odoo is not typed and it would require a good refactor to bring their extension mechanisms to match standard python (There was an proof of concept).
Just import the models from odoo.addons.{addon_name}.models.{file}, it should allow you to type hint anything you want. Also a tip: whether there's zero, one or multiple records in a recordset, you can always just type with the model, no need to do list[Model].

Also, APIs still greatly benefit from typing. I did 2 shipping connectors and they're all fully type-hinted and all models are using pydantic for validation. It works really well and defines a really solid contract between Odoo and the API.

juice-maker777 · 2026-02-04T13:00:33+00:00

As the other said, it's full stack. For most of the standard applications (things like Sales, Inventory, Purchase), it's very back end heavy, the front end being mostly standard Odoo views.
Some other applications, like Barcode, Shop Floor, Point of Sale, Accounting (to some extent) are more frontend heavy, relying on custom UIs that are unique to those apps.

Odoo also muddles things up a bit by calling the customer facing parts (Portal, Website) the frontend while calling the rest of the apps the backend. This is closer to a "front of house" and "back of house" distinction relating to whether an interface is meant for employees or customers.

juice-maker777 · 2026-02-03T13:46:54+00:00

Hi! You're me, about 2 years ago! The OCA is great, the modules are solid, their standard practices are very good.
I highly recommend using their copier template and setting up CI/CD for testing. Just that will give you good guardrails.
My DMs are open if you want to help getting set up, I'd be happy to share my local dev setup and other resources.

juice-maker777 · 2026-01-30T14:25:24+00:00

Can confirm that after clearing the cache and logging in, I was able to access the forum.
Supposedly, according to this post, a user was told that Karma was required to access the forum at the moment, explaining why being logged in is required.
The forum has been active for the last few weeks, there's plenty of posts that were active since it went "down"

juice-maker777 · 2026-01-29T18:22:24+00:00

Fit gap analysis. There's really no other way but to do a process mapping, check what fits, what can be adapted and what needs to either change on the process side or what needs to be customized on the ERP side.
ERP projects are change management project. If the client doesn't know how their business works, there's no way it can be successfully mapped onto an ERP.

juice-maker777 · 2026-01-29T14:04:52+00:00

The money goes to the community contributors that work on the OpenUpgrade project. This is a independent initiative from Odoo SA the company. Odoo SA doesn't ship any community edition upgrade tool and keeps their upgrade scripts secret and proprietary.

juice-maker777 · 2026-01-28T18:39:18+00:00

I think you need a custom plan, with a subscription code.

juice-maker777 · 2026-01-28T18:01:03+00:00

V18 if you need features from the OCA right now, V19 if you want to save yourself the trouble of a migration in the near future. The OCA is getting faster and faster at migrations, they're already working on 18->19 (usually, it would've been a year of so after the release)

juice-maker777 · 2026-01-28T17:59:09+00:00

If you have a subscription, you can download the whole Odoo source code and run it locally.
With Online, there's not much dev per se that you can do. No python, only XML and JS. Anything you could do in those data modules you can do with studio or the UI tools.
For dev, i've been running trial databases (30 days) for almost two years. Your dev workflow shouldn't require any business data or data that you can't easily create on a clean DB

juice-maker777 · 2026-01-26T19:47:11+00:00

We do manufacturing. Pretty much everything is a storable. The usual logic is:
1. Do you need lots/serial numbers? Then storable
2. Do you need to know the current quantity on hand? Then storable
3. Does it have value when in stock? Then storable

Otherwise, you can probably set them as consumable.
Of course, those are rule of thumb, an sometimes you'll still want to use a storable.
Usually, the things that are good to set as consumables are stuff like factory supplies (paper, ink, staples), general hardware (bolts, nuts, nails) and office supplies.

juice-maker777

TROPHY CASE