Tryton documentation 8.0

This portal explains Tryton through three connected perspectives: business use, safe operation, and development. Content is separated by series so that 8.0 instructions are not accidentally applied to older installations.

Learning objectives

• Choose a path that matches your responsibility. When finished, verify the result with a test record and document ownership.
• Always confirm the version shown in the top navigation. When finished, verify the result with a test record and document ownership.
• Use the module catalog to verify dependencies and technical surface. When finished, verify the result with a test record and document ownership.
• Test accounting configuration and migrations on a staging database. When finished, verify the result with a test record and document ownership.

Concepts to master

• Choose a path that matches your responsibility.
• Always confirm the version shown in the top navigation.
• Use the module catalog to verify dependencies and technical surface.
• Test accounting configuration and migrations on a staging database.

Guided practice

1. Activity 1. Choose a path that matches your responsibility. Perform it in staging first, record preconditions, and compare expected and actual results.

2. Activity 2. Always confirm the version shown in the top navigation. Perform it in staging first, record preconditions, and compare expected and actual results.

3. Activity 3. Use the module catalog to verify dependencies and technical surface. Perform it in staging first, record preconditions, and compare expected and actual results.

4. Activity 4. Test accounting configuration and migrations on a staging database. Perform it in staging first, record preconditions, and compare expected and actual results.

How to verify the result

• Company, user, language, time zone, and date match the scenario.
• Permissions allow only operations assigned to the responsibility.
• Changes are traceable and related documents remain consistent.
• The procedure is repeatable and has a documented correction path.
• A restored backup can reproduce the process without relying on production.

Common mistakes

• Confusing save with confirm, post, pay, or close.
• Testing only as administrator and assuming access rights work.
• Changing states or totals with SQL to bypass validation.
• Upgrading without inventory, restorable backup, and post-upgrade reconciliation.
• Documenting only the happy path while omitting cancellation, correction, and exceptions.

Developer perspective

Identify the models, fields, buttons, domains, and access rules involved. Before extending the process, locate the module that owns the rule, review its tests, and preserve invariants through super(). A correct customization must work across companies, languages, permissions, and states.

Production checklist

• Company, user, language, time zone, and date match the scenario.
• Permissions allow only operations assigned to the responsibility.
• Changes are traceable and related documents remain consistent.
• The procedure is repeatable and has a documented correction path.
• A restored backup can reproduce the process without relying on production.