Translation Release for series 4.8

Publicado: 2018-05-21 18:00:00+00:00 release

Due to a mistake in the process of generating the translations, the initial release of series 4.8 contained some unstranslated strings. We decided to make new set of releases with the correct translations even if it breaks the rule of no database updates for bug fix releases.

If you have already updated your server to the series 4.8, you need to also update the database for this bug fix release. Sorry for the inconvenient.

This release additionaly includes the Spanish Chart of Accounts which has cleaner design and is now available for the 4.8 series.

New Tryton release 4.8

Publicado: 2018-04-23 18:00:00+00:00 release

We are proud to announce the 4.8 release of Tryton. This is the last release that will support Python2, as decided on the last Tryton Unconference, next versions will be only Python3 compatible.

In this way we introduced a new way of dynamic reporting. For now it's only available on sale module, but the plan is to extend it to more modules in newer releases. The effort to make all the Desktop client features available on the Web client has continued on this release. This resulted in fixing many small details and adding some missing features on the web client. Of course this release also includes many bug fixes and performance improvements. We added Persian as an official language for Tryton.

As usual the migration from previous series is fully supported. Some manual operation may be required, see migration from 4.6 to 4.8.

Major changes for the user

  • The clients show a toggle button next to the search input for all models that can be deactivated. This allows the user to search for deactivated records and to know that the model is deactivable.
Sao list with inactive records option
  • Until now, when changes on a record from a pop-up window were cancelled, the client resets it using the stored value from the server or deletes it if it was not yet stored. Now, the clients will restore the record to the state it had before opening the pop-up, which is a more expected behaviour for the user.
  • It's no longer possible to expand a node that has too much records. This is needed to prevent to consume all the resources of the client. In such case the client will switch to the form view where normally the children will be displayed in a list view which supports loading records on the fly when scrolling.
  • To help companies to be compliant with the right to erasure from the GDPR, a new wizard to erase a party has been developed. It erases personal information linked to the party like the name, addresses, contact mechanisms etc. It removes also those data from the history tables. Each module adds checks to prevent erasure if pending documents for the party still exist.
  • A name has been added to the contact mechanism. It can be used for example to indicate the name of the recipient of an email address or to distinguish between the phone number of reception, accounting and warehouse.
  • The default search on party will now also use contact mechanism values.
  • Similar to the design of the addresses which can be flagged for invoice or delivery usage, the contact mechanism received the same feature. So the code may now request a contact mechanism of a specific type. For example, it is now possible to define which email address of a party should be used to send the invoices.
  • All the matching criteria against product categories have been unified between all the modules. Any product category will match against itself or any parent category. This is the chosen behavior because it is the least astonishing.


  • The desktop client already has mnemonic for all button but now they are also added to all field labels. This allow to jump quickly to any visible field by pressing ALT + <the underlined key>.
Tryton form with mnemonic
  • The desktop client has a new option to check if a new bug fix version has been published. It takes care of the notification on Windows and MacOS.
Tryton with the notification of a new version available
  • The Many2One fields in editable tree now show the icons to open the related record or clear the selection. This unifies the behaviour with the form view.
Tryton with Many2One icons on editable tree


  • Numeric values are now formatted with the user locale and use an input of type 'number' for editing. This allows to have the right virtual keyboard on mobile devices.
  • The web client finally receives the label that positions the selected record in the list and shows the number of records in the list.
Sao toolbar with selected record label
  • The spell checking is now activated by the browser, so fields with the spell attribute defined will have spell checking activated.
  • The buttons of widgets are now skipped from tab navigation in the web client. The actions of those buttons are available via keyboard shortcuts.
  • The management of editable list/tree has been completely reworked. Now the full row becomes editable on the first click. The focus is kept on the line if it is not valid. The editing is stopped when the user clicks anywhere outside the view.
  • The sum list feature has been implemented in sao.
Sao sum of move's credit and debit
  • The same shortcuts of the Date and DateTime widgets available on tryton can now be used on web client.
  • Many2One fields are displayed on tree view as clickable link which opens the related record form view to allow quick edition.

We have pushed many small improvements which fix small jump of elements of the page:


  • The general ledger accounts are now opened from the Income Statement rows. This allows to see the details of the computed amounts.
  • It happens that users need to customize the configuration of the chart of account that comes from a template. Until now, this would prevent any further update without loosing this customization. Now, the records that are synchronized with a template are read-only by default. A check box allows to edit the value and thus remove the record from the update process.
  • Users may create a second chart of account by mistake. There are very rare cases when such creation is valid. As it is a complex task to correct such mistake, we added a warning when creating a second chart of account.
  • Now an error is raised when closing a period if there are still asset lines running for it.
  • Until now, only one tax code was allowed per tax. This was too restrictive. For some country it was needed to create null children taxes to allow more complex reporting. Now, tax codes are no longer defined on the tax but instead they contain a list of tax lines. Those lines can define the base or the tax amount. On the report, the lines of each tax code are summed per period. All chart of accounts have been updated to follow this design.

Tax report on cash basis

The new account_tax_cash module allows to report taxes based on cash. The groups of taxes to report on cash basis are defined on the Fiscal Year or Period. But they can also be defined on the invoices per supplier.

The implementation of this new module also improved existing modules. The tax lines of closed period are verified against modification. The registration of payment on the invoice is limited to the amount of the invoice.

Spanish chart of account

The module, which was published for the first time in the last series 4.6, needs a deep cleaning. The last changes in the accounting modules raised concerns about choices made for this chart. So it was decided to temporary exclude the module from the release process and to not guarantee a migration path. The work to fix the module has started and we expect to be able to release a fixed version soon.


  • The description on invoice line is now optional. If a product is set the invoice report will show the product name instead of the line description.
  • The reconciliation date is now shown on the invoice instead of the Boolean reconciled. This provides more information for a single field.
  • The Move lines now show which invoice they pay.
  • An error is raised when trying to overpay an invoice.


A cron task has been added that will post automatically the clearing moves after a delay. The delay is configured on the payment journal.

Stripe Payments

  • If the customer disputes the payment, a dispute status will be update on the Tryton payment. When the dispute is closed, the payment is updated according if the company wins or loses.
  • Some missing charge events has been added. In particular, the refund event which may update the payment amount when it is partial.



