Using Tryton to Manage Parts & Vendors

This post is one in a series on Tryton. Tryton is a mature open source business software generally called Enterprise Resource Planning software, or  ERP, which includes the functionality needed by an engineering design team to manage parts, vendors and bills of materials (BOMs), also known as product lifecycle management (PLM). 

Tryton is composed of a set of core modules with additional modules included as needed for less common functionality not all situations will require (in the world of software, generally less is better).

Two characteristics of high-tech product development are:

  • The road to large scale production is iterative, typically starting with a feasibility or proof-of-concept prototype, then one to three development prototypes, one or more pilot manufacturing builds, and finally production. 
  • Many of the parts incorporated in a product are Commercial-off-the-Shelf (COTS) items, manufactured by an Original Equipment Manufacturer (OEM) and sold through distributors and other re-sellers.

The process of design is itself iterative, working from the known, such as it needs to do this, it should be about X big, it must be able to provide X much output power, it must last X long between charges, the display must be X inches in size, it must be waterproof, it must be loud (or quiet), etc.

During development what is unknown will become known, and a design will emerge that meets requirements. At some point, it may become necessary to build a prototype to understand some aspect of the design in more detail, and design decisions made based on the prototype (generally either “that actually works great, don’t change a thing” or “that’s not good enough, find another solution”).  Building low volume prototypes efficiently is a detailed persnickedly job, missing only one is all that is needed to bring a finely tuned development or new product introduction (NPI) process to a grinding halt. 

A product is typically made from a mix of COTS parts and custom parts. Custom parts are used when no suitable COTS part exists or is unsuitable for one reason or another. Often custom parts are used to create a product identity, such as the enclosure, labelling, and user accessories, but they may also may be hidden, such as an internal mounting bracket or an integrated circuit that implements new technology. COTS items are typically general purpose electronics parts (e.g. resistors, capacitors, transistors, switches, display panels, many integrated circuits,  etc.) as well as general purpose hardware (e.g. screws and washers). The same OEM product is often available from several vendors, and often severa; OEM manufactures will produce a product similar enough be used interchangeably.  Custom parts will be sourced from the vendor selected to manufacture the custom part, while for COTS parts the designer must specify a source. Providing more sources will provide greater purchasing flexibility, which can be critical to staying on schedule when parts are in short supply or time is of the essence (or both).

A spreadsheet is often the first tool reached for to manage New Product Introduction (NPI) and new product bill of materials (BOMs).  If the product and part supply chain are simple, a spreadsheet approach will be manageable. However, a complex product structure, with separate sub-assemblies re-using common parts each with potentially multiple alternates and vendors, quickly eclipses a spreadsheet solution and a domain-specific Product Lifecycle Management (PLM) tool becomes necessary to prevent bottlenecks.

Tryton Modules

The figure below shows the Tryton standard modules. The modules needed for basic PLM and prototype manufacturing have been circled, and will support basic PLM and manufacturing. PLM support includes defining and managing parts and hierarchical BOMs, specifying approved sources for purchase, providing common access to part documentation such as OEM datasheets, engineering drawings and work instructions, and include a controlled change management  process when a design change is needed. Manufacturing support includes Material Requirements Planning (MRP), managing vendor Request-for-Quotations (RFQs), purchasing raw material, manufacturing and QA testing, product serialization if needed, and sales. The project management module has been included to report on product development, release and maintenance project costs, for control and business decision making.

Standard Tryton Modules Required for PLM and Prototyping Manufacturing


Swift Construction Company

The fictional Swift Construction Company (SCC) manufactures a radio receiver product called the Aircraft Wireless. The SCC designed the Aircraft Wireless, does the final product assembly and ships finished product to customers. The Aircraft Wireless contains a printed circuit assembly (PCA) with the radio electronics, which is assembled by an electronic contract manufacturer (ECM). The ECM is provided with a BOM for the electronics PCA,  and depending on the situation the ECM may be provided with a kit of parts, or the ECM may have to purchase the parts themselves (turn-key production).

The Aircraft Wireless product as sold to customers is SCC part number 100-0003 . This is the top-level part number and includes not only the Aircraft Wireless itself, but also the shipping box, user manual and included accessories.

