Soviez ERP is engineered for long-lived PostgreSQL deployments where schema integrity, upgrade predictability, and performance localization are non-negotiable. The visual Studio toolkit offers a convenient visual authoring surface for fields and views, but that convenience mutates the live database outside the disciplined module lifecycle enterprises require.
On this platform, Studio is therefore strictly unsupported. Attempts to install or activate it raise an architecture notice with a Know more action that opens this page.
1. The Illusion of Dynamic Freedom (Database Bloat & Corruption)
Studio presents drag-and-drop freedom, yet under the hood it writes durable structural changes into PostgreSQL and the metadata catalog without the packaging guarantees of a declared Python module.
- Raw column injection. New fields materialize as columns on production tables without controlled migration scripts, peer review, or module-owned
ir.model.fieldslifecycle. - Arbitrary XML view overrides. Studio stores arches as database records that silently shadow addon XML, making the effective UI untraceable from the filesystem alone.
- Orphaned attributes. Abandoned experiments leave leftover columns and unused inheritances — database bloat, slower ORM warm-up, and ghost fields that break reports and RPC clients.
- Missing integrity constraints. Visual editors rarely encode the same
required,ondelete, and indexing invariants a developer would declare in code, producing soft corruption at scale.
2. The Inexperienced Operator Risk (Zero Guardrails)
Studio lowers the barrier so far that non-technical operators can alter a live instance with a few clicks. Production ERP cannot absorb that risk.
- Live relational surgery during posting, picking, or POS close leaves half-migrated rows and broken foreign-key assumptions.
- Indexing and lock contention from dynamic field creation surfaces as relational indexing deadlocks and cascading timeouts.
- Unhandled UI layout exceptions — blank screens, recursive view inheritance errors, and client exceptions support cannot reproduce from source control.
- Privilege confusion — Studio rights effectively grant schema administration without DBA oversight.
3. Destruction of Clean Migration Paths
Enterprise upgrades assume application behavior is expressed as code artifacts that can be compiled, diffed, and replayed. Studio breaks that contract.
- Bypass of Python compilation — no module package, no deterministic load order beyond opaque XML IDs in PostgreSQL.
- Isolation from Git — changes never appear in pull requests and cannot be bisected or cherry-picked with confidence.
- Broken upgrade contracts — Studio arches referencing obsolete xpath, fields, or widgets fail unpredictably mid-upgrade.
- Non-portable environments — cloning production copies mutations, but rebuilding from Git cannot. CI and DR drills collapse.
4. Why Custom Code (Custom Modules) Is Vastly Superior
The only acceptable enterprise path on Soviez ERP is a clean, isolated custom module:
from odoo import models, fields
class SaleOrder(models.Model):
_inherit = "sale.order"
svz_priority_flag = fields.Boolean(
string="Priority Account",
help="Marks strategic accounts for localized fulfillment SLAs.",
)Custom modules guarantee:
- Full source-control tracking — Git branches, peer review, and auditable history.
- Testability — isolated automated unit tests with deterministic fixtures.
- Clean schema compliance and portability — fields and views ship with the module for predictable migrations and multi-node rollouts.