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.

Accounting

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

account_invoice_correction

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.

account_payment_stripe

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.

Commission

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

Product

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

product_price_list_dates

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.

Production

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

Purchase

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

Sale

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

sale_subscription

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

sale_advance_payment

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.

Stock

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

stock_shipment_measurements

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.

Product

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

Production

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

Stock

  • 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

Synopsis

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

Workaround

The sibling folder starting with trytond could be renamed.

Resolution

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

Concern?

Any security concerns should be reported on the bug-tracker at https://bugs.tryton.org/ 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.

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.

    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.

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.

    Chronos

    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.

Security Release for issue5795 and issue5808

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

Synopsis

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.

Workaround

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.

Resolution

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

Concern?

Any security concerns should be reported on the bug-tracker at https://bugs.tryton.org/ 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.

Contabilidad

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

Terceros

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

Productos

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

Clasificación

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.

Compras

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

Solicitud

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

Ventas

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

Logística

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

Producción

Rutas

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.

Trabajo

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.

Contabilidad

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

Producto

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

Compras

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

WebDAV

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

Sinopsis

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

Impacto

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

Alternativa

No existe ninguna alternativa.

Resolución

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

¿Incidencias?

Cualquier incidencia de seguridad debe ser reportada en el bug-tracker https://bugs.tryton.org/ con el tipo security.

Nueva versión 3.8 de Tryton

Publicado: 2015-11-02 18:00:00+00:00 release

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

Por primera vez contiene sao, el nuevo cliente web de Tryton. Es el resultado de la campaña Indiegogo . Se ha desarrollado principalmente usando jQuery y Bootstrap y su diseño es adaptativo. Se requiere un navegador actual compatible con HTML5. Para utilizarlo no se requiere ninguna modificación en el lado del servidor, cada módulo trabaja tal cual con sao al igual que lo hace con el cliente GTK. Está disponible una demostración en http://demo.tryton.org usando demo_es/demo como usuario/contraseña de inicio de sesión. Esto conlleva a que el número de clientes compatibles para Tryton ya sean tres.

Se ha trabajado mucho para mejorar la accesibilidad de los clientes web y GTK. Para el cliente GTK se ha seguido la Guía de accesibilidad GNOME para desarrolladores tanto como ha sido posible y para el cliente web se ha seguido la Iniciativa de accesibilidad Web del W3C. Puede seguir los avances en este tema en el issue3459.

Y por supuesto, esta versión contiene muchas correcciones de errores y mejoras de rendimiento.

Como siempre, la migración de las versiones anteriores está totalmente soportada

Las siguientes capturas de pantalla se basan en sao pero las mismas características existen también en el cliente GTK.

Esta es una comparación de la visualización del cliente sao frente el cliente GTK:

Venta con sao Venta con GTK

Cambios importantes para el usuario

  • Ahora el cliente es capaz de generar mensajes de error significativos para todo tipo de validación. Estos mensajes de error utilizan la misma sintaxis que el filtro de búsqueda.

    Mensaje de error
  • Para una mejor accesibilidad se ha sustituido el color de fondo personalizado por etiquetas en 'negrita' para los campos requeridos y por etiquetas en 'cursiva' para los campos editables. Por el mismo motivo, el color de filas se ha eliminado y puede ser reemplazado por iconos.

    Etiquetas en negrita y cursiva
  • Se ha añadido al cliente una nueva opción para tabulación rápida. Si se activa, se salta los campos de sólo lectura al navegar con el tabulador. Este era el comportamiento predeterminado anterior, que debía ser opcional para permitir a los usuarios con discapacidades desplazarse por los campos de sólo lectura para su lectura.

  • Ahora la función de exportación sólo funciona con los registros seleccionados pero permite exportar una estructura de árbol.

Contabilidad

  • Se ha añadido un nuevo informe que muestra los importes de un diario de efectivo en un período. Esto es útil para comprobar el cierre de la caja.

  • La contabilidad francesa genera la FEC (Fichier des Écritures Comptables).

  • El asistente que genera los pagos permite indicar una fecha en lugar de la por defecto que es hoy.

  • Las cuentas de ingresos y gastos predeterminadas se pueden configurar desde la configuración de contabilidad.

    Configuración de cuentas
  • La fecha de los extractos se puede corregir después de su contabilización.

Tercero

  • Ahora el idioma del tercero depende de la empresa.

  • Una lista extensible de identificadores reemplaza el único campo CIF/NIF.

    Identificadores del tercero

Proyecto