This new module adds the automatic import of OFX file as statement. The OFX format is a common format which is supported in various countries, like the United States.


  • The stock quantity was only computed per product because it is the column stored in the stock move. But it may be useful for some cases to compute the stock quantity per template. Indeed products from the same template share the same default unit of measure so their quantities can be summed. This release adds on the products_by_location method the possibility to group by product columns like the template, but also a relate action from the template which show quantity per locations.
  • When there is a very large number of locations, the tree Locations Quantity becomes difficult to use. Especially if you are searching in which location a product is. So we added the option to open this view as a list, this way it is possible to search location by quantity of the product.
List of locations with product stock
  • We found that there are two different expectation from users about the default behavior of the inventory when the quantity is not explicitly set. Some expect that the product quantity should be considered as 0. And others expect that the product quantity is not changed. So we added an option on the inventory to choose the behavior when an inventory line has no quantity.
  • Until now, the assignation process for supplier return shipment was not using children location but this did not work if the location was a view. Now we assign using the children if the location is a view.
  • The supplier shipment support to receive the goods directly in the storage location. This way the inventory step is skipped.


  • Until now, only sub-projects having the same party were invoiced. Now an invoice for each different party will be created.


  • The description on sale line is now optional. This prevents to copy the product name to sale description as it is now shown on the sale report.
  • In case a different product is shipped to the customer if the invoice method is based on shipment, this shipped product will be used for the invoice. Previously only the initially sold product was always used.
  • Now it is possible to edit the header fields thanks to the new Wizard which takes care of recompute the lines according to the changes.
Sale with modify wizard running
  • Reports on aggregated data has been added to the sale module. The report engine allows to browse the Revenue and Number of sale per:

    • Customer
    • Product
    • Category
    • Country > Subdivision

    Those data are over Period, Company and Warehouse. The reports also show a sparkline for the revenue trend which can be drilled down.

Sales per customer with sparklines Sale revenue per customer graph
  • The sale with the shipment method On Invoice Paid will create the purchase requests and/or drop shipments when the lines are fully paid. Before they were created directly on validation.
  • The shipment cost is not more computed when returning goods.


This new module allows to create coupons that are used to apply a promotion on the sale. The coupon can be configured to be usable only a specific number of times globally or per party.


  • The product supplier can be used now on the purchase line. This allows to display the supplier definition of this product.
  • Now it is possible to edit the header fields thanks to the new Wizard which takes care of recompute the lines according to the changes.
  • The description on purchase line is now optional. This prevents to copy the product name to purchase description as it now shown on the purchase report. The same change have been applied on purchase requests and requisitions.
  • In case a different product is received from the supplier if the invoice method is based on shipment the received product will be used on the invoice. Previously the purchased product was always used.
  • The user is warned if he tries to confirm a purchase order for a different warehouse than the warehouse of the linked purchase request.

Purchase request quotation

  • This new module allows to manage requests for quotation to different suppliers. Each request will collect quotation information from the supplier. The preferred quotation will be used to create the purchase.


  • Now it is possible to filter which type of email to use for sending the notification.
  • The email notification skip the recipients if the target field is empty. For example if a notification is defined on the Invoice with the Party as recipient and the Party has not an email address, then the invoice will not be sent. Adding a fallback recipients the email is sent to specific user email which could be a secretary which will be in charge of sending it or a mailbox for a printer which will print it automatically etc.


The following modules have received tooltips:

  • account_credit_limit
  • account_dunning
  • carrier
  • carrier_weight
  • currency
  • product_attribute

Major changes for the developer

  • Starting from this release the tryton client will only support the version 3 of GTK+-3. This will allow to migrate it to Python3.
  • The group widget can be defined as expandable by adding the attribute expandable. If the value is 1, it starts expanded and if the value is 0, it starts unexpanded. Both clients support it.
  • To ensure that all buttons may have their access rights configured a new test has been added. We added also the string, help and confirm attributes to ir.model.button. So they can be shared between different views.
  • The monetary format is now defined on the language instead of the language. According to User Experience best practices the amount should be displayed in the user language format event if it's a foreign currency.
  • It's now possible to manually define an exceptional parent of a language. This allows to use a custom monetary format for each country of the Latin American language.
  • Dict fields are now stored using it's canonical representation. This allows to make equity comparison between them.
  • The language formatting has been simplified to expose the instance methods: format, currency and strftime. A classmethod get is added to return the language instance of the code or the transaction language.
  • The previous API for session management was based on the ORM methods. This makes more complicated to implement alternative session manager. We created a simplified API agnostic to the ORM: new, remove, check and reset.
  • If the database has the required features (for PostgreSQL: the unaccent function), the ilike search will be performed on unaccented strings per default on all Char. This can be deactivated by setting the attribute Char.search_unaccented to False.
  • We have added the support for EXCLUDE constraints. An EXCLUDE constraint is a kind of extension to the UNIQUE constraint which can be applied on a subset of the rows and on expression instead of only columns. For more information, please read the EXCLUDE documentation of PostgreSQL.
  • It is now possible for a module to register classes to the pool only if a specified sets of modules is activated. This replaces the previous silent skip. Existing modules that were relying on the old behaviour must be updated to use the depends keyword otherwise they will crash at start up.
  • Sometimes a module depends optionally on another but it may need to fill from the XML record a value for a field that is defined on the optional module. We added a depends keyword on the field which ignores it if the list of modules is not activated.
  • The clients now support the definition of a specific order and context when searching from a field like Many2One, Reference, One2Many etc. This is useful to have preferred record on top of the list of found records.
  • A new mixin has been added to add logical suppression to a Model. But also we ensure that the client is aware that the model is deactivable. All the modules have been updated to use this new mixin.
  • The context model name is now available on the screen context. This allows for example to change the behaviour of a wizard depending on the context model.
  • Tryton prevents by default to modify records that are part of the setup (which are created by XML file in the modules). This requires to make a query on the ModelData table on each modification or deletion. But usually only a few models have such records, so we now put in memory the list of models that should be checked. This allows to skip the query for most of the models and thus save some queries.
  • Buttons can be defined with PYSON expressions for the invisible or readonly attributes. Some times, the developer wants to be sure that the field used in the PYSON expressions are read by the client. A depends attributes have been added which ensure that the listed fields will be included in all the view where the button is displayed.
  • The administrator can now reset the password of the user with a simple click. The server will generate a random reset password which is available for 1 day by default and send it by email to the user. This reset password is only valid until the user has set a new password. It is also possible to reset this way the admin password using the trytond-admin command line tool.
  • The context has a new optional key _request which contains some information like the remote address, the HTTP host etc. Those values are correctly setup if the server run behind a proxy which set the X-Forwarded headers.
  • A malicious hacker could flood the LoginAttempt table by sending failing request for different logins. Even if the size of the record is limited and the records are purged frequently. The server now limits also the number of attempt per IP network. The size of the network can be configured for each version (IPv4 and IPv6). This are only the last level of protection, it is still recommended to use a proxy and to set up IDS.
  • The name attribute of the tag image can now be a field. In this case, it will display the icon from the value of the field.
  • Now it is possible to extend with the same Mixin all the existing pool objects that are subclasses of a target. An usage example is to extend the Report.convert method of all existing reports to add support for another engine.
  • We have decided to remove the MySQL backend from the core of Tryton. The back-end was not tested on our continuous integration server and so it has many failures like not supporting Python3. The current code has been move to its own repository. This module will not be part of the release process until some volunteer make it green on the test server.
  • The current form buttons are automatically added to the toolbar under the action menu for fast access. Now the developer can define under which toolbar menu the button will appear.
  • Tryton now uses LibreOffice instead of unoconv for converting between report formats. There were some issues with unoconv, which where fixed by using libreoffice directly. Now we publish also docker images with the suffix -office which contains all the requirements for the report conversion.
  • A new Currency.currency_rate_sql method has been added which returns a SQL query that produces for each currency the rate, start_date and end_date. This is useful to get a currency rate in a larger SQL query. This method uses the window functions if available on the database back-end to produce optimized query.
  • Since the introduction of context management in proteus, the client library, the context management was taken from different places in an inconsistent way. We changed the library to always use the context and configuration at the time the instance was created. Some testing scenario may need some adjustment as they could rely on the previous behavior.


  • The previous API to reconcile lines allowed only to create one reconciliation at a time. But as this can trigger the processing of the invoice for example, it can be a bottleneck if you are reconciling a lot of different lines like a statement can do. So the API has been improved in the most backward compatible way to allow to create many reconciliation at once.
  • The invoice now has a method to add and remove payments which should always be used.


  • The limit of authentication request per per network is also applied to the web users.
  • Thanks to the implementation of the exclude constraint, the uniqueness of the email of web user only applies to the active users.

