We are proud to announce the 5.4 release of Tryton.
In addition to my bug fixes and performance improvements, this release improves in many place the user experience. It also extends a lot the existing workflow to support more use cases. We see 8 new modules landing as official.
You can have a try on the demo server, use the docker image or download it here.
As usual the migration from previous series is fully supported. Some manual operation may be required, see Migration from 5.2 to 5.4.
Here is the list of the most noticeable changes:
(For a more complete list, see the change log of each package)
Changes For The User
We can show a visual context on the rows or cells. Those visual context can be
danger. Many modules have been updated to use them like the payable and receivable today on the party or when an invoice is due etc.
In the search bar of the clients, we enabled the direct search on fields of relational field types, like One2Many, Many2Many and Many2One. This is done by appending a dot to the relational field name and then the name of the field in the relation model. E.g. On products filter you can use the search clause
Variants.Code: PROD, to find all products, which variants have a code named
The search entry provides completion for such related fields.
By default only one level of completion is activated but customization can activate more. This feature also works on the keys of dictionary fields like the product attributes.
Now the clients display a more user-friendly error messages for domain validation error. The clients display the exact failing constraint using the same format of the search bar.
All the list views have been reviewed. The most important fields are now expanded to take advantage of available space. For main editable view, the creation of new record is done on top instead of bottom to avoid to load all the records.
For now, an CSV export created by a user will be only available for him by default. The administrator can make an export available to a group of users.
Now, when drag&drop is available on a view, we show a draggable icon to notify the user but also to provide a handle to drag which is easier when the list is editable.
The web client now supports drag and drop to order list and tree rows like in the desktop client. There is one small difference to insert a row inside a non-expanded row: The user must drop it below the row while pressing the
CTRL key. Otherwise the row is dropped next to the row.
The column size of the web client has been improved. Now columns have a minimal width (depending of the type) and a double scrollbar (top and bottom) is displayed if there is not enough space to show all the columns on the view-port.
The constraint that prevented to use twice the same invoice sequence per fiscal year, has been relaxed. Now Tryton checks only that the sequence was not used to number an invoice with a later date.
Since 14 September 2019, Strong Customer Authentication (SCA) has been introduced by EU regulators to reduce online fraud and make the internet a safer place to transact. For that Stripe has introduced the Setup Intent and Payment Intent mechanism for credit card payment. Tryton now supports them in addition to the former mechanism (for SEPA, SOFORT etc.).
Some financial institute have precise requirement about which initiator identifier to use the SEPA message. For that we added a configuration options on the payment journal. The available options for now are: “SEPA Creditor Identifier”, “Belgian Enterprise Number”, “Spanish VAT Number”.
Until now, it was possible to cancel a posted supplier invoice but not one from a customer. This was because in many countries it is not allowed. But in order to be more flexible, we added an option on the company to allow cancel of customer invoice.
When creating manually an accounting move, we set the date to today by default if the current period is selected. Otherwise it is still the start date of the period.
The wizard that renew automatically the fiscal year, now update the sequence name if it contains the year.
When migrating to Tryton, the accountant needs to fill depreciation of existing asset which has already been deprecated. To ease the encoding and ensure a correct computation, we added a field to store the already depreciated amount for the asset. This amount will be deducted from the asset value before continuing the depreciation computation.
To ensure that any tax line will be reported in tax statement, the tax is always required on the tax line.
It is now possible to define default values for the customer and supplier tax rules. This can be useful to apply a local tax rule based on subdivision by default.
In addition to the country, the tax rules can now be written using the subdivisions of origin and/or destination. A child subdivision will match the rule based on an upper level subdivision. This is useful for countries that have different tax rates for some subdivisions.
The income statement is included in the balance sheet for the Spanish accounting (as it is done for other countries). So the running income of the current year is already included before the year closing.
The BIC of banks are now validated and formatted. This avoid encoding error and ease the research.
Until now, the subdivision on an address was limited to the top-level subdivision of the country. It is now possible to define which types of subdivision are allowed to be used. Tryton comes with some configurations following the country rules for postal address format.
Now it is possible to configure a sequence for the product code that will be used to be filled at creation time. This may be used to ensure to have a unique code per product, even when it is duplicated.
Like for parties, we added on product a list of identifiers. By default, Tryton supports and validates these numbers: EAN, ISAN, ISBN, ISIL, ISIN and ISMN. Non-standard identifiers are supported also. These identifiers are used for matching when searching products by name.
The product cost price can be used in the price list. It uses the cost price of the company set in the context. This allows to build price lists by defining a margin to apply on the cost.
You can now define which unit of measure is the basis for quantities used in a price list. In standard modules we support the default unit (the original one) and the sale unit.
It is now possible to configure the customer code of the current company on the supplier party. The code will be displayed on the request for quotation .
The same processing delay for purchases is added to the requisitions. This allows to reset an approved requisition to draft if it was not yet automatically processed.
We added the same processing delay for sales to the sale complaints. So you can reset to draft a complaint after being approved or rejected if it was not yet automatically processed.
We added an option to deactivate a subscription service. This prevents to use these service for new subscriptions.
We allow now to finish a subscription line before the next consumption. This gives more flexibility about ending subscription.
Now users are able to set a default warehouse in the preferences.
This is useful for companies with multiple warehouses. It saves time for the users as they could have the warehouse filled-in for which they work.
You can use consumable products in an inventory if needed. There are still no requirements and the inventory is not automatically filled with products of this type.
When you are looking at the evolution of the stock quantity for a product, you can open the date to see the moves involved for the changes.
When opening the graph of product quantities by warehouse, if there was no move for the current date, the user can not see the current quantity. Now we add always an entry for the current date.
We force now to always have a minimal quantity for the order point. This avoid confusion for the case where it was not set. Now if you do not want to trigger the purchase or production for any quantity, the user must set an explicit negative quantity.
When using the “Enter Timesheet” wizard, now we display the date in the window name (next to the employee name). The shown date is the one selected in the first step of the wizard.
These modules allow to define a different secondary unit and factor on the product for sale and for purchase.
The quantity of sale and purchase lines can be defined using the secondary unit fields (quantity and unit price), the main unit fields are automatically updated using the product factor.
On related documents like the invoice or shipment, the secondary fields are displayed using the factor stored on the sale or purchase.
The amendment modules allow you to change sales and purchases that are being processed and keeping track of those changes. When an amendment is validated the document is updated and given a new revision. If needed, the invoices or shipments are also updated or recreated to match the new order.
Purchase and Sale History
These modules activate the history on sales and purchases but also add a revision number which is incremented each time the document is reset to draft. The revision number is appended to the document number to ensure parties are communicating about the same version.
Changes For The Developer
It is now possible to use SQL expressions as value with the create/write methods. The main purpose is to be able to use the time functions of the database server which are linked to the transaction instead of the one provided by the Tryton server.
expand attribute has been changed from a Boolean (1 or 0) into an integer. The integer represents the proportion of available space which is taken among all expanded columns.
format_date method on
Report can now take an optional
format parameter if you don’t want to use the default format of the language.
Report receives also a new method
format_timedelta. It uses the same representation as the clients to format duration field values.
There is now an environment variable to set the default logging level when running trytond as a WSGI application.
Now we have a
lazy_gettext method which allows to defer the translation by using a
LazyString . It can be used as label or help text of
Fields . This is useful for base
Model classes and
Mixins to limit the duplication of the translation of the same string for each derived class.
Now we prevent to set a value for an unknown field in proteus scripts and in Tryton modules model definitions. For that we add
__slots__ automatically on each model. A positive side effect is that it reduces also the memory consumption of each instance.
We have already a
multiselection widget to use with a
Many2Many field. But now we have also a
MultiSelection field which stores a list of value as a JSON list in the database. This is useful when the selection has a few options. For now, the widget is also available on list views (but not editable). And the field is usable in the search bar of the client.
You can now define a different start date when using PYSON
DateTime with delta.
Now we give the possibility to define a different order (alphabetic) to the keys of a Dict field.
Even if cron jobs are relaunch, it is better to retry directly them few times when a
DatabaseOperationalError is raised. This also avoid unnecessary errors in the logs.
Missing a depends on a method is a common mistake. We have improved the generic test to catch more cases like missing or empty parent or unknown field. All the modules have been checked and corrected against this new tests.
The generic checkout page for Stripe has been updated to use
Stripe.js and support setup and payment intent.
Until now, it was required to setup a webhook from Stripe to Tryton in order to receive the events to update asynchronously the workflow of the payments. Now if you do not setup such webhook, a cron task will fetch periodically the new events and process them. This is useful for testing or when Tryton can not be reached from outside.
We require now to have a fresh session to post a statement. If it is not the case, the client will request to re-enter the user password (or any other authentication method configured).
The countries, subdivisions and currencies are no more loaded from XML at the module installation but using proteus scripts which use pycountry data:
trytond_import_currencies . The translations are also loaded by those scripts.
This reduces the maintenance load of each release and allows users to keep their database up to date without relying on Tryton releases.
As the countries are no more managed as XML data in Tryton (but by import script). The address format are now using country and language code instead of
Many2One. So a format can be created even if the country or the language do not yet exist.
As we now keep a link between the inventory moves and the outgoing moves, we simplified the synchronization algorithm to use this link. Another advantage is that if the product is changed on the inventory move, the outgoing move is also updated instead of creating a new move.