El cálculo del árbol del proyecto ha sido enormemente mejorado mediante la agrupación del cálculo y el uso de mejores consultas.

  • Ahora existe un campo de progreso en los proyectos y tareas y, por supuesto, un total que es la suma de los hijos.

    El progreso del proyecto
  • Se ha añadido un nuevo método para generar la factura del proyecto que se basa en el campo de progreso.

  • Ahora es posible vincular líneas de compra a un proyecto que se añadirán al campo de coste.

  • Ahora los trabajos de las hojas de trabajo tienen un campo total de horas que calcula la duración del trabajo y sus hijos.

    Horas del trabajo

Venta

  • La fecha de entrega en la línea de venta muestra la fecha efectiva una vez que los bienes son entregados.

  • Ahora es posible enviar la venta a otro tercero distinto del indicado en la factura. Esto es un complemento al envío directo que permite que Tryton soporte totalmente los envíos directos.

    Tercero de envío en la venta
  • El envío directo ahora utiliza dos movimientos distintos utilizando una ubicación temporal.

Compra

  • La fecha de entrega en la línea de compra muestra la fecha efectiva una vez que los bienes son recibidos.
  • Se pueden cancelar movimientos de stock desde la vista de la compra sin tener que crear un albarán de proveedor y cancelarlo.

Logística

  • Es posible solicitar a Tryton volver a calcular el precio de coste medio de un producto mediante la reproducción de todos los movimientos desde el principio.

  • Es posible configurar otra ubicación de recogida diferente de la ubicación de almacenamiento para los almacenes.

    Ubicación de recogida del almacén
  • Es posible establecer un aprovisionamiento interno por ubicación que se utiliza para las reglas de stock internas por defecto para todos los productos.

Coste de recepción

Estos nuevos módulos permiten guardar el coste de recepción en los envíos de los proveedores después de su recepción. Se crea un nuevo documento para vincular líneas de factura de proveedores con envíos y definir el método que se utilizará para la asignación de costes. Actualmente hay dos métodos disponibles: Por Valor y Por peso. Y gracias al asistente Actualización precio de coste, el precio de coste de los productos puede ser recalculado teniendo en cuenta el coste de recepción.

Coste de recepción

Aduana

Este nuevo módulo permite definir el Código de Tarifa del Sistema Armonizado y su tasa de aduana sobre los productos. El tipo de tasa se almacena para un país durante un período y están disponibles dos tipos de cálculo: un importe fijo o un importe por cantidad.

Reclamación de venta

Este nuevo módulo sirve para gestionar las reclamaciones de los clientes acerca las ventas o facturas. Permite definir las acciones para resolver las quejas, como devolver la venta o abonar la factura. Permite establecer un flujo de trabajo para la aprobación de las acciones de reclamación mediante los permisos de acceso.

Promoción de venta

Ahora es posible aplicar promociones basadas en fórmulas sobre las ventas seleccionadas mediante ciertos criterios. La promoción cambia el precio unitario de la línea cuando la venta cambia a presupuesto (y se restablece si se vuelve a borrador) pero sólo si la promoción es a favor del cliente. Los criterios disponibles son: la tarifa, un período, la cantidad y los productos.

Cantidad de stock en la venta

Este nuevo módulo comprueba en ventas en estado presupuesto si hay suficiente cantidad de productos en el almacén. También comprueba que la nueva venta no perjudique a ventas anteriores que serán enviadas más tarde.

Cambios importantes para el desarrollador

  • El campo de barra de progreso funciona con un real entre 0 y 1 para facilitar su uso como porcentaje.
  • El campo de texto enriquecido ahora utiliza un subconjunto de HTML para permitir su implementación en sao.
  • El campo Many2One tiene una nueva opción target_search que define el tipo de consulta a utilizar para la búsqueda desreferenciada. Las opciones son subquery y la nueva join (que es el valor por defecto). El método join genera una consulta más rápida en la mayoría de los casos.
  • Las restricciones de SQL utilizan una sintaxis similar a python-sql. Esto da más flexibilidad para implementar el backend para otras bases de datos.
  • Tratar de crear/escribir/borrar en un Model basado en una table_query genera una excepción en lugar de un error silencioso.
  • El nombre de la tabla de un ModelSQL se puede reemplazar con un archivo de configuración. Esto permite evitar las limitaciones de ciertas bases de datos respecto a la longitud de los nombres de las tablas.
  • Se ha añadido a los asistentes el nuevo StateReport para simplificar el código de los asistentes que ejecutan un informe.
  • Se ha eliminado el estilo de los informes, la experiencia muestra que esta función no era utilizada.
  • El backend de PostgreSQL ahora gestiona el esquema. Esto permite que distintas instancias de Tryton compartan la misma base de datos.
  • La clave foránea genérica para crear/modificar el usuario en todos los ModelSQL ha sido reemplazada por una regla que impide eliminar usuarios. Esto mejora enormemente la escalabilidad en algunas circunstancias.
  • El campo Property ahora soporta valores float y integer.
  • Un subdirectorio locale/override permite a los módulos sobrescribir traducciones de otros módulos.

