Tryton Release 4.2

[ced (Cédric Krier)]

We are proud to announce the 4.2 release of Tryton.

With this release, Tryton extends its scope to tailored user applications like Chronos and also as backend for webservice.
A part of the effort was put also on closing the feature gap between the web and the desktop client. The web client is still a little bit behind in terms of features but at the current rate the gap will disappear in few releases.
This release contains many bug fixes and performance improvements.
Polish is now an official language of Tryton.

Of course, migration from previous series is fully supported.

Major changes for the user

• The tabs in list view can now have a counter showing to the user the number of records under them. The feature is activated by default on tabs where the number should tend to zero thus providing some hint to the user about pending tasks.

• When creating a new record from the drop down menu of a relation, the form will have the value entered in the field as default value. This helps the user fill the form.

• The buttons can now be configured to be clicked by a number of different users before being triggered. The user can see on the button how many clicks it already received and on the tooltip who clicked.

• With the recent Neso retirement the database management from the client has been removed. This improve the security of the system by removing a potential attack vector.

• It is now possible to define for each record a different color on the calendar view. This allow to group records visually.

• The icons of the relation field has been improved. The experiences have shown that the old version had drawbacks which confused some users. The result was that some users thought they were searching for a new record while actually they were editing it.

As a result the editing button has now been put in on the left and a new button to clear the current value has been put on the right of the field.

The web client completes its sets of functionalities in order to be closer to desktop client. The new features implemented in this release are:

• The CSV Import/Export.

• The calendar view based on the FullCalendar.

• Support for translated fields.

• The Favorites menu.

• The date picker is now locale aware.

• Add support for column sorting.

• Support for confirm attribute on the buttons.

Accounting

• A comparison amount has been added on Balance Sheet and Income Statement, allowing the amounts to be compared with different date, fiscal year or periods.

• The second currency of account is now enforced, closing the gap between the documentation and the code. Thus it is possible to compute the balance of such accounts in the account currency.

• The creation of a tax can be quite complex. To ease the process, a testing wizard has been added allowing to see the result of the computation in order to validate the definition of the tax.

Invoicing

• The payment term is no longer required. An invoice without payment term will create a single due line at the invoice date.

• By default, the invoice reports are stored in the database when the invoice is posted to ensure the immutability of the document. But on large setup with a lot of invoices, the database becomes very huge and this can generate on overload and a waste of space for the backups. So a new configuration option has been added to store the invoice reports in the file store instead of the database.
  The option can be activated on existing databases. If the report is not found in the file store, the system will take the value found in the database as fallback.

• The process to post invoices has been reviewed in order to have better performance when posting a large number of invoices.

• The tax identifier of the company is stored on the invoice. This is useful when company has more than one identifier registered. By default, the system will take the first one.

Payments

• A new group for Payment Approval has been added in order to have finer grained access to the functionalities.

• The amount to pay of the invoice is now decreased by the amount of the related payments.

• It is now possible to block the payment of a line.

• It is possible to configure the module to always use the RCUR option for a SEPA mandate, as this is allowed by the European Payment Council since November 2016.

• A statement line for an existing payment will mark the latter as succeeded or failed depending on the sign when the statement is validated. This ease the management of the payment state as some banks credit the bank account first and later if the payment fails, they debit it.

• The statement line can also refer to payment group instead of individual payment. This is useful when the bank statement contains only one operation.

Analytic

• Many redundant fields with the account lines have been removed on the line.
  This simplifies the encoding and avoids mistakes.

• A new type of analytic account has been introduced for distribution.
  The analytic lines will be divided when used with such account into many lines accordingly to the distribution ratio defined per sub-accounts.

• The move line has now an analytic state which defines if the amount of the line is correctly set in each analytic axis/roots. This applies by default only on income lines. A menu entry allow to search for all lines that needs analytic correction.

• The analytic chart enforces now the company consistency. It is no longer possible to attach an account to an axis of a different company.

• The supplier invoice for a depreciable asset does not create analytic lines on posting. Indeed the analytic lines creation is postponed to depreciation moves.

Party

• A more generic address design has been added. It supports as many lines as needed for the streets instead of the previous limitation of two lines. Also the formatting of the address can be configured per country and language. The formats for about 65 countries are preconfigured.

• A common problem with referential data like party is the duplication. It is common that the same party ended to be created twice in the system. For such issue, Tryton has now a wizard that allow to merge one party into another. The merged party is inactivated to prevent new usage and the remaining one inherits from all the documents. For example, the receivable amount will contain the sum of both parties.