The SCC has historically used a software PLM application called Parts&Vendors[1] (P&V) to document engineering designs. P&V was the eminant engineering PLM database of the 90’s for startups and small-to-medium (SME) businesses, but unfortunately Trilogy Design no longer exists and the SCC knows it is running on borrowed time and is looking for a suitable replacement. The SCC has selected Tryton as a potential replacement for P&V, and is starting a detailed evaluation process using their historical P&V workflows for reference.

Top-Level PN 100-0003 Assembly Tree


Workflows and User Stories

A variety of common worflows and user stories have been identified to explore using Tryton to understand Tryton’s basic behavior and identify any constraints.  A general description is provided here, each workflow will be described in detail in a separate post and linked from the heading once it is avaiable.

Please post a comment at the bottom giving any specific behaviors you would like to see explored.

Create a Part with Alternates and Sources

Identify one or more Mfr/MfrPN with a part, as well as one or more vendors that the Mfr/MfrPN can be purchased from and for what price.

PN 900-0006 is an axial diode, with three alternates specified, and a different vendor for each Mfr/MfrPN. The concept and basic requirements can be understood from how sources are managed in Parts&Vendors[2] (P&V).

P&V provides for a Vendor to be marked as the Primary vendor, and the cost of the item is driven by the entered vendor cost. This is effective during the engineering stage of a project when sources are first being identified, long before actual purchase, but having cost forecasts of known accuracy is vital to validate development. When the product transitions from design to production, costing will transition to standard model driven by purchase orders and receipt of product into inventory.

Sources for PN-900-0006 Diode
Sources for PN 900-0006 Diode


Parts generally need multiple units of measure (UOM) to be defined, and the relationship between them, for example the “use unit of measure” on a BOM for a particular epoxy catalyst might be in milli-litre, the “stock unit of measure” is 100ml bottles, and the “purchase unit of measure” is a case of 12 bottles. The units and their relationships must be defined corrrectly, and it may be necessary to consider round-off and calculation errors when chosing units, such as when wire purchased in a 19,300 foot spool and used in centimeters. 

New Units of Measure (UOM)

Capture Supporting Part Documents

It is convenient to capture documents associated with a part (such as manufacturer’s datasheets and engineering drawings) with the part for convenient access. As well, keeping ad hoc notes on a part can often provide crucial information to unravelling a future issue. 

Files associated with PN 900-0006 DIODE

Create a Bill of Materials BOM

PN 200-0001 (IND,830UH,AIRCRAFT WIRELESS) is the lowest-level sub-assembly in the  hierarchical Aircraft Wireless BOM.

PN 200-0001 Parts List

Make a Major Release (Revision)

Update a part or bill of materials using a controlled atomic workflow. Generate a report showing which parts not yet “released” (approved for use) within a product structure.  

Support an Alternate Assembly

If there are no true second sources for a Part, it may be possible to design the product such that the same function is maintained by use of some other non-interchangeable part. Using alternates in a controlled process will maintain traceability, which various regulated industries may require. 

As an example, assume a product with an internal power supply printed circuit board (PCB), which uses a particular monolithic AC/DC power supply module. The module is an “old” design, and has no direct alternates (mechanical and electrical) available, and the best electrical  alternate would require a new incompatible PCB. It also seems the module is getting harder to purchase, and because supply risk is increasing, which affects the abiliity of the enterprise to product product, it is desired to have an alternate process in place should the current module be unavailable, which is also a growth strategy until then.

A simple solution chosen is often to simply design a new PCB for the the best electrical alternate, up-rev the BOM to use the new PCB and module and don’t look back.  A better solution would be to create a new part number for a new PCB assembly, using the new AC/DC power supply brick and its own BOM and fab file set for the PCB, and recognise the new part number as an alternate for the original part number. This will allows running out of  raw and WIP materials as efficiently as possible, and provides traceability should the old PCB assembly be buld again (don’t say it will wouldn’t happen, I won’t believe you anyway).

Perform Simple Purchasing

A lot of PN 200-0001 (IND, 830UH, AIRCRAFT WIRELESS) must be manufactured to have in stock before the Aircraft Wireless PCA can be manufactured. Tryton production planning can be used to issue purchase orders for the raw material, but as there are only three parts it will be faster to purchase them manually.  

Manufacture an Edge Assembly

An edge assembly is one that does not contain sub-assemblies. The lowest level manufactured sub-assembly in the Aircraft Wireless is PN 200-0001, a custom 830uH inductor manufactured in-house by the SCC. 

Determine BOM Shortages for Manufacturing

Capture stock on hand by importing a stock count, and enter part purchase orders with expected delivery date. For a given date of manufacturing, generate a report showing required material taking into account stock-on-hand and parts on order.. 

Purchase an Assembled Printed Circuit Assembly

The assembled printed circuit assembly, or PCA (part number 200-0003) in the Aircraft Wireless is purchased in lots of 5 from an ECM. The SCC kits the necessary raw material for the build and consigns it to the ECM. When the finished PCAs are returned by the ECM, tey are received by the SCC, inspected, serialized and stocked in inventory.

Purchase Using a BOM

Generate a report of material required to manufacture a multi-level hierarchial BOM, taking into account stock on hand. Optionally generate purchase orders for required material taking into account minimimum stocking levels, minimum order quantities, price-quantity breaks, and order in multiples requirements. 

Sell a Serialized Product

This workflow explores serialized stock in the context of a customer purchase. B&E Submarines desires to purchase a spare parts kit for the Aircraft Wireless unit they previously purchased. A serialized circuit board is used in the assembly of the spare parts kit (preferably a phantom-type BoM to make the parts in it visible), which is then sold and delivered to B&E.

Sometime later, Ed Bentley calls from B&E. He says he found a circuit board, but he doesn’t know if it is the circuit board from the spares kit. Ed is not sure, but he thinks the original board might have failed and he swapped it with the one from the spare parts kit. Ed wants to know if the serial number on the board is the same as the board shipped in the spare parts kit he bought.

Report Use of Serialized Stock

Explore serial numbers in the context of a project. B&E Submarines plans to upgrade 5 of their submarines with Aircraft Wireless systems. A contract is negotiated between the SCC and B&E, and the SCC initiates a Project to capture all related activity (of which the physical receiver units are only one portion). Complete radio receivers PN 10000003 are manufactured, each with its own serial number, traceable to the serialized electronics circuit board within. The completed radio receivers are sold and delivered to B&E as part of the overall project.

Sometime later, Ed Bentley calls from B&E. He has a circuit board in his hand again, and wants to know where the serial number came from. Ed asks if the circuit board was from one of the 5 receivers delivered as part of the upgrade project.

Rent, Return, Inspect and Re-Stock a Field Support Kit

  • Create manufacturing order
  • Issue material to order (serialized PCA)
  • Deliver order to customer
  • Return order from customer
  • Inspect items, replace or repair as needed
  • Return material to stock (serialized PCA)

Act on Data from an IIoT Device

It is possible for an Industrial Internet of Things (IIoT) type device to interact directly with Tryton for a variety of tasks:

  • Create a service order when a device reports service is required in the case of non-optimal machinery operation.
  • Recognise asset transfer according to usage data a device  repots, such as sale of commodity such as electricity or oil, and automatically perform monthly customer billing.


[1] (active as of 2021-08-12)



Install Tryton using Docker on Ubuntu

The simplest method way to get Tryton up and running for a quick evaluation is to use the Docker image provided by the Tryton project on Ubuntu Linux, running as a virtual machine on a FreeBSD host.

Create Virtual Machine

Install Ubuntu 20.04 using the Ubuntu distribution DVD ISO and using the startup wizard configure appropriately.

Copy your user ssh key to the new server and disable password login.

Configure vm port forwarding.  Port forwarding with VirtualBox must be done with the vm powered off.

Name: ssh
Protocol: TCP
Host Port: 8000
Guest Port: 8000

Update Server OS

$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade

Install Docker

$ sudo apt install

Install Tryton

$ sudo docker pull tryton/tryton

Start a PostgreSQL instance

The Tryton image will be pulled from library/postgres

$ sudo docker run --name tryton-postgres -e POSTGRES_PASSWORD=mysecretpassword -e POSTGRES_DB=tryton -d postgres

