Daily updates from Odoo
Friday, March 9, 2018
3 changes · master
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
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-prResolved 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.