Contabilidad

  • Los planes contables ya no son traducibles. En lugar de ello debe proporcionarse planes contables traducidos a través de una plantilla usando XSLT.
  • La factura no calcula un precio unidad en cada línea. Para tener esta función debe utilizarse los módulos de compras o ventas.
  • Algunos campos de la factura como las Notas y el Origen son editables después de contabilizar la factura.

Producto

  • La conversión entre unidades ya no genera fallos silenciosos sino que aparece un error explícito.
  • Se ha añadido la propiedad volumen a los productos.

Proyecto

  • La estructura de árbol del proyecto y de la hoja de trabajo se han separado, cada objeto tiene su propia estructura de árbol.
  • La tarifa utiliza los mismos decimales que el producto.
  • El precio de coste del empleado se almacena en la línea de la hoja de trabajo según la fecha de la línea. Esto permite sumar los costes de la hoja de trabajo más rápido.

Compra

  • Ahora el estado de la solicitud de compra permite realizar búsquedas.
  • Las solicitudes de compra se generan incluso si la cantidad redondeada es cero para permitir al usuario comprar más.

Logística

  • Muchas restricciones innecesarias en la edición de los campos de los movimientos han sido eliminadas.
  • La cantidad esperada de las líneas de inventario se calculan siempre, incluso si se añaden manualmente.
  • Es posible crear movimientos en estado En proceso y Borrador utilizando ubicaciones de tipo Vista. Estas ubicaciones tendrán que ser cambiadas para poder finalizar el movimiento.
  • El inventario utiliza la función de agrupación para crear los movimientos. Esto permite soportar fácilmente el lote (o cualquier otro campo extra).

Nueva versión 3.6 de Tryton

Publicado: 2015-04-22 18:00:00+00:00 release

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

Esta versión incorpora el soporte oficial de PyPy que es una implementación alternativa de Python centrada en la velocidad y la eficiencia.

Como siempre, la migración de las versiones anteriores está totalmente soportada a excepción del módulo ldap_connection que ha sido eliminado.

Cambios principales para el usuario

  • Un esquema de colores nuevo para los gráficos que remplaza la única variación de brillo que había. Ahora el esquema de colores también cambia el matiz de cada color mediante el ángulo de oro (que asegura que un color no sea seleccionado dos veces).

    Esquema de colores para los gráficos
  • El campo diccionario recibe sugerencias a partir de la búsqueda del texto de forma similar a otros campos.

  • Los campos fecha y hora han sido reescritos completamente para poder ser más flexibles con el formato a teclear. Pero también son más prácticos si se usan con el ratón gracias a un calendario emergente real y a una lista desplegable para la hora.

    Campo fecha Campo fecha y hora
  • Las columnas de la vista listado que tienen siempre el mismo valor se ocultan automáticamente debido a que no proporcionan información. Por ejemplo, la lista de facturas contabilizadas no muestran la columna estado porque, por definición, todas ellas están contabilizadas.

Contabilidad

  • Ahora se puede añadir una descripción al asiento de cancelación desde el asistente.

  • En el libro mayor aparece una nueva opción para mostrar sólo el saldo.

  • Se pueden configurar los impuestos para modificar el precio base para los siguientes impuestos de la lista.

  • Ahora se pueden definir plantillas para asientos habituales. Cuando se ejecuta una plantilla, al usuario se le preguntará que introduzca algunos datos como un importe o un tercero, para poder generar un asiento con estos datos.

    Plantilla de asiento
  • Se ha añadido un informe imprimible para la amortización de activos.

  • Los planes contables para Francia y Bélgica han sido actualizados. Y el de Bélgica ha sido traducido al holandés.

  • Se dispone de un asistente de prueba para ver los resultados generados por un plazo de pago. Como los plazos de pago son muy flexibles porqué permiten aplicar varios incrementos de tiempo (en lugar de uno), no siempre es fácil prever el comportamiento.

    Prueba de plazo de pago
  • Se ha extendido la cobertura de SEPA con los sabores pain.001.003.03 y 008.003.02 que se utilizan en Alemania. Y también es posible regenerar un mensaje SEPA en caso de configuración errónea en la primera generación.

  • Los extractos crean asientos agrupados por número, fecha y tercero por defecto. Así, cuando una línea de extracto se divide para conciliar facturas, sólo se crea un asiento y el origen de este asiento es el grupo de las líneas de extracto.

  • Las reglas de impuestos ahora pueden depender del país de origen y de destino gracias al nuevo módulo account_tax_rule_country.

  • Se ha añadido el formato SEPA personalizado (no estándar) CFONB con el nuevo módulo account_payment_sepa_cfonb.

  • El nuevo módulo account_deposit añade un nuevo tipo de cuenta Adelanto. Permite facturar adelantos y recuperar este importe más tarde en la siguiente factura.