Setup the database

$ sudo docker run --link tryton-postgres:postgres -e DB_PASSWORD=mysecretpassword -it tryton/tryton trytond-admin -d tryton --all

The script will prompt for:

  • “admin” email for “tryton”
  • “admin” password for “tryton”

Store the password in a key vault for safe future reference.

Start Tryton Instance

$ sudo docker run --name tryton -p 8000:8000 --link tryton-postgres:postgres -e DB_PASSWORD=mysecretpassword -d tryton/tryton

Start Tryton cron Instance

$ sudo docker run --name tryton-cron --link tryton-postgres:postgres -e DB_PASSWORD=mysecretpassword -d tryton/tryton trytond-cron -d tryton

Create bash Startup Script

Without further configuration the Docker container will not start automatically when the server starts. While it is possible to configure Tryton to automatically start, I have created a simple bash script for convenience to start Tryton manually.

dale@starlord:~$ cat
# run using sudo
docker start tryton-postgres tryton tryton-cron



Install Tryton on FreeBSD v13

Tryton is open source business software that can be used for enterprise resource management (ERP) and accounting. This post describes installing Tryton (and the PostgreSQL DBMS) on FreeBSD, and is one in a series on Tryton.

Tryton naming conventions:

  • Tryton (capitalized) is the Tryton system in totality.
  • trytond is the Tryton server daemon.
  • tryton (uncapitilized) is the Tryton desktop client. 
  • sao is the Tryton web client.
  • PostgreSQL is the database management system used by Tryton.

sao will not be installed in this tutorial.

This post is a Work in Process while being updated to describe installing Tryton 6.2 and PostgreSQL 14 on FreeBSD 13.

Install FreeBSD

Install FreeBSD v13 using suitable media and perform typical initial configuration. Create an initial admin user in the install wizard and include them in the wheel group. 

After booting into the new system and logging in as the admin user, copy a public ssh key for the admin user to ~/.ssh/authorized_keys and disable ssh password authentication in /etc/ssh/sshd_config for security.

% su - 
# vi /etc/ssh/sshd_config
# Change to no to disable PAM authentication
ChallengeResponseAuthentication no
# sudo service sshd restart

Update FreeBSD and package manager database for third-party software (pkg is initially only a shim which installs the current version of pkg).

# freebsd-update fetch
# freebsd-update install
# pkg update

Install sudo for the admin user to use for system administration.

# pkg install sudo

Configure sudo to allow the admin user (and all other members of the wheel group) to allow use without needing to enter a password for convenience (reasonable on a small system).

# visudo
## Uncomment to allow members of group wheel to execute any command
# %wheel ALL=(ALL) ALL

## Same thing without a password


Tryton supports the SQLite DBMS for developer testing but for production PostgreSQL will be used.  

Install the latest version of PostgreSQL (currently 14.1). 

% sudo pkg install postgresql14-server

Edit /etc/rc.conf to start the server at startup

% sudo vi /etc/rc.conf

Create a new PostgreSQL database cluster and start the PostgreSQL server. 

% sudo /usr/local/etc/rc.d/postgresql initdb
% sudo service postgresql start
% sudo service postgresql status

The installation procedure creates a “postgres” user who owns the PostgreSQL files and the postgres server process. The provided configuration file /var/db/postgres/data14/postgresql.conf will allow access from localhost only. 

Use the PostgreSQL createuser command to create a tryton” super-user,

% sudo su postgres
$ createuser -sdrP tryton
Enter password for new role:
Enter it again:
$ exit

and restart PostgreSQL.

% sudo service postgresql restart

Confirm localhost can connect to the PostgreSQL server (“-W” prompts for user password).

% psql --username=tryton -W --list
List of databases
   Name    | Owner    | Encoding | Collate | Ctype   | Access privileges
 postgres  | postgres | UTF8     | C       | C.UTF-8 |
 template0 | postgres | UTF8     | C       | C.UTF-8 | =c/postgres          +
           |          |          |         |         | postgres=CTc/postgres
 template1 | postgres | UTF8     | C       | C.UTF-8 | =c/postgres          +
           |          |          |         |         | postgres=CTc/postgres
(3 rows)