New Tryton release 4.6

Publicado: 2017-10-30 18:00:00+00:00 release

We are proud to announce the 4.6 release of Tryton.

This release is enhanced by the addition of 9 new modules covering many different topics. There has been also an effort in improving the graphical user interface and the user experience by fixing many small details. It is also good to note the inclusion of the Spanish charts of accounts which required some improvements in the standard accounting modules. Of course it includes many bug fixes and performance improvements.

As usual the migration from previous series is fully supported. Some manual operation may be required, see migration from 4.4 to 4.6.

Major changes for the user

  • In addition to the user name, company and currency in the title of the clients, we have added the profile or the login details. This way, the user can find faster the right windows.

  • The order of the toolbar has been reworked to have a more logical order and grouping. The same logical has been applied also on the toolbars of the widgets.

    Tryton toolbar order
  • On previous version, the headers of the column were always centered. Now they use the same alignment as the content following the best practice. Texts columns aligned on left and numerical columns on right. Also to improve the discoverability, editable lists have a grid design instead of just stripped row. This allows the user to know directly if it is editable.

  • Similar to the redesign of the button on relation field in the release 4.2, this release improves the design of the Binary and Image widget. Only the available buttons are shown instead of being disabled. But also before having the option to upload a new file, the previous file must be cleared. This prevents confusion to some users.

    Sao non-editable list Sao editable list


  • Under GTK+-3, a default theme has been added for read-only, required and invalid entries.
  • Also under GTK+-3, it is possible to add in the configuration folder a file theme.css which will be loaded as user theme. We have added Tryton's specific selectors: .readonly, .required, .invalid and .window.profile-<name>. The last one is useful to setup a different style to the windows depending of the profile.


  • The web client has now the same keyboard shortcuts as the desktop client. You can see them with ctrl+h. This make is simple to use without mouse.


  • A new wizard has been added to renew the fiscal year. It takes the previous fiscal year and some other parameters to create the new fiscal year automatically. The sequences can be reset automatically and the same number of periods are created.

    Sao renew fiscal year
  • On some countries, it is required to add a legal notice when some taxes are applied. This legal notice can now be configured on the tax to be included automatically and so avoid mistakes or oversights.

  • The tax rule system is the way Tryton configure the taxes to apply on an invoice for a party. This works by replacing the default tax by the one defined on the matching rule. Now it is possible to configure the rule to keep the default tax and add the rule one. It is needed to support tax mechanism from some countries like the equivalence surcharge for Spanish VAT.

  • The tax description which appear on the invoice is now translatable.

  • The payable and receivable accounts on party are no more required. This prevented the creation of parties when no default values was setup even if the values were not needed. Now, a message will be raised only when the value is needed for a particular operation.

  • It is now possible to search the amounts of the general legder. It is useful for example to get only the accounts with a balance.

  • The general ledger and the income statement can be computed for a range of date in addition to the sets of periods.

  • The configuration wizard allows to configure default receivable and payable accounts for categories and products.


This is a new module that aims to implement common accounting requirements in Europe. The first common feature added is the EC sales list.


A new module registers two default charts of account and taxes for Spain:

  • Plan General Contable Español 2008
  • Plan Contable para PYMES 2008


  • The tax identifier of the party invoiced is stored on the invoice. By default it is the first tax identifier of the party that is chosen but it can be changed. This is useful for tax reporting and when a party has many tax identifiers.
  • The Belgian chart of accounts has been adapted to configure the taxes for the EC sales list.


  • The clearing of payments only worked when paying a specific line. Now it can also work if an account is defined instead of a line. The common case is when you register a deposit for which you have no line but still want to register it once the payment is succeeded.

  • The manage of payment with Stripe received many improvements:

    • The user can now create manually Stripe payments. Usage showed that it may be needed and there was indeed no technical reason to prevent.
    • It is possible to select the specific Source of the Customer.
    • It is now possible to enter an existing Customer by filling its ID.
    • Tryton supports now the two steps payment flows. It is just checkbox to uncheck to activate on this flow. The amount can be changed between the authorisation and the capture and the capture is just triggered by a button.


  • When a statement is cancelled, if the generated move lines were reconciled, they are now automatically unreconciled. This ease the task of correcting a statement as it is no more a task to do for the user.


This new module adds the automatic import of CODA file as statement. The CODA format is a standard from the Belgian Financial Sector Federation which is supported by most of the Belgian banks.


This new module allows to define for a dunning procedure level to send an email to the party. The template of the email can be different at each level. The action of sending an email is logged into the system.


  • It is possible to restrict a location to have only one level of children. This allows to apply some techniques to improve the performance of the stock quantity computation and to support chaotic storage which requires to have a huge number of locations.
  • In addition to the wizard to split stock move, there is now a wizard to split a shipment. It asks for the moves to be sent to the new shipment. This is useful if the default order can be too big for the carrier.
  • There is a warning raised when a incoming or outgoing move is done without an origin. Until now, it was raised once for each move but with this release only one global warning is raised for all moves.
  • For the perpetual stock accounting, Tryton supports now the reversed drop shipment.
  • In order to register past move, the effective date of move can be set manually by the user.
  • In version 3.6, we added a new state 'staging' on move. But the constraint, that allows to delete only 'draft' or 'cancel' move, was not updated to allow also 'staging'. This is now corrected with this release.
  • A check has been added in order to prevent the deactivation of a location if there are still products in it. This way the conservation of products is respected.


This new module allows to manage consignment stock from supplier in the company warehouse and at the customer warehouse. The corresponding invoices are created automatically when products are used from such location.


This new module allows to define some storage location as movable. They can be moved by an internal shipment. This can be used for example to manage palettes.


  • The Drag and Drop has been activated on the project and work views.


  • The backorder of supplier are no more planned. Before they were planned at the same date as the initial order. But indeed as the supplier has failed once, the best assumption is to not know when he will fulfill it.
  • The confirmed purchases are now automatically processed thanks to a cron task.


  • The backorder for customer are planned for today. Before they were planned at the original shipping date. But this date may be already in the past so it is better to try to fulfill it as soon as possible.
  • The confirmed sales are now automatically processed thanks to a cron task.
  • It is now possible to define a default invoice grouping and the default shipment grouping method for new party.
  • When the shipment cost is invoiced on order, it is now invoiced only when at least one shipment is done.
  • Consumable products are not checked anymore when the quantity check is activated on sale.


This new module allows to register payments on sale before the creation of any invoice. When the payments for full amount of the sale are authorized, the sale is automatically confirmed. For example, this module is used to manage payment from a e-commerce website.


This new module adds under and over shipment tolerance on the sale. If the quantity of a sale line is under shipped but inside the tolerance percentage, then the line will be considered as fully shipped and no back-order will be created. If the quantity of a sale line is over shipped more than the tolerance percentage, then a warning is raised.



This new module adds the generic feature to send email to parties or users of document based on trigger conditions. The email can embed as attachment any report of the document. A common usage for this module is to send automatically the invoice to the customer when it is posted.

Major changes for the developer

  • The server supports to have a JSON as column type instead of TEXT column. To active it, it just require to alter the column type after the database creation. This is useful if you plan to use JSON functions or operators on the column.
  • The SQLite backend receive the alter_type and alter_size feature. This is implemented by recreating the table with the right types and inserting the old tuples.
  • The report engine, thanks to last version of Relatorio, supports Flat OpenDocument. This is useful for development as the file can be easily inspected and reviewed. But of course as it is a format not wildly supported, the result is still a standard OpenDocument.
  • Report template can now be defined as working on a single record only. This means that when it is requested for a list of records, it generate a zip file which contains each report in a separated file. This is useful for report like invoice which must be archived as unique document.
  • A new method on get_email in allows to retrieve an email instance with the template rendered for a record. The email can be multilingual and if the template is in HTML a plain text is generated automatically.
  • The extension for plain text is now txt. This is better for guessing mimetype using the extension.
  • To improve the security the session randomness has been increased to 32 bytes.
  • The server enforces natively the size of the requests to avoid deny. The unauthenticated requests are limited to 2MB and the authenticated ones are limited to 2GB. Of course those values are configurable. Until now it was recommended to use a reverse proxy for this protection.
  • The WSGI application support more configurations (TRYTOND_LOGGING_CONFIG and TRYTOND_DATABASE_NAMES) from environment variables.
  • The changes in sequence management of the new PostgreSQL 10 showed that we should move the queries about sequence to the back-end to provide an API independent of the back-end.
  • Just like we have a descriptor on Selection field to retrieved the translated value, there is now a descriptor for the Reference field.
  • To be able to use the cache on our new drone for continuous integration, the tests infrastructure support the cache for remote PostgreSQL.
  • The XML loader was missing the possibility to evaluate datetime values.
  • Some methods can not be called with duplicated ids. But often the developer does not think about testing this requirement. In order to prevent this category of issues, all RPC calls are checked against unique ids. Also the ModelView.button and Workflow.transition have an assert against duplicate ids to detect wrong call at development stage but without having performance impact on production.
  • In order to support testing external back-end, they can register through entry points specific tests to the standard sets of tests.
  • A new generic test has been added to check that methods for Function fields are well defined on the Model.
  • The trytond-admin command has a new option --install-dependencies which allow to automatically install the missing dependencies when updating the database.
  • When updating module list, trytond-admin will also delete missing modules not activated.
  • The URI for SMTP supports two new parameters localhost_name and timeout.
  • The ModelView removes automatically empty pages from notebook.
  • The root user can behave as any company or employee.
  • The model and record name of Reference fields can be exported.
  • The sequence field can be set on proteus ModelList by using the new method 'set_sequence'.
  • As Python 3.3 has reach it end of life, we do not support it anymore, but we support the new Python 3.6.


  • The method Move.query_get, which generate the SQL clause from the context, handles now the from_date and to_date as date range.
  • The default value of the move line has been greatly simplified. This removes potential bugs due to the complexity. And most of the features are better managed with the template move.
  • The deposit amount on party now shows a positive amount when the party has deposit.
  • All the function fields based on the MissingFunction have been replaced by Python properties. The problem with MissingFunction was that it may be triggered for the wrong record because of the pre-computation design of Tryton. The property ensure to raise error only for the needed record.


  • The tax sequence is now used as default values for the invoice taxes sequence.


  • An origin field has ben added to the payment. This allows to link payment to specific model like the sale in the module sale_payment.
  • The support for Stripe webhooks has been added. Some events are handled by default: charge.succeeded, charge.failed, source.chargeable, source.failed and source.canceled but more can be added easily in custom module.


  • A generic wizard which is the common basis to import statement from a file has been added. It is already used by the account_statement_coda.
  • To allow to import statement line with partial data, a new model has been added. The origin shares most of the fields with the statement line but with minimal constraint. The origin serves as basis to create lines. It shows the amount still pending to convert into line.


  • The commission plan does not match any more line for empty product.


  • The service products are enforced to have only the fixed cost method.
  • The cost price has been moved from template to product. This allows a finer grain computation and still compute an average cost for the template.


  • The performance of the average cost price computation has been greatly improved. The new algorithm minimize the number of save and take advantage of the replacement of Property by MultiValue from the previous release.
  • The constraint that enforce move location to be child of the locations of the shipment has been relaxed to apply only shipment states on which the move can be corrected.


  • In order to easily customize the address to print on the purchase, a python property report_address has been added on purchase.
  • The required constraint on the origin of a request has been dropped. It follows the doctrine that Tryton has only constraint that are programmatically needed because it eases the customization.


  • In order to easily customize the address to print on the sale, a python property report_address has been added on sale.
  • The sale price can also be computed by the price list even if no customer is defined.
  • The shipment cost price is rounded using the precision of the field it is stored on instead of the currency.


  • As done in trytond, the web user session randomness has been increased to 32 bytes.
  • The email used to login is managed as case insensitive. This is the most common and expected behavior.

