We are proud to announce the 5.6 release of Tryton.
This release provides many bug fixes and some significant improvements. Among other changes you will find big improvements in the cost price computation and stock accounting, the link buttons to display related records and the employee audit on key actions.
You can give it 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.4 to 5.6.
Here is the list of the most noticeable changes:
(For a more complete list, see the change log of each package)
Contents
Changes for the User
We added link buttons to the sale, purchase and party forms. They each open a view containing related records. For example on the sale form there is a button that opens the invoices it has generated. Each button also displays the number of records it will show if clicked. And if the target view has tabs, there is a counter for each tab.
The CSV export has been improved by adding an option to export the listed records (instead of only the selected records). Also now it is possible to get a URL that can be used to retrieve the configured export later. This is useful if you want to use it in a spreadsheet because it can be refreshed on the fly. Of course the URL is protected by the standard authentication mechanism of Tryton.
We also now allow users to directly select a relation field to export. In these cases it is the record name that will be used. This prevents the user from needing to search for this specific field.
It is possible to create attachments and notes that will be copied on to other documents that get created by the initial document. For example on sales, it is possible to add an attachment that will be copied on to the invoices created from the sale.
Web Client
The header for lists now sticks to the top (if the browser supports it). This means that the header is always visible even when you scroll far down the list.
On mobile screens, we automatically hide the cells that are empty. This saves space and thus allows more room for useful information.
We implemented an infinite scroll on all the lists. This means that when the user scrolls down and reaches the bottom of the loaded records (by default 20), the client automatically loads a new set of records. (There is no longer the need to click on the More button).
Desktop Client
We replace the retired App Menu by a primary menu in the header bar (on the right). This is because the GNOME project deprecated the App Menu so we expect it’s maintenance will be a low priority for them.
We moved the word “Tryton” to the end of the header bar. This is because when the application is minimized, there is often only limited space to display the title so we think it’s better to show the company name in case you have multiple instances.
Accounting
The default ordering of accounts now includes its code. This is more intuitive for accountants that are used to using the account’s code instead of its name. This is very useful when reviewing big account moves, like the one used to import the starting balance from other systems.
The move created by the Grouping wizard is now shown. This allows the user to post it once it’s reviewed.
The default depreciation frequency for assets can now be set on the account configuration. Once a value is set it will be used for all new assets.
It is now possible to define a second type on the account for when the balance is a debit. This is useful for some countries which require the balance of an account to be reported in two different places depending on whether it is a debit or a credit.
The wizard, to automatically create the periods for a fiscal year, asks for the day of the month on which the periods ends. In some countries it is possible that the period may not start on the first day of the month, like in the United Kingdom where for some companies it starts on 6th April.
To avoid a strange result when asset depreciation starts or ends on a leap year, we use a fixed year of 365 days in the calculation.
To speed up the processing of the reconciliation wizard, we ignore any deposit account that is not fully balanced. Such accounts should never be reconciled with write-off.
We simplified the stock accounting (perpetual) configuration by requiring only 3 accounts. This simplification allows the cost price to be recalculated and the adjustment move to be posted automatically.
Spanish account
A new tax group for selling services has been added which allows the tax rules needed for selling to other countries to be included by default. This tax rule will correctly set the tax depending on the nature of the items sold: goods or services.
A tax rule for regimen especial de Agricultara ganadariea y pesca has been added.
The Spanish tax authority added a new normative which requests that all companies send the EC operation list on a quarterly basis. We updated the report to be based on dates (instead of periods) allowing all companies to fulfill the new normative.
The Spanish bank association allows companies to send requests to their banks for the advancement of the SEPA Payments. We added a new check on the payment journal for Spanish accounts. When it’s checked the generated SEPA file will include the information needed to request the advancement from the bank.
Invoice
The lines to pay are now shown on the payment tab of invoices:
This allows the user see all the maturity dates of the invoice and also manually update them if required.
We now support overpaying an invoice (using the payment wizard). In such case the extra amount is booked on the party account.
When creating a credit note, it is possible to set a specific date for it. This is useful if the credit note is a refund because once posted it can not be edited any more.
Payments
When creating a payment from move lines the user is required to set the payment date. Now, the user can leave the payment date blank, which will use the line’s maturity date as the payment date. This allows them to create, in a single step, several payments that are due on different dates.
The user can force Tryton to use a specific SEPA mandate on a draft payment. In order to help when searching the mandate, we added the bank account number to the record name.
We now support the partial or complete refund of Stripe payment.
Statements
We now use the date of the statement line as date for the clearing move. This provides more accurate accounting if the statements are not posted for a long time.
Bank
The bank name and currency are included on the account record name, this allows you to pick the right bank account if you can’t remember the bank account number but you can remember the bank name or currency.
Carrier
We added an option to deactivate a carrier. This prevents use of these carriers for new shipments.
When a carrier is duplicated, its selection criteria are also duplicated to simplify the work of the user.
Commission
An agent selection is now available for Parties. This allows you to set the default agent that will be used for the sales related to this party. The selection accepts a date range which will be compared against the sale date to determine the correct agent for the party.
It is now possible to use an agent as recipient for notification emails. This allows you to automatically send agents the invoices that generate a commission for them.
Company
In order to simplify the profile status, we do not display the company nor the employee if they are the only possible value for the user.
It is now possible to define for each employee a supervisor and a list of the employees that they supervise. This can be used when writing access rules, for example.
Party
The record name for a contact mechanism now also shows the name if it is filled in. This helps when the contact is stored on document so all the needed information is visible.
When searching for a party or a contact, the result can be ordered by the proximity of the parties along relationship lines. This has been implemented on the contact field for sale, opportunity, purchase and subscriptions.
Product
We now enforce the uniqueness of the code for all active products. This allows you to use it as a SKU code or as key for a web shop.
A common prefix for the variant’s codes can be defined on the template.
The form for product variants can be a little bit confusing because it contains the fields inherited from the template but which are read-only. To help the user, we hide these read-only fields when they are empty which is normally the case when creating a product variant. This prevents the user from trying to fill them in. Also when a template is created from the product variant form, we no longer create a default variant for the template. This avoids a common problem where the user ended up with two variants by mistake.
Production
When a production is reset to draft, we now delete all the cancelled moves. This avoids confusing the user who can easily miss that cancelled status.
We now store on each production order the employees who assigned, run or did it. This helps to audit what has happened in case of issues.
There is now a scheduled task that ensures the cost of a production is recalculated and updated when some of the input products have their cost price modified. This ensures there is always the correct cost pricing for all productions. The changes to the cost of a production are automatically allocated to the output products proportionally based on their list price.
You no longer need to define the work center for requested or draft productions. This only needs to be done for the subsequent steps. This allows you to manually assign productions instead of using the automatic process.
Project
We allow the user to freely define the available status for the projects and tasks. For each status, a minimum progress can be enforced. Those statuses then automatically become tabs on the views.
We improved the invoicing process in such way that it is no longer based only on time. So it is now possible to have fixed price for a task (using a service whose unit of measure is not based on time).
Purchase
We added a wizard to create a return from a purchase. This may simplify the user’s work when they have to return a complete (or almost complete) order.
For each purchase order we now store the employees who quoted or confirmed them, and also the employee who converted a request into purchase and the one who rejected or approved a requisition. This helps when auditing what has happened in case of issues.
We added a contact and an invoice party to the purchase. This way, by default, the purchase order can support nearly all the different possibilities.
Sale
Sale reporting is now based on the actual quantity of each line. By actual quantity, we mean the actual amount shipped or invoiced because sometimes some lines are not totally fulfilled.
For each sale order we now store the employees who quoted or confirmed it. This helps when auditing what has happened in case of issues.
We added a contact and an invoice party on the sale and opportunity. This way, by default, the orders can support nearly all the different possibilities.
We added a menu item in the sale menu to show salable products. Using this view the user can see the prices and quantities according to the parameters like sale date, price list, customer etc.
Complaint
Based on the complaint we now support performing a partial return of a sale or credit invoice. This means for each line we can set the quantity for which the action must be performed.
Subscription
We now store on each subscription the employees who quoted or ran it. This helps to audit what happened in case of issues.
If no end date is defined when ending a subscription, we automatically set the greatest end date from the lines.
We added a contact and invoice party to the subscription to follow the sale design.
We now support subscriptions that invoice before the start of the subscription.
Stock
We have greatly improved the product cost management. There is now a scheduled task that recalculates the cost price of each product when needed (for example a landed cost has been applied on a past move). The re-calculation also updates the cost history for the product (stored on the moves).
It is also possible to add cost price revision at a specific date for a variant or a template. The revision can be a fixed cost price or a formula (e.g. for a reduction of 10%: cost_price * 0.9). Those revisions are automatically applied when recalculating the cost price. Such revisions are entered using a wizard which ensures the recalculation happens on the fly.
We added some visual indicators to the quantities of products and locations. This helps the user quickly find records with issues.
We no longer define a lost and found location for each inventory. Instead the lost and found location is now defined per warehouse. This avoids mistakes and ensures that the same location for each warehouse is always used.
The warehouse in which the user is working is now displayed in the user status, but only if there are multiple warehouses available.
We now use a MultiSelection widget for the supply days. This provides an easier way for the user to select and update the days.
New Modules
Cash Rounding
The account_cash_rounding module allows cash amounts to be rounded using the cash rounding factor of the currency.
Sale Supply Production
This module allows Tryton to generate, on sale, a production request for producible products regardless of stock levels. Like the other sale supply methods this new module also assigns the customer shipment after the production is done.
Changes for the Administrator
For Windows we now build two versions of the desktop client: 32bits and 64bits.
On the first login, the administrator has a new setup wizard which allows them to activate more languages. The new languages are loaded automatically.
Setting up the email configuration can be complicated. To help on this task, we added an option to trytond-admin which sends a test email.
It is now possible to make Tryton load the WSGI middleware defined in the configuration.
Country
The script that loads zip (postal code) entries now creates an entry for each level of subdivision found in the source.
Stock
Now it is possible to calculate supply stock from a scheduled task. This allows you to recalculate the stock needs of the company every night, so when the user logs into the system the next day all the information is up to date. This task is deactivated by default which allows manual stock supply calculations to be run as required.
Changes for the Developer
The Function field can be accessed from unsaved records if the getter method is based on an on_change_with.
The ir.resource module defines a new mixin which adds the method copy_resources_to to manage the copying of resources to new records.
The form view has a new tag <link/> which is used to display a relate button. The button displays the number of records (per tab) that the action will open.
When using ModelStorage.save and ModelView._changed_values, we support the delete or remove actions for xxx2Many. For One2Many records will be deleted by default but the field provides a method One2Many.remove which will instead remove the specific record. And for Many2Many it is the opposite way round with the availability of a Many2Many.delete method.
To support the export of data for the listed records, we added a ModelStorage.export_data_domain which allows records to be exported using a domain instead of a list of records.
This method is used on the new route <database>/data/<model> which returns the CSV file for the export.
The ModelView.view_attributes allows you to define the fields to add to the view if the attribute is applied. This ensure the proper behavior of the PYSON attribute.
We applied the same simplification to ir.trigger as happened to ir.cron. We now use a selection to define the method to trigger. In addition to the simplification, we also now run the trigger in the queue. This ensures that the trigger is run only once per transaction and only if at the end of the transaction the record is still valid for the trigger. This avoids, for example, multiple email notifications being generated for the same event.
As now resources can be copied between records, we optimized how Binary fields are copied by using a file_id. In these cases, we do not duplicate the contents as only the file_id gets copied.
Tryton is now fully tested against Python 3.8. Some warnings have been fixed to ensure future compatibility.
Now when a Model is inheriting the DeactivableMixin, all its fields (except active and the buttons) are read-only if the record is inactive. This unifies the behavior across the whole application. All standard modules have been reviewed to remove the code that previously implemented this behaviour for each model individually.
The editable attribute of the tree view is now a boolean. This allows the client to choose the best position to use when adding a new record by looking at the default order the server sent it.
We replaced, for performance and simplicity, the advisory lock by the more standard SKIP LOCKED when pulling from the queue.
The Dict field has been improved to support the definition of MultiSelection as a value and to define help text per key.
The Model.button_action can now return values that will be used to update the action returned. This allows the creation of dynamic actions without the need to create a full wizard.
Tryton will use WeasyPrint to convert html and xhtml reports into pdf if it is available. It is preferred over LibreOffice because it gives better results.
In trytond.url we added some useful tools to help compose URLs. is_secure returns whether the trytond is serving over an encrypted connection. host returns the name the server can be reached at. And finally http_host composes the two previous methods together to return the base URL.
We also added to URLMixin the attribute __href__ which returns the http url for the instance.
The wizard’s buttons have a new attribute called validate which defines whether the client must validate the form or not when the button is clicked. This allows the creation of, for example, a skip button which does not end the wizard but also does not care about whether the form is valid or not.
The Tryton exceptions now return statuses in the 400s instead of 500s which is semantically more appropriate.
When setting records in a One2Many field of an instance, we automatically fill in the reverse field. This is useful because it allows methods to be called that rely on the reverse field of a unsaved record.
We removed the attribute skiptest from the XML data. It was no longer used in any of the standard modules and it is a bad idea to not test data loading.
Similarly to the removal of implicit field names on ModelStorage.read, we also removed them from ModelStorage.search_read for consistency.
We unified the string representation of instances between trytond (the server) and proteus (the scripting library).
Accounting
We added support for a context keyword _account_invoice_correction that is used when copying an invoice for correction. If it is set the stock_moves links on the lines are copied, otherwise they are not.
We merged the SEPA identifier defined by account_payment_sepa with the standard eu_at_02.
It is now possible to configure the max_network_retries used by the Stripe library.
Company
In company.model we added tools to manage the setting and resetting of employee fields. Those methods are used in all the standard modules that need such features.
We added the employee instance to the evaluation context of the record rule. This allows rules to be written based on employee properties.
Sale
To manage a unique state for sale line supplied (by purchase request or production), we renamed the purchased state into supplied which is more generic.