Productos

  • Ahora se puede definir una tarifa con impuestos incluidos. Tryton calculará el precio sin impuestos según los impuestos aplicados.

Ventas

  • Se ha añadido un nuevo estado Ganada a las oportunidades de venta. La oportunidad cambia a este estado automáticamente cuando una de sus ventas se confirma y todas las otras están también confirmadas o canceladas.
  • El importe de las oportunidades se actualiza según el importe de las ventas relacionadas. Esto permite obtener informes más precisos.
  • El cálculo del coste de envío sólo se calcula al pasar a presupuesto. Esto reduce la carga en el cliente cuando la venta es bastante larga ya que el coste se calculará una sola vez en lugar de cada vez que una línea sea añadida.
  • El módulo nuevo sale_extra permite añadir líneas extras en las ventas según varios criterios. La línea extra puede ser tanto un producto gratis como un coste de servicio adicional.

Logística

  • Ahora hay una relación entre un producto y sus reglas de abastecimiento.
  • La creación de solicitudes de compra avisa también de producciones anteriores igual como lo hacía de albaranes de entrada anteriores.
  • Las informaciones de vida útil y fecha de caducidad están incluidas en el nuevo módulo stock_lot_sled. Cuando un lote caduca, no se utiliza más para calcular la cantidad prevista de stock.

Comisiones

Esta nueva área se gestiona con un conjunto de nuevos módulos commission. Se crean comisiones para el agente definido en una venta o factura utilizando un plan de comisiones. También permite definir agentes principales en los productos a los que también habrá que pagar comisiones.

Principales cambios para el desarrollador

  • Ahora se permite tener varias veces el mismo campo en una vista listado/árbol.
  • El campo datetime ha desaparecido en las vistas listado/árbol, hay que usar en su lugar dos columnas, una con el campo fecha y otra con el campo hora.
  • En esta versión aparece un nuevo campo TimeDelta para representar una duración. Reemplaza el campo float_time que tiene algunos problemas de redondeo. Este nuevo campo ya se usa en los módulos timesheet y project.
  • Se puede configurar los campos One2Many para utilizar un producto cartesiano con la selección de varios valores de campos Many2One o Reference.
  • Se añade el método restore_history_before a ModelSQL que se comporta como el existente restore_history pero restaurando los registros justo antes de una fecha-hora.
  • Los métodos on_change han sido migrados para tener un comportamiento más consistente con el Active Record Pattern utilizado en Tryton. En vez de devolver un diccionario con los valores a cambiar, se cambia la instancia directamente. Esto permite encadenar fácilmente los métodos on_change o reutilizarlos en otros métodos reduciendo la duplicación de código.
  • El método save de ModelStorage ahora es un dualmethod que significa que pueda ser llamado como siempre como método de instancia pero también como método de clase con una lista de registros. De este modo, guardar varios registros a la vez mejora el rendimiento ya que el método minimizará el número de peticiones a la base de datos y validará el resultado entero.
  • El campo Dict recibe el método translated para crear descriptores con los que traducir los valores o las claves, de forma similar al mismo método en los campos Selection.
  • Ahora se puede utilizar la notación con punto en el parámetro orden de una búsqueda. El ORM generará automáticamente las agrupaciones necesarias.
  • La API de la clase Report ha sido reescrita para mejorar la personalización del motor de informes. Ahora los métodos de formato son más estrictos para prevenir fallos silenciosos.
  • La función safe_eval (que no es para nada segura) ha sido completamente eliminada. En los lugares donde el código evaluado era de todos modos seguro se utiliza la función estándar eval. Para evaluar código desde el exterior ahora se utiliza una notación JSON. Se han desarrollado algunas utilidades para facilitar la creación de JSON desde XMl o en las vistas.
  • Se ha añadido una nueva clase de botón que trabaja sobre registros no guardados. Son similares a los on_change pero son disparados por un clic en un botón en lugar de un cambio en un campo.