New Tryton release 4.4

Publicado: 2017-05-01 18:00:00+00:00 release

We are proud to announce the 4.4 release of Tryton.

This release see many work to make Tryton even more customizable by reusing or improving common design patterns of existing modules, but still continues to extend the features with new modules. There is also a good effort in improving the security of the application. It contains also many bug fixes and performance improvements.

This release see the removal of the set of DAV modules (webdav, calendar, party_vcarddav etc.). Those modules were based on the no more maintained PyWebDAV library and they did not support Python 3. The side effect is that now the full server stack is Python 3 compatible.

Of course the migration from previous series is fully supported. Some manual operation may be required, see migration from 4.2 to 4.4.

Major changes for the user

  • The URL entry that was set at the button of every tab has been replaced by a button on the toolbar. The button allow to display the URL and copy it to the clipboard. This allow to have more vertical space in the client for the lists and the forms.
  • A common need, when user customize the report template from the client, is to encode the new translations. This is now very easy thanks to the addition of two actions on the report to set and synchronize the translations. A new relate button allows to open the list of all translations linked to the report. The same feature is also available for the views.
  • The desktop client used until now the security model Trust On First Use. But today with the raise of service like Let's Encrypt, it is very easy and cheap to have a valid SSL certificate but such certificate are renewed very often. So it was no more practical to use TOFU model so the client now validate the certificate of the server using CA of the system or the one configured. The fingerprint of the server is still used as check to prevent to fallback to a plain HTTP connection.


  • The period and the fiscal year can be locked definitively. It was already possible to close them to prevent to post anything on them but it was always possible to re-open them. Some countries (like French) has a requirement to have a mechanism that can not be re-open. This is why we have added the lock.
  • The invoice sequences have been simplified. They now use a list of extensible criteria to choose which sequence to use for an invoice. This design is very flexible and allow to implement the country specific requirements very easily.
  • It is now possible to mark a supplier has having direct debit access. In this case its payable lines will not be shown in the list of lines to pay. This prevents to pay them by mistake while the supplier will issue a direct debit.
  • Often a company has only one payment journal. In this case now it will be directly filled in the payment wizard.
  • To ease the task of reviewing the account entries, the statements put the line number and description in respectively move and line description.
  • The analytic accounting has now a rule engine. It allows to apply rules when posting accounting moves without any analytics. The rules can be based on the account, the journal and the party, but of course as usual, those criteria can be easily extended.


This new module allow to correct the price of a posted invoice line. It adds a new wizard which allow the user to select the line to correct and create a new invoice with for each line two opposite ones. This way the user can change the price of the positive line and keep the statistics and the anglo-saxon accounting correct.


This new module adds the support of Stripe as receivable payment method. The module support many Stripe accounts, one per payment journal. It provides checkout method via browser form for payment or to register a party as Stripe customer. The processing of the payment is done asynchronously by a cron task.


  • It is now possible to use product category as criteria to match a commission plan.


  • The price list has now a new criteria based on the category. It matches products that are linked to the category (standard or accounting).


This new module adds a start and end date to the price list lines like that the price list change can be planned in advance. There is a relate from the price list to open the lines like that the user can use the filter.


  • A new producible checkbox is added to the product. This allow to restrict the product that can have a BOM.


  • The purchase price is now displayed on the product search list from the purchase line.
  • It is now possible to edit the delivery date of a purchase line. The computation from the supplier lead time is not always possible, but often the supplier can provide an accurate delivery date. So it is good for the supply planning to have a good accuracy of the planned deliver dates.
  • It is now possible to see the requests from which a purchase line was created. This gives more information to the purchaser in case he has to negotiate the quantity for example.


  • The sale price is now displayed on the product search list from the sale line. This allow the salesman to discuss the prices of similar product with the customer.
  • It is allowed now to leave the lead time of a product empty. There are cases where a company can not define a lead time for selling a product. Then the generated stock move will not have any planned date.


This new module defines the basics to support subscription of recurring services. And periodically invoice them based on consumption created recurrence rules.


