When deploying Odoo on Odoo.sh for a mid-sized metal fabricator, the implementation workflow relies on a clear division of technical labor. Core backend trade math—such as dynamic bar densities ($\rho = 7850\text{ kg/m}^3$), sheet girth slitting yields, and automatic Bill of Materials (BOM) generation—is securely coded in Python within a custom Git repository (e.g., odoo_fab_core).
However, the Odoo Implementation Partner (OIP)—the client-facing consultant who conducts discovery and manages the front-end setup—uses Odoo Studio directly in the browser to bridge the gap between underlying Python logic and daily factory usability.
Rather than writing custom code for every minor UI request, the OIP uses Studio as a rapid, no-code customization layer to adapt forms, automate business guardrails, build touchscreen shop-floor views, and refine PDF travelers on Odoo.sh.
1. Form & View Customization (Without Git Commits)
Metal fabricators track specific physical attributes that standard out-of-the-box ERP screens omit. Instead of requesting a backend developer to submit a Git pull request for simple field additions, the OIP uses Studio’s drag-and-drop interface during client discovery workshops:
- Adding Custom Parametric Fields: The OIP adds inputs directly onto
sale.order.lineormrp.productionforms—such as Plate Thickness (mm), Bend Hit Counts, Girth (mm), Heat/Mill Certificate Numbers, or Galvanizing Batch References. - Conditional Visibility Rules: The OIP configures dynamic display conditions so that specialized inputs only appear when relevant. For example, Bend Hit Count fields remain hidden unless the selected routing operation includes a press brake step.
- Smart Action Buttons: The OIP embeds custom smart buttons at the top of Sales or Manufacturing Orders that link directly to CAD attachments, DXF files, Mill Test Certificates (MTC), or Quality Inspection logs.
2. No-Code Automated Actions (Business Rules & Guardrails)
While complex mathematical costing is handled by odoo_fab_core Python models, the OIP uses Studio’s Automated Actions (triggers and automated server actions) to enforce operational rules:
- Gross Margin Guardrails: The OIP configures an automated rule on Sales Quotations: if a quoted gross margin drops below a pre-set threshold (e.g., 15%) due to a sudden increase in raw steel spot prices, Odoo automatically flags the quotation and places it on hold for Sales Manager approval.
- Subcontracting & Outsource Alerts: When an order line requiring secondary processing (such as hot-dip galvanizing or powder coating) advances to the “Outsourced” stage, an automated action notifies the purchasing department to generate a vendor purchase order.
- AS/NZS Compliance Hold Points: To enforce structural standards (like AS/NZS 5131 or AS 4100), the OIP sets triggers that place a Manufacturing Order on a quality hold if mandatory welding sign-offs or NDT inspections are missing.
3. Creating Touchscreen Kiosk Views for the Shop Floor
Machine operators running press brakes, plasma cutters, or welding bays require streamlined, touch-friendly interfaces rather than dense financial screens.
Using Studio, the OIP creates simplified Kanban and form views tailored specifically for shop-floor industrial tablets:
- Hiding Financial Data: The OIP strips out cost rates, profit margins, and accounting figures from the operator’s view to prevent distraction and maintain privacy.
- Barcode & Scanner Triggers: The OIP configures action buttons that trigger when an operator scans a barcode on a physical Job Traveler—instantly logging machine start times, recording scrap material, or marking a weld operation as complete.
4. Customizing PDF Job Travelers & Client Quotes
Metal fabricators rely heavily on clear physical documentation. Standard invoices and generic picking slips rarely suffice on a busy factory floor.
The OIP uses Studio’s visual report designer to modify QWeb PDF layouts:
- Shop Floor Job Travelers: The OIP customizes manufacturing travelers to prominently display cut lists, nesting layout references, steel grades, and bar-stock yield details for machine operators.
- Parametric Client Quotes: The OIP formats client-facing quote PDFs so that parametric line breakdowns (showing specific dimensions, finishes, and unit masses next to item prices) display cleanly for commercial buyers.
5. Rapid Prototyping & Custom Table Creation
Before committing to backend Python development for a new feature, the OIP uses Studio to prototype workflows directly with factory management:
- Custom Data Tables: The OIP builds custom tables in the UI—such as a Coil Feed Register, Plate Scrap Log, or Cutting Die Maintenance Tracker—in minutes.
- Validating User Flow: The fabricator’s team tests the prototype in real time. Once the operational workflow is proven, the Odoo Systems Architect (OSA) can review the Studio-generated structure and refactor it into clean, version-controlled Python code inside the Git repository if needed.
Summary: The Studio vs. Custom Code Boundary
Understanding where Studio stops and custom Python begins is key to maintaining a clean Odoo.sh deployment:
| Functional Requirement | Handled via Odoo Studio (OIP Role) | Handled via odoo_fab_core / Python (OSA Role) |
| Parametric Steel Math ($\text{Volume} \times \text{Density} = \text{Mass}$) | ❌ Not for complex math | ✅ Python ORM (@api.depends) |
| Dynamic BOM & Routing Explosion | ❌ Too complex for Studio | ✅ Python (mrp.bom ORM Logic) |
| Adding Custom Form Fields (Heat No., Bend Count) | ✅ Fast Drag-and-Drop Addition | 🟡 Can also be defined in code |
| Approval Rules & Automated Email Alerts | ✅ Automated Actions (No-Code) | 🟡 Optional via Python |
| Simplifying Tablet Views for Machine Operators | ✅ View Access & Field Hiding | 🟡 Can be done via XML views |
Best Practice on Odoo.sh: Managing Customization Debt
On Odoo.sh, any modifications made via Odoo Studio generate an internal module named studio_customization in the database.
To maintain clean DevOps and ensure seamless annual version upgrades, the OIP and Systems Architect work together during staging cycles: the architect regularly exports studio_customization changes, refactors them into clean XML XPath views and Python fields within the main Git repository, and deploys them through Odoo.sh’s native GitHub CI/CD pipeline.
This keeps the production environment upgrade-safe, version-controlled, and performant.