Contabilidad

  • Se ha añadido un método nuevo reverse_compute a los impuestos que permite calcular el importe base a partir del importe con impuestos.
  • El signo del importe en la segunda moneda de un apunte se fuerza a que sea el mismo que el signo del debe - haber.
  • La gestión de la contabilidad analítica ha sido reescrita para usar realmente campos One2Many en lugar de pseudo-campos. Esta simplificación ha sido posible gracias a las nuevas funcionalidades recientes como el uso de un campo Reference en un One2Many.

Terceros

  • Ahora se guarda el número de CIF/NIF en su forma compacta.

Productos

  • Ahora se puede definir el número de decimales para los cálculos internos de precios como un parámetro de configuración price_decimal. Este parámetro se usa en todos los sitios para asegurar consistencia entre todos los módulos.

Compras/Ventas

  • Las líneas de compras/ventas soportan ambos tipos de factura (factura y factura de abono) en cada línea cuando se calcula la cantidad facturada.

Logística

  • Se ha añadido un nuevo estado staging en los movimientos. Este estado no impacta en ningún cálculo de los niveles de stock. Se utiliza para el suministro en ventas, para crear movimientos por adelantado.
  • También se calculan los productos inactivos para saber el nivel de stock.
  • Se ha mejorado el cálculo de los movimientos asignados para tener en cuenta sólo los movimientos asignados de salida, no los de entrada. Esto comporta un nivel de stock menos optimista y por tanto evita asignar movimientos con una entrada que esté asignada pero todavía no finalizada.
  • Las previsiones son desactivadas automáticamente cuando su periodo forma parte del pasado.

Nueva versión 3.4 de Tryton

Publicado: 2014-10-20 18:00:00+00:00 release

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

Además de las mejoras habituales de las funcionalidades existentes para usuarios y desarrolladores, esta versión muestra los resultados del trabajo exhaustivo realizado en el área de contabilidad.

Como siempre, la migración de las versiones anteriores está totalmente soportada a excepción del módulo ldap_connection que ha sido eliminado.

Principales cambios en la interfaz de usuario

  • La búsqueda de registros relacionados ha sido rediseñada para aprovechar las ventajas del autocompletado automático. En esta versión, la ventana emergente mantiene el texto introducido en la búsqueda.

  • Ahora el botón de Abrir/Buscar registro de los registros relacionados se sitúa dentro de la caja de texto, y el botón Crear un nuevo registro ha sido sustituido por las acciones de autocompletado o por el botón de la ventana emergente. Este cambio permite armonizar las dimensiones de los campos en los formularios.

    botones interiores campo many2one
  • Ahora se pueden mostrar imágenes en la vista de listado/árbol.

    campo imagen dentro listados
  • Se pueden realizar prevalidaciones de campos antes de ejecutar acciones de botón. Las validaciones resaltan los campos erróneos en vez de informar del error en una ventana emergente.

  • Se incrementan las posibilidades de la exportación de datos incorporando la etiqueta de campos selección y el valor interno (ID) del registro (CSV).

  • Exportar la información que se está consultando es ahora más fácil y rápido, ya que la ventana de exportación se predefine con los campos que se visualizan.

  • Los campos predefinidos de exportación ahora se pueden sustituir directamente por una nueva selección de campos. Una mejora pensada para facilitar la creación de plantillas de exportación.

  • Ahora podemos ordenar fácilmente la lista de campos a exportar seleccionando y arrastrando los elementos.

  • Los rangos de búsqueda ahora incluyen por defecto ambos extremos. Este comportamiento es menos extraño para los usuarios aunque el comportamiento anterior de incluir - no incluir los extremos tuviera algunas ventajas prácticas.

  • En esta versión el cliente también carga los 'plug-ins' definidos en el directorio local del usuario. (~/.config/tryton/x.y/plugins).