This new module allows to manage advance payment on the sale. An advance payment term can be linked to a sale which will create advance invoices when it is processed. The payment of those advance payments can condition the execution of the supply and the shipping of the sale. The amount of each invoice is computed using a formula based the sale amount.


  • The shipments now record the employee responsible for some states. For example the employee who received the supplier shipment; the employee who picked and packed the customer shipment etc.
  • The internal shipment has now a request state. This allows to have similar design as for production by creating request long time in advance and recompute them as far as they stay in request state.
  • The customer shipment can have the same picking/storage location and output location. This allows to support more warehouse workflow. For example, using grouped internal shipment for the picking, this is often known as wave picking.
  • If an order point exists for a specific type (purchase, production etc.), this disable the other supply methods.
  • The internal shipments are now generated recursively because creating an internal shipment can generate a new need of another internal shipment. Now the generation is looping as long as it is needed.
  • All the different wizards that created supply records for each type have been merged into a single wizard. This allow to ensure that all supply records are created at once, leaving the system in a coherent state.
  • The order point has now a maximum quantity. If this quantity is reached by the location then the extra quantity will be shipped to the defined overflowing location.
  • Just like there is a warning on the supply wizard for late supplier moves, there is also now a warning for late customer moves. By default Tryton consider that customer moves not performed on time, will not be done and so they are no more supplied. This warning ensure the user will take care of those late moves by canceling or replanning them before computing the stock supply.


This new module adds the computation of the weight and volume of the shipments and packages. This is a central place where this computation can be shared between different modules.

Major changes for the developer

  • The Property fields have been removed in favor of the MultiValue based on the MultiValueMixin and ValueMixin. The Property fields were used mainly to provide multi-company capabilities but the API is based on context attribute only which makes them very difficult to use without having record rules to ensure not mixing between company. The new API allows to get values without using context and this will allow us to remove the multi-company record rule in future release.

  • The col attribute in the view can have a negative value to create an infinite number of column. This is very useful for group that are designed to get an undetermined number of field.

  • A new domain has been added to the window action. This domain evaluation is reevaluated when the context is changed. This creates more dynamic windows.

  • All the domain computation can be override by a method domain_<field name> on the Model with until now the exception of the Function fields. This makes the API more coherent and allow to create more performant SQL query for Function fields by using for example joins.

  • Two new capabilities check methods have been added to the Database back-end:

    • has_select_for which allows to use the SELECT ... FOR to lock specific rows instead of the all table.
    • has_window_functions which allows to use the SQL window functions.
  • A better independence between the fields and the backend has been implemented in this version. This allow external modules to define new kind of fields. For example, a set of GIS fields is under development based on those improvements.

    • The fields define now which methods should be configured for RPC
    • A generic SQL type is defined by the fields and it is on the back-end responsibility to convert into its specific version.
  • The order definition for a column support the extra keywords for ordering null values. The available keywords are: NULLS FIRST and NULLS LAST. For SQL back-end that does not support the keywords, the order is converted into an equivalent SQL query thanks to python-sql.

  • The Many2One fields on ModelSQL can now target just ModelStorage. Tryton will not try to create a foreign key constraint on the table in that case.

  • A new filter attribute has been added to all xxx2Many fields. This filter is used to limit the records returned by the getter of the fields. So it is like domain but without being a constraint for the setter. This allows to replace some Function into plain fields. This review still needs to be done for all modules.

  • The cache management is automatically done now in the Transaction. This allows to ensure the consistency and integrity of the cache but also ease the usage of trytond in Python script.

  • A new security measure against brute force attack on the login has been implemented. A new max_attempt parameter in the configuration determine the number of attempt before the server answers unconditionally Too Many Requests for new login attempts. This lasts for the timeout period.

  • Some constraints have been added to the user password to enforce good security practice. Those constraints are:

    • a configurable minimal length which is 8 by default.
    • a list of forbidden password. This list is stored into a file defined in the configuration. By default there is no list but it is useful for example to forbid the name of the company etc.
    • a minimal ratio of non repeated characters.
    • the password must be different of the login, email and name of the user.


  • New methods ceil and floor have been added to the Unit of Measure. They have the same API as round.


  • For better accuracy of production quantities, the input quantities are ceil and the output quantities are floored. This reflect better the really than rounding the quantities.


  • The default product location uses the MatchMixin pattern now. This makes it easier to extend with new criteria.
  • The computation of the maximum lead time has been improved to be more accurate by summing all the lead times to get the biggest path possible. It also adds extra lead times like the biggest supplier lead time.

Security Release for issue6361

Publicado: 2017-04-04 18:00:00+00:00 release security


A vulnerability in trytond has been found by Cédric Krier.

The CVE-2017-0360 allows an authenticated user with write access to report or icon definition to make the server open any readable file under any sibling folder of the trytond installation but only if starts with trytond (for example: ../trytond_suffix). This is a remaining case from CVE-2016-1242


The sibling folder starting with trytond could be renamed.


All users should upgrade trytond to the latest version.

Affected versions per series: <=3.4.16, <=3.6.14, <=3.8.10, <=4.0.7 and <=4.2.2

Non affected versions per series: >=3.4.17, >=3.6.15, >=3.8.11, >=4.0.8 and >=4.2.3


Any security concerns should be reported on the bug-tracker at with the type security.

New Tryton release 4.2

Publicado: 2016-11-28 18:00:00+00:00 release

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.

    Tryton tab domain count Sao tab domain count
  • 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.

    Tryton button rule
  • 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.

    Tryton calendar color
  • 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.

    Tryton old Many2One

    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.

    Tryton new Many2One

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.

    Sao export CSV
  • The calendar view based on the FullCalendar.

    Sao calendar view
  • Support for translated fields.

    Sao translate field
  • The Favorites menu.

    Sao favorite
  • The date picker is now locale aware.

  • Add support for column sorting.

  • Support for confirm attribute on the buttons.


  • 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.

    Balance Sheet comparison
  • 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.


  • 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.


  • 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.


  • 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.


  • 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.


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


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


  • 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.


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.


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


  • 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.


  • 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.


  • 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.


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


  • 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.


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.


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.


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.


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.

Security Release for issue5795 and issue5808

Publicado: 2016-08-31 10:00:00+00:00 release security


Two vulnerabilities in trytond have been found by Cédric Krier.

The CVE-2016-1241 allows an authenticated user to read the hashed password of other users. The exploitation is not easy thanks to the existing protection of Tryton against such leak. Those protections are usage of strong hash method (bcrypt or sha1) and the salt of the password with random data (protection against rainbow tables).

The CVE-2016-1242 allows an authenticated user with write access to report or icon definition to make the server opens any readable file. By default, only the administrator group has such right access.


There is no workaround for CVE-2016-1241.

For CVE-2016-1242, the modification rights could be removed to all users for the report and icon records.


