# Tryton Release 4.0 **URL:** https://discuss.tryton.org/t/tryton-release-4-0/5926 **Category:** News **Created:** [May 2, 2016, 4:00pm UTC](https://discuss.tryton.org/t/tryton-release-4-0/5926 "2016-05-02T16:00:00Z") **Posts on this page:** 1 **Page:** 1
### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced) #### Post date: [May 2, 2016, 4:00pm UTC](https://discuss.tryton.org/t/tryton-release-4-0/5926/1 "2016-05-02T16:00:00Z")
We are proud to announce the 4.0 release of [Tryton](http://www.tryton.org/). This is the first release of Tryton that adds support for Python 3. The server and most of the modules support it. The missing modules are mainly the ones using the WebDAV and LDAP. The client will be ported once GTK-3 support is added. The release sees also a large refactoring of the protocol stack which was previously based on the `SimpleHTTPServer` of Python. Now it uses a [WSGI](https://en.wikipedia.org/wiki/Wsgi) application running on the [Werkzeug](http://werkzeug.pocoo.org/) server by default. Any WSGI server can be used to run Tryton, this removes the design constraint of single threaded process and opens the way for using workers. All modules have been reviewed to enforce the naming convention about the document identification. The name “code” is used for all referential documents like parties, product. The name “number” is used for the internal identification of all operational documents like sales, purchases, invoices etc. And finally, the name “reference” is used for identifications from external systems like the sale order number of the supplier of your purchase. Two new languages are now available on default installation the Lao and the Simplified Chinese. As [Richard Stallman reminded to us](https://www.gnu.org/philosophy/when-free-depends-on-nonfree), _the migration from previous series is fully supported_. ## Major changes for the user - The new _note_ functionality handles the management system for general textual notes on any arbitrary model in Tryton. On click it opens a notes dialog, where the user can maintain notes. The read state of every note is managed per user. Like the attachments, the icon in the tool-bar visualizes when there are notes on a model. ![Tryton note](https://discuss-cdn.tryton.org/uploads/default/original/2X/5/574bdb347648f777c2d12053ca95bdacf491dffe.png) ![Sao note](https://discuss-cdn.tryton.org/uploads/default/original/2X/c/c86f5997d89a96251ccd3a46b4ca921bf15aa845.png) - The CSV import and export has been highly reworked for a better experience. The import dialog now supports drag and drop to order the selected columns like the CSV export wizard. Both wizards are able to use any of the encodings available in Python. It is now possible to configure the CSV parameters for the export result. ![Export CSV](https://discuss-cdn.tryton.org/uploads/default/original/2X/b/b0bd6a1a758dd1df91b71d99429cd696f88d2538.png) - The charts provided by the graph view have been improved. Now they use softer colors, thinner lines and smaller arcs. On the background, dash style is used instead normal line for axis representation. A smart transparency value is applied for filling lines to always show through it. - A new button in the scheduler allows running a job once, useful to run jobs on demand or to test new settings. ### Accounting - The report design of the General Ledger, Trial Balance and Aged Balance has been re-worked. They are now based on the new dynamic views. This provides a performance burst and allows to filter the records more precisely. In addition to the previous printable output, they also gain the CSV export which is useful to perform specific operations in a spreadsheet application. ![General Ledger](https://discuss-cdn.tryton.org/uploads/default/original/2X/3/3a94c6912f6be08b1ea6f358ec030644783864f2.gif) - A _date_ field is added to the _Aged Balance_, to modify the date on which the calculations are based. With this feature, it is possible to generate reports based on a past date as if it would have been generated by ignoring reconciliation that happened after that date. - The functionality of _Third Party Balance_ is merged into the _Aged Balance_. We found that the _Third Party Balance_ computed the same data as the _Aged Balance_ with the type _Customers and Suppliers_. ### Party - The _Name_ field on party is no longer required for input. This solves a long standing request to be able to maintain parties where the name is not known on creation. ### Product - A configuration form is added to the product module with these options: - It was not always easy to explain the design of products with the templates, especially when it was not really relevant for the current business. So we have redesigned both views to be very similar and indeed they use the exact same design. The fields, that do not exist on the product, are automatically replaced by the value of the template. ![Product](https://discuss-cdn.tryton.org/uploads/default/original/2X/7/78b14306eda79737009a6740daaa396fb857f03a.png) ![Variant](https://discuss-cdn.tryton.org/uploads/default/original/2X/c/c68e11609f7130c6f6b518ad34f4f578b40b4f60.png) - The field _Category_ is replaced by a _Categories_ field, to support the ability of adding many categories to one product. This is very useful for example to create multi-axis categories for web shop. #### Classification This new module defines the reference basis to create different kinds of classifications for products. It adds a generic field _Classification_ on the product form. #### Classification Taxonomic This new module introduces the taxonomic classification of products as an example using the new Classification module. It includes classifications by [Taxon](http://en.wikipedia.org/wiki/Taxon) and by [Cultivar](http://en.wikipedia.org/wiki/Cultivar). ### Purchase - The field _Delivery Time_ on product supplier is replaced by _Lead Time_ which increases the precision from days to microseconds. - For each warehouse, it is now possible to define the location where the goods are picked in case of supplier return. If this location is not defined, the default storage will be used. #### Request The purchase request functionalities have been decoupled from `stock_supply` and `sale_supply` modules into a new separate module named `purchase_request`. This is to prepare future work that will use only purchase requests without the need of other `stock_supply` features. - A new state _Exception_ is added to the purchase request. This is useful to manage cancelled purchase when linked to drop shipments. ### Sale - The field _Delivery Date_ on model _Sale Line_ is renamed into _Shipping Date_ to avoid any confusion. - The field _Delivery Time_ on product form is replaced by _Lead Time_ which increases the precision from days to microseconds. - The custom _history_ management on _Sale Opportunity_ is replaced by the general revision functionality of the client. This increases its precision and works automatically for any new fields. ### Stock - The address of the destination warehouse of the _Internal Shipment_ is now displayed on the report. - Now it is possible to manually do a move with the new _Do_ button. This is useful for example to get correct accounting when you have long living productions. - Supplier return shipments now have a supplier and a delivery address fields. Those fields will be automatically populated for shipments created from purchase. ### Production #### Routing This new module defines the routings, steps and operations for productions. A routing is a list of ordered steps and each step is defined by a generic operation. #### Work This new module completes the routing module by creating the _Works_ of a production based on its routing. A _Work_ is linked to a _Work Center_ which defines the cost using one of these two methods: _Per Cycle_ or _Per Hour_. The cost of a work is computed using the _Cycles_ created on it and later added to the global cost of the production. ## Major changes for the developer - The domains are now accepting a new `parent_of` operator which recursively returns all the records that are parents of the searched records. This is the opposite of the existing `child_of` operator. - It is now possible to inherit from a view that already inherits another view from a different model. - The new _where_ domain operator is useful when you need to search on a `xxx2Many` with a full sub-domain instead of separated clauses. It has the advantage to avoid to fetch an intermediary result by using a sub-query. - The _Transaction_ design has been reworked to be closer to the design defined by the [PEP-0249](https://www.python.org/dev/peps/pep-0249/). This new design allows to support nested transactions. It also supports multiple cursors for the same transaction, reducing the memory consumption when iterating over large result sets. - A new context model is introduced, to save the trouble of writing simple wizards for configuring reports by setting some values in the context. With this new design, the developer can define a model for which each field will define the values of the context. The form of this model will be displayed on top of the view and the view will be automatically reloaded when the context is changed. - Now its possible to have reports in plain, XML, HTML and XHTML reports. With this change the report infrastructure can be reused for example to design email templates. - This release adds support for the [Two-Phase commit protocol](https://en.wikipedia.org/wiki/Two-phase_commit_protocol) which allows to coordinate distributed transactions. By default, Tryton uses a single transaction from the database back-end. But when Tryton has to communicate with other systems, it is good to use TPC to keep data integrity. The implementation follows the API of the Zope [Data Manager](https://zodb.readthedocs.org/en/latest/transactions.html#data-managers). The data managers of the Zope community can be used within Tryton. - Thanks to the two-phase commit protocol now mails can be sent when the transaction is committed, so if something goes wrong and the transaction is rolled back no mails are sent. ### Accounting - The reconciliation process now stores the date of the reconciliation. By default, it is the highest date of the reconciled lines. This allows to filter reconciled lines based on this date, for example to generate a report with the unreconciled lines before a specific date. - The _Credit Notes_ have been merged into the _Invoices_. They are now standard invoices with negative quantities. This allows to easily group both types into a single document. The numbering can still be differentiated depending on the sign of the lines. ### Product - `Uom.round` is now an instance method which makes more sense according to its signature. ### Purchase - The _Purchase_ has received a `done` transition like the _Sale_ to allow extensions to perform some action when this transition is performed. - It is now possible to search _Purchase Requests_ using the _Purchase_ field. ### WebDAV WebDAV has been decoupled from `trytond` into a separate module which improves the modularity of the system. Indeed many setups do not use the WebDAV so it was a little bit bloated to have it into the base. Also dependencies of this module prevented to add the support of Python 3 to `trytond`. So, for now, the WebDAV protocol is managed by a separated process but it will probably return [in the future](https://discuss.tryton.org/t/migration-to-wsgidav/73) into the main process.