Principales cambios en el servidor

  • Se introduce la clase Mixin MatchMixin que permite implementar un patrón común de búsqueda de registros a partir de ciertos valores.
  • También se añade la clase UnionMixin que permite definir un ModelSQL que es la UNION de varios ModelSQL.
  • En la versión anterior, Tryton no actualizaba los registros de configuración definidos mediante un fichero XML si se modificaban fuera del fichero. En la nueva versión es posible encontrar estos registros y forzar su actualización para sincronizarlos con el archivo XML.
  • Se ha añadido un Descriptor de Python a los campos Selection. Permite definir qué atributo de un modelo contiene la etiqueta de la selección de un registro. Está previsto actualizar todos los informes para que utilicen este descriptor en lugar de valores fijos.
  • Se ha introducido un nuevo formato para el fichero de configuración del servidor. Este formato puede extenderse fácilmente para ser usado por los módulos. Este fichero utiliza el formato de configuración de registros de Python.
  • El contexto definido en los campos relacionados ahora se utiliza para instanciar el destino.
  • La consulta SQL utilizada por el dominio de un campo ahora puede ser personalizada utilizando el método domain_<field>. Este método está diseñado para soportar JOINs y permite definir consultar SQL más eficientes en algunos casos.
  • Las reglas de acceso se han mejorado para que sólo estén activadas en las llamadas RPC. Con este diseño, Tryton sigue el principio de validar los datos en los extremos de la aplicación. De modo que ya no es necesario cambiar al usuario root cuando se necesitan permisos de usuario más específicos a no ser que estemos dentro de una llamada RPC.

Módulos

Account

  • Se ha añadido un nuevo asistente para conciliar apuntes contables. El programa busca para cada cuenta contable y tercero proponiendo apuntes para conciliar. Una funcionalidad que permite aumentar notablemente la velocidad del proceso de conciliación.

    asistente para conciliar
  • También se ha añadido un nuevo asistente para facilitar la creación de asientos de cancelación que concilia automáticamente el apunte con la contrapartida de cancelación.

  • Se ha añadido la opción de 'Tercero requerido' en las cuentas contables. Esta opción obliga introducir el tercero en los apuntes de las cuentas marcadas y prohíbe introducirlo en las otras.

Account Invoice

  • Ahora es posible configurar el redondeo de impuestos tanto a nivel de línea de factura como a nivel global de factura. Por defecto es a nivel global de factura.

Account Payment

  • Se ha incorporado la posibilidad de modificar el estado de los pagos 'Con éxito' a 'Fallado'.

Account Payment SEPA

  • Se habilitado el esquema de empresa a empresa para domiciliaciones bancarias.
  • Ahora los mandatos reciben una identificación única a partir de la secuencia configurada.
  • Se ha adaptado el módulo para las notificaciones de débito/crédito de banco a cliente (CAMT.054).
  • Se ha añadido un informe para imprimir un formulario estándar para los mandatos.

Account Statement

  • Ahora podemos ordenar las líneas de extracto y numerarlas. Una mejora que permite reproducir de forma fiel los extractos bancarios.
  • Se ha añadido un informe de extracto que permite, por ejemplo, repasar los extractos de depósito de cheques.
  • En esta versión se puede definir el método de validación en el diario de extracto. Los métodos disponibles son: Balance,` Importe` y Número de líneas. Esto permite utilizar los extractos para distintos propósitos tales como la conciliación bancaria o el control de depósito de cheques.

Account Stock Continental/Anglo-Saxon

  • Ahora el método se define por ejercicio fiscal en vez de activarse a nivel global en la instalación del módulo.

Country

  • La nueva versión permite almacenar códigos postales por país. Se proporciona un script para descargar códigos postales desde GeoNames.

LDAP Authentication

  • El módulo ldap_connection ha sido sustituido por una entrada en el fichero de configuración de trytond.

Party

  • La nueva funcionalidad de códigos postales del módulo 'Country' se utiliza para el autocompletado de los campos ciudad y código postal de las direcciones.

Purchase

  • El estado Confirmado se ha dividido en dos estados Confirmado y En proceso, para hacerlo similar al proceso de ventas.

Sale Supply Drop Shipment

  • La gestión de las excepciones de los envíos directos de proveedor a cliente se propagan desde la venta hasta la compra.

Nuevos módulos

  • El nuevo módulo Account Payment Clearing permite generar asientos de liquidación entre las cuentas a cobrar o a pagar y la cuenta de liquidación cuando un pago ha tenido éxito. La cuenta de liquidación se concilia posteriormente con los extractos.

Proteus

Proteus es una librería Python para acceder a Tryton como si fuera un cliente.

  • Ahora permite ejecutar informes. Es útil para testearlos.
  • Se ha añadido un nuevo método de duplicado de registros que es similar al menú de copiar del cliente.