All users should upgrade trytond to the latest version.

It is recommended that every user changes his password.

Affected versions per series: <=3.2.16, <=3.4.13, <=3.6.11, <=3.8.7 and <=4.0.3

Non affected versions per series: >=3.2.17, >=3.4.14, >= 3.6.12, >=3.8.8 and >=4.0.4


Any security concerns should be reported on the bug-tracker at with the type security.

Versión con traduciones para las series 4.0

Publicado: 2016-05-11 10:00:00+00:00 release

Debido a un problema con Pootle, la versión inicial de las series 4.0 se ha publicado sin muchas traducciones. Por este motivo hemos decidido publicar un nuevo conjunto de versiones con las traducciones corregidas aunque esto suponga romper la regla de ninguna actualización de base de datos para las versiones de corrección intermedias.

Si ya habéis actualizado vuestro servidor a las series 4.0, debéis también actualizar la base de datos para esta versión de correcciones. Disculpad las molestias.

Nueva versión 4.0 de Tryton

Publicado: 2016-05-02 18:00:00+00:00 release

Estamos contentos de anunciar la publicación de la versión 4.0 de Tryton.

Es la primera versión de Tryton que añade soporte para Python 3. El servidor y la mayoría de módulos ya lo soportan. Los módulos que faltan son principalmente aquellos que utilizan WebDAV y LDAP. El cliente será portado cuando se añada el soporte para GTK-3.

Esta versión también contiene una gran refactorización de la pila de protocolo que antes estaba basada en el SimpleHTTPServer de Python. Ahora utiliza una aplicación WSGI corriendo a través del servidor Werkzeug por defecto. De todos modos se puede utilizar cualquier servidor WSGI para ejecutar Tryton, eliminando la restricción de un único proceso con hilos y abre el camino a la ejecución a través de varios esclavos.

Todos los módulos se han revisado para cumplir con la convención de la nomenclatura para la identificación de documentos. El nombre "Código" se utiliza para todos los documentos referenciales, como por ejemplo los terceros y los productos. El nombre "Número" se utiliza para la identificación interna de todos los documentos operacionales, como por ejemplo ventas, compras, facturas, etc. Por último, el nombre "Referencia" se utiliza para las identificaciones de sistemas externos, como por ejemplo el número de venta del proveedor de nuestras compras.

Se han añadido dos nuevos idiomas en la instalación por defecto: Lao y chino simplificado.

Como nos recordó Richard Stallman, la migración desde versiones anteriores esta totalmente soportada.

Cambios importantes para el usuario

  • La nueva funcionalidad nota ofrece un sistema para gestionar notas textuales en cualquier modelo de Tryton. Cuando se clica se abre un diálogo de notas donde el usuario puede gestionar las notas del registro. El estado de lectura de cada nota es independiente por cada usuario. Como sucede con los ficheros adjuntos, el icono de la barra de herramientas indica cuando hay notas en un registro.

    Notas en Tryton Notas en Sao
  • Se ha mejorado la importación y exportación a través de CSV para obtener una mejor experiencia. La ventana de importación ahora soporta arrastrar y soltar campos para ordenar las columnas, como ya pasaba con el asistente de exportación. Ambos asistentes pueden utilizar cualquiera de las codificaciones disponibles en Python. Ahora se pueden configurar los parámetros CSV del resultado de la exportación.

    Exportar CSV
  • Los gráficos provistos por la vista de tipo gráfico han sido mejorados. Ahora usan colores más suaves, líneas más delgadas y arcos más pequeños. En lo que se refiere al fondo, se usa un estilo de guiones en lugar de la línea normal para la representación de los ejes. Se aplica un pequeño valor de transparencia al dibujar líneas para poder ver siempre a través de ellas.

  • Se ha añadido un nuevo botón en las tareas programadas para ejecutarlas una sola vez. Esto es útil para ejecutarlas bajo demanda o probar nuevas configuraciones.


  • Se ha mejorado el diseño del Libro mayor, Balance de sumas y saldos y el Balance histórico. Ahora se basan en vistas dinámicas. Esto permite una mejora del rendimiento y filtrar los registros de una forma más precisa. Además de poder imprimir informes como antes, se puede exportar los registros a CSV, cosa que es útil para realizar manipulaciones en una hoja de cálculo.

    Libro mayor
  • Se ha añadido el campo Fecha al Balance histórico, para poder modificar la fecha en que se realizan los cálculos. Con esta funcionalidad se puede generar informes en una fecha pasada como si se hubieran generado ignorando las conciliaciones que se han producido después de esta fecha.

  • Se ha mezclado la funcionalidad del informe Balance de tercero dentro del Balance histórico. Nos hemos dado cuenta que ambos informes calculan la misma información pero el Balance de tercero se calcula sobre el tipo Clientes y proveedores.


  • El campo Nombre del tercero ya no es obligatorio. Esto soluciona la antigua demanda de poder crear terceros sobre los que no se sabe el nombre cuando se crean.


  • Se ha añadido un formulario de configuración en el módulo de producto con las siguientes opciones:

    • Valor por defecto para los campos Utilizar Categorías.
    • Valor por defecto para el campo Método de precio de coste.
  • Nunca ha sido fácil explicar el diseño de los productos con sus plantillas, especialmente cuando no es relevante para el negocio. Para simplificarlo, se han rediseñado las vistas para que sean muy similares y en efecto utilizan exactamente el mismo diseño. Los campos que no existen en el producto son automáticamente reemplazados por el valor de la plantilla.

    Producto Variante
  • El campo Categoría se ha reemplazado por el campo Categorías para soportar la funcionalidad de añadir múltiples categorías a un mismo producto. Esto es muy útil para crear categorías multi-dimensión en tiendas online.


Este nuevo módulo define las referencias base para crear diferentes tipos de clasificaciones para los productos. Añade un campo genérico Clasificación en el formulario de producto.

Clasificación Taxonómica

Este nuevo módulo añade la clasificación taxonómica de los productos como un ejemplo de utilización del nuevo módulo de clasificación. Incluye las clasificaciones por Taxón y por Cultivar.


  • El campo Tiempo de entrega en el proveedor de producto es reemplazado por Tiempo de espera, lo que incrementa la precisión de días a microsegundos.
  • Para cada almacén ahora es posible definir la ubicación de donde se tomarán los bienes en caso de una devolución al proveedor. Si esta ubicación no está definida se utilizará la ubicación de almacenamiento del almacén.


