Skip to content
Dale Scott edited this page Feb 23, 2026 · 51 revisions

Background

webERP, like most "ERP" software is more concerned with accurate financials than the product development and lifecycle process aka PLM (Product Lifecycle Management). PLM is the process used by a business to manage changes to an item from creation to termination (from "cradle to grave"). Changes affect what exactly to build and how, what exactly is counted as stock, what exactly is being ordered from a supplier, etc. The "PLM to ERP" relationship is especially critical for businesses that sell and/or manufacture controlled product for a regulated industry, but the concept is valid in any situation where traceability has value.

Dedicated PLM software has existed for some time and many suppliers of engineering design software (think Autodesk, SolidWorks, Onshape, etc.) either have built-in PLM features or integrate with third-party software (often later acquiring the third-party software). More recently a number of PLM web apps have appeared - examples including "Duro" - proprietary software first available in 2018 as an MVP and recently purchased by Altium (some may be familiar with Altium's PCB design software and Octaparts parts supply chain portal), "Dokuly" - proprietary software that pivoted to open source after exhausting funding in 2025, and "PartsBox" - proprietary software started specifically for electronics parts design and manufacturing.

Generally, PLM software by itself is insufficient to manage general business operations because it is missing financials and ERP software by itself is insufficient to manage product lifecycle for businesses requiring rigor because it allows ambuiguity. Either the ERP must support PLM or be integrated with seperate PLM software - which makes the resulting system even more complex and costly!

No popular open source ERP web software (that I am aware of) supports rigorous PLM and webERP can fill that gap.

Product Lifecycle

The simplest "product lifecycle" for an item has three states:

  • Unreleased: the item is identified in the system with at least some information about it. At minimum, the item name and whether it represents something that is bought, manufactured or a service. However, if bought, then perhaps also supply chain specifications for COTS parts, or fabrication specifications for custom parts. If made, then perhaps also a BOM. A general rule for an unreleased part is not to purchase, manufacture, sell or otherwise transact unless the user knows better.

  • Released: there are no restrictions on the item and it can be freely purchased, manufactured or sold (or any part of the process thereof).

  • Obsolete: Per The Manual, "the item is no longer used" (meaning an item which cannot be purchased, produced or sold for any reason but maintained for historical data consistency).

These three states are proven by the success of Parts&Vendors, the defacto Windows desktop and group PLM software for small businesses reigning almost 20 years from the mid-1990's to the late '20-teens (I admit I am biased having used Parts&Vendors almost daily since 2006 and will continue to use it until I can replace it with webERP).

Fwiw (and as an outsider), Parts&Vendors eventually failed by not progressing from a Windows workgroup to true shared access with an SQL database, allowing "Agile" to emerge as the leading PLM software for medium sized businesses (Agile would later be acquired by Oracle for selling to BIG enterprise and become unavailable to SMEs).

However, a business may desire to extend the number of lifecycle states or use the states already in use by their business, and allow only certain transistions between states according to desired or established business processes.

Different types of companies may have different lifecycle states:

  • a software development company releasing software
  • a holding company may have no life cycle
  • a rental company
  • a company dealing with physical items

E.g. 1. A business may wish to add a "Superceded" state for identifing an item in the process of being obsoleted - it has been superceded by another item but current stock is favored while it lasts (after which item state will be changed to Obsolete).

E.g. 2. A buiness may wish to use existing lifecycle states for finished products:

  • Setup
  • Test
  • Stable
  • No more production
  • Discounted
  • Recycle
  • Obsolete

and different states for "Components" (items only used as part of an assembly but not sellable as an independent item).

sidebar - webERP includes QA features to record that a specific lot or serial number of an item met some specification (e.g. an incoming or outgoing QA procedure) and can generate a certification report attesting to it.

Synopsis

Use Cases

TODO describe specific use cases for users and for high-level guidance to developers.

User Interface

TODO summarize features and provide mockup of proposed UI.

Database Changes

TODO summarize expected database schema changes.

1. Increase size of stockmaster.stockid from 20 char to 64 char

The stockid field is small compared to competition and user expectations.

The stockid field is used both in both explicit child foreign key constraints, explicit grandchild foreign key constraints as well as informal foreign key constraints and possibly also stored as a value (and not used in a constraint, either explicit or implicit).

Identifying all possible columns that must be re-sized is complex and discussed further here: Increasing stockid Size

  • Parts&Vendors allows 50 char
  • @pakricard OpenCart store allows 64 char

Discussion: https://github.com/timschofield/webERP/discussions/812

2. Increase size of stockmaster.description from 50 char to 255 char

The description field is small compared to competition and user expectations.

  • Parts&Vendors allows 255 char
  • @pakricard OpenCart store allows 255 char

Discussion: https://github.com/timschofield/webERP/discussions/812

3. Add stockmaster.notes column

The Notes column is to store ad hoc notes about a stock item.

The MariaDB "text" column type allows 65K one-byte characters or less if multi-byte. However, Z_ImportStocks.php limits the total char per row in a CSV to only 4KB (TODO confirm)

Discussion:

4. Add stockrefs table to store links to documents or websites related to stock items (many to many)

Table stores references to documents (filename and filesystem path) or website URLs related to a stock item for future reference (e.g. drawings, datasheets, product web page, etc.).

TODO confirm number of characters supported by Parts&Vendors.

Fyi, a planned future feature is to support using a seperate DMS (e.g. SeedDMS) for when formal document change control and traceability is required.

5. Add vendor "line card" table

Table stores relationships between a vendor and the OEMs (original manufactures) whose product(s) are sold by the vendor.

6, 7. Add manufacturer and manufacturer part number tables

The manufacturer and manufacturer part number tables store original manufacturers and part numbers for control and reference. Purchases for a stock item are made to a vendor using a vendor part number but if needed an associated OEM manufacturer and manufacturer part number can be specified.

A vendor may be a manufacturer but a manufacturer is not a vendor and a manufacturer cannot be purchased from. If a manufacturer only sells direct, only a vendor must be created. However, if a manufacturer both sells direct and through a distributor, both a vendor AND a manufacturer will need to be created with a mapping from vendor/vendor-partnumber to manufacturer/manufacturer-partnumber.

Often an item is satisfied by a particular manufacturer and manufacture part number and the vendor the item is purchased from is determined based on price, availability or some other criteria (e.g. a strategic purchasing agreement).

A "manufacturers" table already exists for storing "brands" (used for sales reporting IIUC), which must first be renamed (to e.g. "brands") and all references in code revised accordingly. Identifying code references is complex and discussed further here: Renaming existing manufacturers table

Also see:

8. Add lifecycle table and lifecycle state in stockmaster table

The lifecycle table stores an arbitrary set of lifecycle states and allowable state transitions.

New and/or Modified Scripts

TODO list scripts and their salient features in sufficent detail for coding to.

LifecycleState.php

Manage lifecycle states and allowed transitions.

Related Discussions

Related webERP discussions:

Clone this wiki locally