Frequently asked questions
Direct answers about Moduvio's product model, operational boundaries and current availability, with links to the authoritative documentation.
These answers describe the current verified product. Where a target workflow is not yet implemented, the answer says so explicitly rather than presenting planned behavior as available.
What is Moduvio's primary hook?
A governed ERP + PLM backbone for regulated manufacturing, joining released product truth to controlled operational truth.
Moduvio's primary hook is one attributable product-realisation thread from released design to accepted product. It combines PLM-grade requirements, configuration, Engineering BOM and change control with ERP-grade supplier, inventory, manufacturing and Quality operations.
The value is not a loose collection of modules. Each handoff pins the exact identity, revision, site, classification, authority and evidence that the next domain is allowed to use, so Engineering can prove what was released, Operations what was planned and executed, and Quality what was accepted.
Who is the primary buyer and internal champion?
The economic buyer is normally the leader accountable for manufacturing performance and regulated product delivery; the strongest internal champion is usually Quality/Compliance or Operations transformation.
The primary buyer is normally a COO, VP/Head of Manufacturing, Operations Director or business leader who owns reliable product delivery across Engineering, Supply, Production and Quality. In smaller regulated manufacturers this may be the Managing Director or plant leader.
The internal champion is commonly a Head of Quality/Compliance, Quality Management Representative, Manufacturing leader or transformation owner who feels the daily cost of disconnected revisions, spreadsheets, evidence stores and handoffs. Engineering, Supply and IT are essential stakeholders, but Moduvio should be evaluated as a cross-functional operating backbone rather than a departmental point tool.
What is the difference between an Assembly BOM, EBOM and Manufacturing BOM?
Assembly BOM and EBOM define what the approved product is; the MBOM translates that exact released design into how it will be manufactured.
An Assembly BOM is the independently released direct-component definition for one assembly item. Product Engineering deliberately selects exact released Assembly BOM revisions to form a configuration baseline and recursive Engineering BOM (EBOM), which is the complete as-designed hierarchy carried in the released PLM handoff.
Manufacturing then creates an immutable, versioned Manufacturing BOM (MBOM) from that exact released Engineering handoff. The MBOM adds operation allocation, routing, supply/issue strategy and controlled quantity treatment without rewriting the Engineering source. Releasing any BOM definition does not create, reserve, receive, issue or move stock.
Where are workflows defined, and why are only generic human workflows visible in Workflow Governance?
Operational workflows are enforced by owning domain APIs and invariants; Workflow Governance administers bounded human definitions, not arbitrary copies of operational logic.
Moduvio's operational workflows are real domain processes implemented by the modules that own their records, API transitions, permissions, maker-checker rules, audit/outbox facts and safety invariants. The Operational flows catalogue explains those cross-module journeys, while the live record and Action Centre expose the exact next permitted action in the owning screen.
Workflow Governance deliberately shows protected built-in human definitions and tenant-created generic human workflows as definitions that can be versioned or duplicated safely. It does not turn receipt, inspection, custody, stock, Manufacturing or Quality domain logic into editable templates, because duplicating those code-owned flows would bypass their authority and transaction invariants. Generic workflows cannot run scripts, SQL, arbitrary endpoints, inventory postings or code-owned callbacks.
Why is physical stock separate from catalogue definitions, and how is permission-scoped stock shown in Catalogue Governance and Item Master?
An item record defines identity and policy; only authorised physical transactions create quantity, while stock context is a scoped read-only projection.
An item record contains no stock. Item creation, editing, review and approval define the governed identity, units, tracking and classification but never create quantity. Physical quantity begins only with an authorised receipt or another explicit inventory transaction, and every movement remains in current stock, stock ledger and custody records.
Users with stock:read see read-only Physical on hand and Available to issue summaries in Item Master and Catalogue Governance, plus site/location/state/ownership/batch/serial/container detail within their assigned-site and clearance scope. Physical on hand includes held or restricted material where represented; quarantine, reserved, allocated, blocked/MRB, repair and subcontractor states are not labelled available. Users without stock:read see Stock visibility not permitted or no stock surface—never a misleading zero.
How should multiple revisions of an already approved item work?
Approved revisions are immutable, simultaneously addressable records; a new human-coded revision is cloned, reviewed and approved independently without rewriting the prior revision.
Current behavior: in Catalogue Governance choose Create next revision draft and enter the required business revision code. Moduvio clones approved revision A into a separately identified draft B, automatically assigns its internal UUID and sequence, and retains A unchanged and usable while B is drafted, submitted, rejected or reconsidered. Revision codes are unique within an item and an approved revision cannot be edited in place.
A different authorised user independently approves B. Only then is A marked SUPERSEDED for new selection; both remain simultaneously addressable, with their definition snapshots, checksums, authors, approvers, timestamps, effectivity and audit history intact. Existing BOMs, authorities and physical transactions that pin A continue to resolve A rather than silently following the item’s latest revision.
New downstream definitions and transactions pin the exact approved revision through BOM components, receipt authority, ASN/GRN, inspection, physical instances, batch/serial/container stock, ledger movements, reservations/issues, work orders and as-built genealogy. Stock and traceability views separate quantities by revision. Pre-existing rows whose historical revision cannot be proved remain nullable and are labelled Legacy unpinned; Moduvio does not fabricate provenance for them.
What can I edit today in Item Master?
Item Master edits governed identity and policy fields; Catalogue Governance separately owns revision/specification values and maker-checker review, while stock and history remain outside both edit surfaces.
For a new or current draft revision, Item Master exposes part number, name, description, commodity category, nature, usage, tracking, base UOM, quantity precision, classification, NSN, shelf life, calibration/default frequency, lifecycle selector, UOM/pack conversions and manufacturer, supplier, legacy and customer references. Catalogue Governance separately exposes the revision code and typed category specification values, the immutable revision register, review preparation/submission and the independent decision.
Saving a draft keeps catalogue review in DRAFT. An approved revision is not edited in place: use Create next revision draft in Catalogue Governance, then edit and approve that separate revision. Tracking policy, base UOM and quantity precision cannot change after stock-ledger history exists. Item ID, stock quantities, stock states, locations, batch/serial/container identities, historical transactions, approved BOM revisions and audit evidence are never edited through Item Master. Duplicate part number or NSN and self-approval are rejected.
Should an item revision be automatic or manual, and is it part of traceability?
The business revision code is human-confirmed; Moduvio automatically assigns immutable internal identity and carries the exact approved revision through physical and product traceability.
The customer-visible business revision code remains a required human-confirmed code because manufacturers use A/B/C, 01/02, drawing-controlled and external schemes. Moduvio never silently increments it, and every code must be unique within the item. The server automatically assigns the immutable internal sequence and UUID, timestamps, authors and approvers, SHA-256 definition checksum and lifecycle history.
The exact identity can therefore be read as TRAIN-A-BOLT-M8 · Rev A · Batch TRAIN-BATCH-001. BOM component selection, receipt authority, ASN/GRN, incoming inspection, physical instance, batch/serial/container balance, current stock, stock ledger, reservation/issue, assembly or Manufacturing work order and accepted as-built genealogy carry the exact item_revision_id. Stock and traceability views break the same item down by revision rather than merging A and B.
Backward compatibility is explicit: historical rows that can be attributed deterministically are pinned during migration; physical or ledger history whose revision cannot be proved stays valid with a nullable revision and is shown as Legacy unpinned. It is never silently assigned to the latest revision, and creating, revising or approving an item still creates zero stock quantity.
How does Moduvio show job and contract cost without becoming an accounting system?
Programme reads independently approved Manufacturing cost evidence and adds customer/contract context only through a unique deterministic demand match; it never allocates or posts cost.
The Job & contract cost insight surface reads only the current APPROVED Flow 30 build-rollup version. It shows the exact Assembly work order/job, build, released manufacturing-plan version, product baseline, currency, planned-versus-actual minutes/cost, variance, operation rows and immutable execution/dispatch/rate-version fingerprints.
Customer and contract context is presented as unique only when exactly one visible governed demand line matches assigned site, project reference and the exact released product-baseline UUID. Multiple matching demands remain AMBIGUOUS and cost is shown once without splitting or allocation; no match remains honestly unassigned.
This is operational evidence, not payroll, budget, GL, AP/AR, tax, payment or inventory valuation. Reading it cannot change Manufacturing sources, demand, item identity, custody, current stock or stock ledger. Tenant, programme_cost:read, site scope and clearance are enforced, and classified reads are audited.
Does Moduvio support Indian languages?
Indian English, Hindi and Kannada are reviewed, with eight additional Indian languages available as company-governed previews.
Yes. Indian English, Hindi and Kannada are reviewed for the public first fold, secure-login and MFA journey, workspace and primary-navigation shell, connectivity state, Action Centre shell and Language & Region module. Tamil, Telugu, Marathi, Bengali, Gujarati, Malayalam, Punjabi and Odia are available as opt-in previews for the Language & Region module and locale-aware formats, with an explicit Indian English fallback elsewhere until native review is accepted.
Company administrators govern the enabled set and default. Indian English always remains the assured fallback, new users inherit the company default, and disabling a language atomically moves affected users to that default with one policy audit fact. A coverage panel states exactly which surfaces have completed localization acceptance.
This is not described as full-product translation. Deeper module forms, API validation, record content, notifications, generated reports/PDFs and documentation remain English until their terminology, layout, accessibility and evidence behavior are reviewed. Product codes, identifiers, workflow states, statutory facts, authority decisions, audit facts and source evidence are never silently translated or rewritten.
Preview does not mean ungoverned. Each preview is off by default for existing companies, visibly labelled, constrained by the same company policy and user audit controls, and promoted to reviewed only after named native terminology, responsive layout, accessibility and fallback acceptance.
How do statutory controls feed supplier-invoice tax without guessing legal facts?
Finance governs immutable statutory configuration and now consumes one exact active version for deterministic supplier-invoice tax, while broader numbering, returns and filing authority remains absent.
The Statutory tax & localisation surface creates one site-bound profile per legal entity, country and jurisdiction. Each immutable version retains registration and authority facts, base currency, locale, timezone, fiscal start, tax point, tax-inclusion and rounding policy, effective tax-rule components, statutory document-series constraints, CLEAN evidence and a SHA-256 checksum.
A Tax Accountant authors and submits the version; a different Finance Controller approves, rejects or later retires it. Site scope, clearance and India GST validation guardrails apply, and historical rejected, approved, superseded and retired versions remain attributable.
At supplier-invoice capture, the AP user must select the exact active version, one eligible NORMAL purchase/goods rule per receipt-backed line, required place of supply and an evidence-backed rationale. The server—not the caller—calculates inclusive/exclusive basis, approved rounding, named components and recoverable/nonrecoverable tax, then freezes fingerprints that every later workflow step revalidates.
Posting carries the profile checksum and determination fingerprint into journal dimensions and the retained source snapshot; recoverable and nonrecoverable tax use separate controls without changing stock. Customer tax, reverse charge, withholding, statutory numbering/issuance, return summaries, close exceptions and filing adapters remain separate future authorities.