Las funcionalidades de solicitud de compra han sido desacopladas de los módulos stock_supply y sale_supply a un nuevo módulo llamado purchase_request. De esta forma se prepara el trabajo futuro para permitir usar solicitudes de compra sin la necesidad de otras características del módulo stock_supply.

  • Un nuevo estado Excepción ha sido agregado a la solicitud de compra. Esto es útil para gestionar compras canceladas cuando están atadas a "envíos directos".


  • El campo Fecha de entrega en el modelo Línea de venta se ha renombrado a Fecha envío para evitar cualquier confusión.
  • El campo Tiempo de entrega en el formulario de producto es reemplazado por Tiempo de espera, lo que incrementa la precisión de días a microsegundos.
  • La personalización de la historia de las Oportunidades de venta se ha reemplazado para la funcionalidad de revisiones del cliente. Eso mejora la precisión y funciona de forma automática para los nuevos campos.


  • La dirección de destino del almacén de los Albaranes internos ahora se muestra en el informe.
  • Ahora es posible finalizar un movimiento con el nuevo botón Finalizar. Esto es interesante para tener una contabilidad correcta en caso de tener producciones abiertas durante mucho tiempo.
  • Los albaranes de devolución de proveedor ahora tienen el campo Proveedor y Dirección de envío. Estos campos se llenarán automáticamente para los albaranes creados a través de una compra.



Este nuevo módulo define las rutas, los pasos y las operaciones de las producciones. Una ruta es una lista ordenada de pasos y cada paso está definido por una operación genérica.


Este nuevo módulo completa el módulo de Ruta creando los Trabajos de una producción basándose en su ruta. Un Trabajo esta vinculado con un Centro de Trabajo que define su coste mediante los siguientes métodos: Por ciclo o Por hora. El coste de un trabajo se calcula a través de los Ciclos creados en el mismo y luego se añade al coste global de la producción.

Cambios importantes para el desarrollador

  • Los dominios ahora aceptan el operador parent_of que devuelve recursivamente todos los registros que son padres de los registros buscados. Es el operador opuesto al existente child_of.
  • Ahora es posible heredar una vista que ya hereda de otra vista de otro modelo diferente.
  • El nuevo operador de dominio where es útil cuando necesitas hacer una búsqueda sobre un campo xxx2Many con un sub-dominio completo en lugar de cláusulas separadas. Tiene la ventaja de evitar la obtención intermedia de resultados ya que usa una sub-query.
  • La Transacción ha sido mejorada para que su diseño sea más cercano al definido por el PEP-0249. Este nuevo diseño permite dar soporte a transacciones anidadas. También soporta cursores múltiples para la misma transacción, reduciendo el consumo de memoria al iterar sobre grandes conjuntos resultantes.
  • Se introduce un nuevo modelo contextual para evitar el trabajo de escribir asistentes simples para configurar informes asignando algunos valores en el contexto. Con este nuevo diseño, el desarrollador puede definir un modelo para el cual cada campo va a definir los valores del contexto. El formulario de este modelo se mostrará en la parte superior de la vista y la vista se actualizará automáticamente cuando el contexto cambie.
  • Ahora es posible tener informes en texto plano, XML, HTML y XHTML. Con este cambio la infraestructura de informes se puede utilizar para diseñar plantillas de correo electrónico.
  • Esta nueva versión añade soporte para el Protocolo de comiteado en dos fases que permite coordinar transacciones distribuidas. Por defecto, Tryton utiliza una sola transacción de la base de datos, pero cuando Tryton tiene que comunicarse con otros sistemas, es mejor utilizar el PC2F para mantener la integridad de datos. La implementación sigue la API de los Data Managers de Zope. Los Data Managers de la comunidad de Zope se puede utilizar en Tryton.
  • Gracias al protocolo de comiteado en dos fases, ahora los correos electrónicos se pueden enviar cuando la transacción está comiteada. Así, si alguna cosa va mal y la transacción se deshace, no se envía ningún email.


  • El proceso de conciliación ahora guarda la fecha de la conciliación. Por defecto, es la mayor fecha de las líneas conciliadas. Esto permite filtrar lineas conciliadas basado en esa fecha, por ejemplo para generar un reporte con las lineas sin conciliar anteriores a una fecha dada.

  • Los Abonos han sido integrados con las Facturas. Ahora son facturas estándar con cantidades negativas. Esto permite agrupar fácilmente ambos tipos en un único documento. La numeración aún puede ser diferenciada dependiendo del signo de las líneas.

    Nota: con la integración de Factura y Abonos, los signos de los impuestos para los Abonos deben ser invertidos a mano.


  • Uom.round ahora es un método de instancia cosa que tiene mucho más sentido teniendo en cuenta su firma.


  • Las Compras ahora disponen de la transición finalizado, como las Ventas, para permitir extensiones que realizan alguna acción cuando se ha finalizado la compra.
  • Ahora se puede buscar las Solicitudes de compra utilizando el campo Compra.


El módulo WebDAV se ha separado del servidor hacia un módulo aparte, cosa que mejora la modularidad del sistema. En efecto, muchas instalaciones no utilizan WebDAV por lo que era un poco hinchado tenerlo en la base. Además las dependencias de este módulo bloqueaban el camino hacia Python 3 en el servidor. Por el momento, el protocolo WebDAV se gestiona mediante un proceso separado pero es posible que vuelva en el futuro al proceso principal.

Publicación seguridad para issue5167

Publicado: 2015-12-17 07:00:00+00:00 release security


Una vulnerabilidad en trytond ha sido encontrada por Cédric Krier, que podría permitir a un usuario malicioso autenticado escribir en campos en los cuales no tiene acceso (ver issue5167).


Cualquier usuario autenticado puede escribir en campos en los cuales no tiene acceso. Los otros permisos de acceso se verifican correctamente.


No existe ninguna alternativa.


Todos los usuarios deben actualizar trytond a la última versión.

Versiones afectadas: <=3.8.0, <=3.6.4, <=3.4.7 and <=3.2.9

Versiones no afectadas: >=3.8.1, >=3.6.5, >=3.4.8 and >=3.2.10


Cualquier incidencia de seguridad debe ser reportada en el bug-tracker con el tipo security.