Tryton has required Python 3 since v4.4, and Python 3.8 will have been installed as a dependency of postgresql14-server. However it will be convenient to create symlinks for accessing Python in a conventional manner.

% cd /usr/local/bin
% sudo ln -s python3.8 python3
% sudo ln -s pydoc3.8 pydoc3

Also bash and and pip will need to be installed. bash (the Bourne Again SHell) is required to use Python’s built-in venv module, which will be used to create a virtual environment for Tryton to avoid potential system dependency issues. pip (the Python package manager), will be used needed to install Tryton from PyPI (the Python Package Index). 

% sudo pkg install bash
% sudo pkg install py38-pip

Unlike python3, pip will be executed simply as pip (which is a symlink to the actual executable pip3.8 created by pip installation).

pip (at least on FreeBSD) must only be used to install packages into a user directory or virtual environment to avoid creating system inconsistencies, as per the pip post-install message. 

Install the Python SQLite package so Tryton can use SQLite for testing, 

 sudo pkg install py38-sqlite3

Install System Dependencies

Tryton makes use of libxml2, an XML C parser and toolkit, and libsxlt, an XSLT C library. 

% sudo pkg install libxml2
% sudo pkg install libxslt
% sudo pkg install graphviz

graphviz is not required unless sao is being installed.

Create a directory to install trytond

Create a directory to install trytond in. A dedicated user could be created to execute trytond, and their home directory used to install trytond and for storing document attachments, but for simplicity at this time a regular user and home directory will be used.

% sudo mkdir -p ~/work/trytond

Create virtual environment

% cd ~/work/trytond
% bash
% cd work/trytond
% bash
$ python3 -m venv env
$ source env/bin/activate
(env) ~/work/trytond$

Install trytond and modules

First install trytond, which provides basic Tryton server functionality.

(env) ~/work/trytond$ pip install trytond

Next install trytond modules for required user functionality. For managing parts, bills of materials, vendors and customers, the following modules will be sufficient.

  • trytond-product 
(env) ~/work/trytond$ pip install trytond-product

You can search PiPY for Tryton Framework to see all Tryton modules. Refine the search by adding “trytond” in the search field and sort the results by last updated, which will tend to put core modules towards the top of the list.

trytond modules can have dependencies, which will also installed when a module is installed. To see all the trytond modules which have been installed, use pip to list installed modules and grep for trydond.

(env) ~/work/trytond$ pip list | grep trytond
trytond 6.2.3
(env) ~/work/trytond$

Create a log directory for trytond.

% sudo mkdir /var/log/trytond
% sudo chown -R tryton:tryton /var/log/trytond

Create a json-rpc data directory for trytond

% sudo mkdir /var/run/trytond
% sudo chown -R tryton:tryton /var/log/trytond

Create trytond.conf

The Tryton configuration file trytond.conf is read by the Tryton server daemon trytond when it starts, and includes such site-specific data as:

  • computer addresses to respond to (jsonrpc).
  • username and password for the PostgreSQL “tryton” super-user.
  • Tryton “administrator” password (required to create, drop, backup or restore a database).
  • specify FreeBSD-specific directory paths

The trytond package does not include a trytond.conf file as trytond will use reasonable defaults, including using an SQLite database. However PostgreSQL is the recommended database for use cases other than basic testing, which will require creating a suitable trytond.conf file.

Create trytond.conf with the following content:

jsonrpc = *:8000,
jsondata_path = /var/run/trytond

db_type = postgresql
db_host = localhost
db_port = 5432
db_user = tryton
db_password = appleton

admin_passwd = appleton

pidfile = /var/run/trytond/
logfile = /var/log/trytond/trytond.log

data_path = /home/tryton

Start trytond

For production use an rc script should be created to control trytond. However for simplicity trytond will be started manually.

# ~/work/env/modules/bin/trytond

trytrond can be stopped using Ctrl-C.

Create and configure a new Tryton database

Download and install tryton, the Tryton desktop client for your system. The major and minor version of tryton must be the same as the major and minor version of trytond to connect.

Launch the Tryton client and access menu: File > Databases > New database.

Enter the Tryton server admin password (“admin_passwd” in trytond.conf) in the password field, then click Change beside the IP address and change the address to that of your server.