• SEPA Creditor identifier is now validated and unified into the party identifiers.

• Phone numbers are automatically formatted now using the phonenumbers library.

Product

• A new relate from products to variants has been added in order to ease the navigation between them.

Purchase

• As the payment term is no longer required on the invoice, the same applies also to the purchase.

Request

• It is now possible to create a purchase request without product. In such case, a description is required and will be used for the creation of the purchase line.

• When converting request into purchase, the requests containing the same product with the same unit will be merged into the same purchase line. This simplifies the purchase order.

Requisition

A new module for managing purchase requisitions has been added. It allows users to create their purchase requisitions which will be approved or rejected by a member of the Approval group. On approval, purchase requests will be created.

Sale

• As the payment term is no longer required on the invoice, the same applies also to the sale.

Stock

• A lead time can be configured for internal shipments between warehouses. In such case the internal shipment uses a transit location during the time between the shipping and the reception.

• A relate has been added to the location to show lots and their quantities inside the location.

• The default location defined on the product is used in the output of production. This unifies the behaviour of this feature with incoming shipments.

• The supply period of a supplier is configurable now. Before it was always 1 day.

Package Shipping

A new set of modules has been published. They provide integration with shipping services for printing labels and store shipping references per packages of shipments.

Two services are currently supported UPS and DPD.

Carrier

• It is possible to restrict the usage of carriers per country of origin and destination. Other criteria can be easily added. The carrier selection is already enforced by default on sales.

Timesheet

• A Web-Extension named Chronos has been published. It allows to quickly encode timesheet entries using the new user application API (see below). The application supports to work offline and synchronises when the user is back online.

It will be available soon on the different browser markets.

• It is now possible to define a start and an end date for the employees. In such case, they will not be allowed to encode timesheet outside the period.

• The work has be simplified by removing the tree structure. It was considered redundant with the tree structure of the projects.

Project

• The timesheet works are created automatically from the project form. This simplifies the management of projects.

Production

• Thanks to the new lead time per BoM and routing, start dates can be computed for productions. This allows to have a better schedule of the production needs for long running productions.

Following the work on previous versions, the production area has received two
new modules to extend its functionalities:

Work Timesheet

It allows to track the time spent per production work.

Split

Similar to the stock_split module, this module allows to split a production into several units.

Major changes for the developer

• The desktop client support GTK-3 thanks to the pygtkcompat module. The support is still experimental and can be tested by setting GTK_VERSION=3 in the environment. The plan is to switch completely to GTK-3 in one year.

• The server provides now a way to connect URL rules to a callable endpoint. This feature comes with a set of wrappers to simplify the work of the developer like instantiating the pool of the database name found in the URL or start the transaction with automatic retry on operational error. But the more interesting wrapper is the user_application which allows to authenticate a user with a key for a specific sets of endpoints. This feature allows to create applications that do not need to login on each use.
  Chronos is an example of such application.

• The translations now support derivative languages. Most of the main language has been renamed without their country code. This allowed the merge of all the Latin American Spanish translations under one common language deriving from Spanish.

• It is now possible to configure Binary fields to store the data in file store by setting the attribute file_id to the name of the char column which will contain the file store identifier.

• A new level of access rights has been added targeting the buttons. It allows to define how many different users must click on the button to actually trigger it.

• It is possible to configure a different cache than the MemoryCache. It just needs to define the fully qualified name of an alternative class in the cache configuration section.

• A new widget has been implemented in the clients for the Char field that stores PYSON expression. The widget displays a human readable representation of the expression and uses an evaluated dump of the expression as internal value.

• The read-only states for the fields xxx2Many is now limited only to the addition and suppression of records. The target records must manage themselves the read-only state for edition. This behavior allows for example to still edit the note field of a line of a validated sale while other fields are read-only.

• To speed up the tests and especially the scenario, a new option has been added that allows to store clean dumps of database (per module installed). A dump will automatically be loaded instead of creating a new database, this operation is way faster. Of course, the developer is responsible for clearing the cache when the database schema definition has been modified.

• A new mixin has been added to generalize the common pattern of ordering record with a sequence field. It is named sequence_ordered and can be customized with the name and the label of the sequence field, the default order and if null first must be used.

Authentication

The login process has been reworked to be very customizable. It is now possible to plug any authentication factors without the need to adapt the clients.

SMS

The authentication_sms module allows to send by SMS a code to the mobile phone of the user that he will have to enter to proceed with the login.

Web

The module web_user is the first of a new set of module which aims to provide facilities to developers who want to use Tryton as backend for web development.