Open source ERP for manufacturing

Auditors expect a dated record of every configuration change, custom module release and parameter update, with who requested it, who approved it, what was tested and when it reached production. In Odoo, custom modules live in version-controlled code, so the Git history, merge requests and deployment logs become the primary evidence. In ERPNext, the equivalent sources are the custom app repository, the Version doctype that tracks document changes, and the deployment pipeline that runs bench commands. Configuration changes such as workflows, tax rules, bills of materials and work center settings should be exported or logged so a reviewer can compare before and after states. DeployOpen can set up the change workflow and the evidence trail, but approval authority and the final control design stay with the client and its auditors. Ask your assessor which change samples they will pull before you design the process.

Assessors look for a log of user logins, failed logins, role assignments, permission changes and changes to production records, retained for a defined period and protected from edits by the users being monitored. The sources differ by platform: Odoo records chatter and tracking on fields, and the Odoo server and PostgreSQL logs record authentication and database activity. ERPNext keeps a Version history for tracked documents, an activity log, and login history on the site. Central log forwarding to a SIEM or log store is usually needed to make these records tamper-resistant. Directory integration through LDAP for Odoo and ERPNext, where configured, ties account lifecycle to the identity provider. The FTC Safeguards Rule at 16 CFR 314.4 requires logging of authorized user activity for covered financial institutions, and similar logging expectations appear in customer security questionnaires for manufacturers. Confirm the retention period and the log fields with your compliance lead before go-live.

Auditors and customers want proof that backups exist and that a restore has been tested to a usable state, not only that a backup job ran. Evidence includes the backup schedule, backup job logs, encryption settings, storage location, retention policy, and dated restore test records that show a database and file store were restored to a separate environment and checked against known transactions. For Odoo, this covers the PostgreSQL database and the filestore. For ERPNext deployed with frappe_docker, it covers the MariaDB database, the site files and the configuration. Restore tests should include a reconciliation step, such as confirming open production orders and inventory balances match the source. The recovery time and recovery point targets should come from the business owner, and the restore test should be measured against them. DeployOpen can design and run restore testing as part of an engagement, and the results are documented for the client's records.

Customers and regulators typically ask for dated scan reports, penetration test reports covering the ERP web application, APIs and the hosting environment, remediation tracking, and a statement of scope. The FTC Safeguards Rule at 16 CFR 314.4(d)(2) sets an annual penetration test and vulnerability assessments at least every six months for covered institutions that lack effective continuous monitoring, which is a useful benchmark even for manufacturers whose customers apply similar expectations. Evidence should show the target version, the test scope, findings by severity, the fix that closed each finding and the retest result. DeployOpen runs application, API, cloud and infrastructure security testing, and it can deliver reports that feed the client's own assessment file. DeployOpen does not issue audit reports or certifications, so the evidence is only as useful as the independent review the client arranges.

A NIS2 incident reporting workflow needs documented detection, triage, internal escalation and a timed report path, so the organization can meet the early warning, notification and final report windows. Under Directive (EU) 2022/2555, in-scope entities report significant incidents with an early warning within 24 hours, an incident notification within 72 hours and a final report within one month. Manufacturing is listed as a critical sector in Annex II, so manufacturers that fall in scope need a tested playbook. Evidence includes the incident register, timestamps for detection and each notification, the named decision makers, and tabletop exercise records. For an ERP, the workflow should cover alerts from the SIEM on the ERP and OT-adjacent systems, plus a path to the national competent authority. DeployOpen can help build the workflow and exercise it through its cyber range and security training services, but the reporting obligation and the legal assessment belong to the client.

Where a manufacturer produces regulated products, such as medical devices or products handled under FDA oversight, auditors may require electronic records and signatures that meet the controls in 21 CFR Part 11. The core evidence includes unique user accounts, signature manifestations that show the signer's name, date, time and meaning, audit trails that record changes without overwriting prior values, validated system documentation, and controlled access to electronic signature components. In Odoo and ERPNext, approval steps can be modeled with workflows, but the system must be validated for its intended use, and the client must decide whether Part 11 applies to a given record. DeployOpen can prepare the configuration, validation documentation and test evidence, while the regulatory determination and any validation sign-off remain with the client's quality function.