You must enter the password first, before changing the server address, because the Tryton client will attempt to connect to the server immediately after the server address is changed, and will report “Unable to connect” if the admin password was not already entered.

Enter the name of the database to create (e.g. “scc”) and the admin password for the database, then click Create.

Login to the new database as user “admin” and the password you entered to create the database. The Module Configuration Wizard will run automatically after login to configure the new database.

  • Add user (e.g. “Dale Scott”, login “dale”), optionally add permissions (you may need to update user permissions after installing modules, so this is optional at this point),
    • add Permissions: “Administration” (which will be the only permission group available)
    • add Rule: Read, Write, Create, Delete, Model: View Search (which will be the only rule available available).

The new Tryton database can now be configured for use as per Configuring Tryton (coming soon).

Maestro Dev Review

I posted recently that Maestro development was moving from the Tryton framework to ERPNext.

There two perspectives to keep in mind when managing a project. The first is a crisp motivating vision of the goal, the second is the path to goal. The challenge is finding the path that best balances cost, time and quality, taking into account technical and operational risks and constraints. Oh, and did I also say the path needs to changes as new information becomes known, risks become better understood, new skills are learned, team members come and go…

Also, periodically review the individual steps on the path. Are the risks acceptable? Should a step be simplified or re-factored? Are there appropriate contingencies available? Backcasting can also be a useful technique, working backwards from the goal to the current position (Harry Tucker has a great backcasting visual).

Getting back to the Maestro project…

Maestro Platform Iterations

Maestro is now in its fourth platform iteration:

  • Platform 1 – Loosely coupled web apps (WebERP, MantisBT, OpenDocMan)
  • Platform 2 – Full-custom monolithic web app (Yii Framework)
  • Platform 3 – ERP framework (Tryton) with Integrated web apps apps (MantisBT, OpenDocMan)
  • Platform 4 – Single ERP web app (ERPNext)

Platform 1

Platform 1 was a loose integration of three separate web applications. Each application had integration points to the others as appropriate, such as from an Item in WebERP to the control documents for it in OpenDocMan, or from an Issue in Mantis to the Item in WebERP, or related documents in OpenDocMan.

|-- WebERP
|-- OpenDocMan (document control)
|-- Mantis (issue management)
\-- Launch portal (simple HTML page)

Development moved to Platform 2 after the initial prototype showed the effort to understand the underlying architectures, data structures, and different coding styles of each application, and to create an overall cohesiveness, would be greater than the effort saved by using separate applications in the first place.

Platform 2

Platform 2 was a full custom web application based on the Yii Framework. A prototype was completed with a rudimentary Parts module (including CSV and PDF export) and Order module, but development moved to Platfrom 3 in March 2014 after departure of a key team member. 

Platform 3

Platform 3 was a throwback to Platform 1 (a collection of loosely coupled applications), but with the Tryton framework (including native desktop client) replacing webERP, and WordPress replacing OpenDocMan. OpenLDAP provided a single point of user management and authentication, a self-contained messaging system was provided with Postfix, Dovecote and SquirrelMail, and WordPress provided a launch portal and document control system.

Maestro development moved away from Tryton in September 2014 after the completed prototype showed the need for both core development as well as a simplified domain-specific web-based user interface, and doing both was  beyond the ability of the project team.

|-- Tryton
|-- Desktop Portal (WordPress)
|   |-- Notices (posts)
|   |-- User Manual (pages)
|   \-- Documents (WP Document Revisions)
|-- Issues (Mantis)
|-- Messages (SquirrelMail)
\-- Users (phpLDAPadmin)

Platform 4

In the same way as Platform 3 was a throw-back to Platform 1, Platform 4 is a throw-back to Platform 2 – a single integrated web application. However, instead of a green-field development, Platform 4 is based on ERPNext.

After development moved away from Platform 2, but before starting Platform 3, two web-based ERP systems were evaluated – ERPNext and OpenERP/Odoo. Although both showed promise, Odoo had a significant learning curve for core development that would be needed, and ERPNext was still relatively young and immature. However, over the course of Platform 3 development, ERPNext made such significant progress that it became feasible to use for Platform 4.