The words you’ll hear on an ERPNext or Odoo project
Short definitions first, then how each thing works, an example and the mistakes we see. Written for the operations lead sitting in on a developer call as much as for the developer.
ERPNext and Frappe
Build on ERPNext ›- bench
- bench is the command-line tool for setting up and managing Frappe Framework and ERPNext deployments. The word also refers to the bench directory it creates, usually frappe-bench, which holds the apps, sites, Python environment and configuration shared by every site on that server.
- Child Table
- A Child Table in Frappe and ERPNext is a DocType marked Is Child Table whose records only exist as rows inside a parent document, such as the items on a Sales Order. The parent holds the rows through a Table field, and each row stores its parent, parenttype, parentfield and idx.
- Custom Field
- A Custom Field is a field added to an existing DocType, such as Sales Order or Customer, without editing that DocType's source files. Frappe stores it as a record of the Custom Field DocType, adds a matching column to the database table and merges it into the form's metadata at runtime.
- DocType
- A DocType is the basic data model in the Frappe Framework, which ERPNext is built on. It defines a type of record, its fields, naming rule, permissions and form layout, and Frappe creates a matching database table plus a list view and form view from that definition.
- Fixtures
- Fixtures are database records, such as Custom Fields, Property Setters, Roles or Workflows, that a Frappe app exports to JSON files in its fixtures folder. Frappe imports those files whenever the app is installed and on every bench migrate, so each site running the app ends up with the same records.
- Frappe app
- A Frappe app is a Python package built on the Frappe Framework that lives in a bench's apps folder and gets installed on one or more sites. ERPNext is itself a Frappe app, and a custom Frappe app holds your own DocTypes, hooks, patches and front-end assets in a Git repository.
- hooks.py
- hooks.py is the configuration file inside every Frappe app's Python package where the app declares how it plugs into the framework, such as document event handlers, scheduled jobs, fixtures, form script includes and class overrides. Frappe merges the hooks of all apps installed on a site and applies them together.
- Print Format
- A Print Format is the template Frappe uses to turn a document, such as a Sales Invoice or Delivery Note, into a printable page or PDF. It can be laid out by dragging fields in the Print Format Builder or written by hand as a Jinja HTML template with its own CSS.
- Script Report
- A Script Report is a Frappe report whose columns and rows are produced by Python, typically an execute(filters) function that returns column definitions and data, with its filters declared in a JavaScript file. It's the report type to use when the numbers need more logic than a single SQL query can express.
- Server Script
- A Server Script is a Frappe record holding Python code that is written in the desk and run in a restricted sandbox. Depending on its type, it runs on a document event, answers an API call, runs on a schedule or filters list queries, all without a custom app or a deploy.
Odoo
Build on Odoo ›- ir.cron
- ir.cron is the Odoo model behind Scheduled Actions: each record tells the server's cron workers to run a piece of Python code against a model at a fixed interval, such as every hour or every day. Modules usually ship them as XML data records that call a model method.
- ir.model.access.csv
- ir.model.access.csv is the CSV data file in an Odoo module's security folder that creates ir.model.access records, each granting one user group read, write, create or delete rights on a whole model. A model with no line in it can only be used by superuser code.
- __manifest__.py
- __manifest__.py is the file that turns a Python package into an Odoo addon. It holds a single dictionary literal declaring the module's name, version, license and dependencies, the XML and CSV data files to load, and the static files it adds to asset bundles such as web.assets_backend.
- Odoo addon
- An Odoo addon (also called an Odoo module) is a Python package that Odoo can install into a database: a folder on the addons path with a __manifest__.py and an __init__.py, plus the models, XML views, security files, data and web assets it needs.
- Odoo Studio
- Odoo Studio is the no-code customization tool in Odoo Enterprise. It lets an admin add fields, change views, create models and apps, build automation rules, webhooks, approval rules and PDF report changes from the browser, and it stores that work as database records grouped under a module called studio_customization.
- Odoo.sh
- Odoo.sh is Odoo's official cloud platform for running Odoo Enterprise with your own custom modules. It connects to a GitHub repository, builds every branch you push in a container, and sorts branches into three stages: production, staging and development.
- OWL
- OWL (Odoo Web Library) is the JavaScript UI framework Odoo builds and uses for its web client. OWL components are ES6 classes with a QWeb template and a setup() method, keep reactive state through hooks like useState, and are plugged into Odoo through registries such as fields, systray and main_components.
- QWeb
- QWeb is Odoo's XML templating engine. A QWeb template is ordinary XML or HTML with t- directives such as t-if, t-foreach, t-out and t-call, and Odoo uses it to render PDF reports and website and portal pages on the server and, through OWL, the web client's components in the browser.
- Record rules
- Record rules are ir.rule records that limit which individual records of an Odoo model a user can read, write, create or delete. Each rule holds a domain that is checked record by record after access rights, so record rules can narrow what ir.model.access.csv grants but never go beyond it.
- XPath view inheritance
- XPath view inheritance is how Odoo changes an existing view without editing it. A new ir.ui.view record points at the original through inherit_id, and xpath elements locate nodes in the parent arch to add content inside, before or after them, replace them, change their attributes or move them.
Your next module is one paragraph away
Write it the way you’d explain it to a new hire. We’ll turn it into an app you can read, test and install.