A manufacturing ERP should keep a link between each finished lot or serial number and the materials consumed, the work orders and operators involved, the inspection results and the shipments made. Customers and quality auditors ask for both forward traceability (from raw material to customer) and backward traceability (from a complaint back to the supplier lot). In Odoo Manufacturing and ERPNext Manufacturing, lot and serial tracking is set on items, and work orders record material consumption against those lots. Evidence includes goods receipt records with supplier lot numbers, quality inspection records tied to batches, and a traceability report that the team has tested with a sample recall exercise. Machine and shop floor data, if captured through MES, should carry the same identifiers. Confirm with your quality team which trace depth and retention periods apply to your products before configuring the records.

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors, certification bodies and the client's own compliance function make those determinations. In practice, DeployOpen configures the platform, documents the controls, sets up logging and backup routines, runs security testing and assembles the evidence package that an assessor will request. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. Before starting, ask your auditor which evidence formats they accept and which periods they sample, so the engagement scope matches the assessment.

The biggest cost drivers are the number of plants, the number of MES and machine integrations, the volume of custom work, the amount of historical data to migrate, and how much user training the rollout needs. Each plant adds its own bills of materials, routings, work centers and quality checks to configure and test. Every MES or machine connection adds interface design, testing and ongoing maintenance. Custom modules add build and upgrade effort for every future major version. Ask any partner to price these items separately in a written scope so you can see which choices move the total.

One-time costs usually include fit-gap analysis, configuration, custom module development, integration build, data migration, testing, training and go-live support. Recurring costs depend on the route you choose. Self-hosting ERPNext has no license fee, but you pay for infrastructure, operations and support. Odoo Enterprise requires subscriptions, and Odoo's pricing page lists per-user monthly prices with a yearly discount, with only the Custom plan supporting on-premise hosting and custom modules. Plan for yearly upgrade effort and ongoing support, and ask the partner to split these figures in the quote.

A capable internal team can implement the core modules, especially for a single plant with standard processes, but the work still needs people who understand both ERP configuration and your production process. ERPNext can be installed with Docker Compose or the bench command line tool, and Odoo documents packaged installers and source installation. The harder parts are fit-gap design across plants, MES and machine integration, data conversion and cutover controls. Be realistic about staffing for the project and for the upgrade cycle that follows. Many organizations use a partner for the design and integration work and keep configuration in-house.

Duration depends mainly on how many plants go live, how standard their processes are, how many interfaces must be built, and how much history must be migrated. A pilot plant usually sets the pattern for the rest, and later plants move faster if the global template and master data are stable. Integration testing with machines and MES often sets the critical path. No fixed timeline can be given without a scoped process review, so ask any partner for a phased plan with a named exit criterion for each plant and a written schedule before work starts.

Plant staff must validate bills of materials, routings, work center capacities, inspection plans and shop floor procedures, and they must sign off on test scenarios in their own area. Production planners and quality managers should own the decisions on scheduling rules and nonconformance handling. IT staff must provide infrastructure, identity integration, network access to machines and MES, backup and monitoring, and a change process for production releases. Confirm the time commitment for each role during scoping, because delays often come from unavailable subject matter experts rather than from the software.

Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. DeployOpen does not publish a price list. To get a comparable quote, prepare a list of plants, modules, interfaces, data sources, custom requirements and training audiences, and ask each bidder to state assumptions, exclusions and the support terms after go-live. A good written scope names what is out of scope, such as machine programming or hardware changes, so the final cost is easy to compare.

A self-hosted system needs patching, backups, monitoring, user administration, and a plan for major version upgrades. Odoo standard support covers the first three years after a major release, with security updates and bug fixes, and Odoo 20.0 has standard support planned until September 2029. Frappe warranty coverage requires a listed version and a matching Frappe Cloud support plan. Budget for support retainers or an internal team that covers these tasks, and confirm the upgrade path for any custom modules before you commit to them.