Daily updates from Odoo
Navigate
Branch
Friday, March 9, 2018
7 changes
New functionality added to Odoo
Mexican electronic invoices now use SAT-defined decimal limits for each currency and a fixed precision for exchange rates. This helps invoices comply with Mexican tax authority requirements and reduces validation issues when using currencies with different decimal rules.
Original PR description
According to the SAT, amounts in the CFDI must have a specific maximum of decimal digits, which depends on the currency of that amount. For this purpose, the SAT provides a catalog, where a list of…
According to the SAT, amounts in the CFDI must have a specific maximum of decimal digits, which depends on the currency of that amount. For this purpose, the SAT provides a catalog, where a list of currencies are provided along with their number of allowed decimal digits (named `c_moneda`). [SAT Catalog](http://www.sat.gob.mx/informacion_fiscal/factura_electronica/Documents/catCFDI.xls) This change adds a new field to the res.currency model to store the maximum number of decimal digits, and adds the data provided by the SAT's catalog. The following currencies are not included because there is a mismatch between the currencies supported in the SAT's catalog and the ones supported by Odoo: - SDG: was put out of circulation in 2007, SDD is now used. - SRD: not supported yet in Odoo, still supporting SRG, even though the currency change took place in 2004 - TMT: not supported yet in Odoo, still supporting TMM, even though the currency change took place in 2009 - ZMW: not supported yet in Odoo, still supporting ZMK, even though the currency change took place in 2012 - ZWL: not supported yet in Odoo, still supporting ZWD
Enhancements to existing features
This update makes certain error messages easier to understand by showing cleaner names and clearer module file paths. It helps support teams and developers identify configuration problems faster, reducing time spent diagnosing module issues.
Original PR description
Description of the issue/feature this PR addresses: Modified exception message with `(name, None)` to `name` when raise exception using subclass. And print the full path of `MANIFEST_NAMES` using `manifest_file`, to identify the module path. Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now filter partner records to find those with a VAT number more easily. This helps teams review customer or supplier tax information faster and supports cleaner partner data management.
Original PR description
In this branch we add the filter option by partner with vat number.
Odoo now keeps field references from each module that defines the same field. This prevents screens or views from breaking when one module is removed while another module still depends on that shared field.
Original PR description
Given the following variables: * Module A * Module B * Model M * Field X of model M If module A defines M.X and is installed, an xmlid for this field is generated in the form of A.field_M_X Before…
Given the following variables:
* Module A
* Module B
* Model M
* Field X of model M
If module A defines M.X and is installed, an xmlid for this field is
generated in the form of A.field_M_X
Before this commit:
If module B defines M.X as well and is installed after module A, no
xmlid is generated.
This means that if module A is uninstalled, the single xmlid pointing to
M.X will be deleted and thus, the field itself will be deleted as well,
therefore any views from module B referencing M.X will crash.
After this commit:
If module B (or any subsequent modules) define M.X, an xmlid will be
generated in the form of B.field_M_X.
If module A is uninstalled, the xmlid A.field_M_X will be deleted, but
B.field_M_X will remain and thus the field itself won't be deleted.
This system means that for a single actual field, there can be multiple
xmlids, each xmlid sharing the same field, thus the name "shared
fields".
Task ID 38016
Task link: https://www.odoo.com/web#id=38016&view_type=form&model=project.task&action=333&active_id=133&menu_id=4720
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prScheduled background jobs now report how many tasks ran successfully, how many failed, and when the next job is due. This improves operational visibility and helps the server make better decisions about when to check for upcoming automated work.
Original PR description
…time _acquire_job() now returns the following: - success: number of successfully triggered jobs - failed: number of failed triggered jobs - nextcall: minimum nextcall value from active ir_cron - nextcall_epoch: same as above as epoch Also, _acquire_job() was not returning anything, however some code was acting as is (probably due to historic refactoring), this explains the changes in server.py Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Fixes an issue where creating a credit note did not properly refund the original invoice. This helps ensure customer credits and accounting records reflect the intended refund action.
This fixes an accounting issue where creating a new payment from the Accounting Dashboard could use the wrong records behind the scenes. The change ensures payments only look at invoice records when the action actually comes from invoices, helping avoid incorrect behavior or errors for accounting users.
Original PR description
Issue: https://www.odoo.com/web?#id=1824893&view_type=form&model=project.task&action=333&active_id=1278&menu_id=4720 Pad: https://pad.odoo.com/p/r.9512941eaa8a46f1c43b38172968de2f -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr