diff --git a/README.md b/README.md
index 286cfda7ffee..97557c541e68 100644
--- a/README.md
+++ b/README.md
@@ -23,7 +23,7 @@ addon | version | maintainers | summary
--- | --- | --- | ---
[l10n_br_account](l10n_br_account/) | 15.0.2.10.2 | [](https://github.com/renatonlima) [](https://github.com/rvalyi) | Invoicing and accounting entries for Brazil
[l10n_br_account_due_list](l10n_br_account_due_list/) | 15.0.1.1.0 | | Brazilian Account Due List
-[l10n_br_account_nfe](l10n_br_account_nfe/) | 15.0.1.1.0 | [](https://github.com/antoniospneto) [](https://github.com/felipemotter) [](https://github.com/mbcosta) | Integration between l10n_br_account and l10n_br_nfe
+[l10n_br_account_nfe](l10n_br_account_nfe/) | 15.0.2.0.0 | [](https://github.com/antoniospneto) [](https://github.com/felipemotter) [](https://github.com/mbcosta) | Integration between l10n_br_account and l10n_br_nfe
[l10n_br_account_payment_order](l10n_br_account_payment_order/) | 15.0.1.1.1 | [](https://github.com/mbcosta) | Brazilian Payment Order
[l10n_br_account_withholding](l10n_br_account_withholding/) | 15.0.1.1.0 | [](https://github.com/marcelsavegnago) [](https://github.com/renatonlima) | Brazilian Withholding Invoice Generator
[l10n_br_base](l10n_br_base/) | 15.0.1.0.2 | [](https://github.com/renatonlima) [](https://github.com/rvalyi) | Customization of base module for implementations in Brazil.
@@ -42,8 +42,8 @@ addon | version | maintainers | summary
[l10n_br_hr](l10n_br_hr/) | 15.0.1.0.1 | | Brazilian Localization HR
[l10n_br_ie_search](l10n_br_ie_search/) | 15.0.1.1.0 | | Integração com a API SintegraWS e SEFAZ
[l10n_br_mis_report](l10n_br_mis_report/) | 15.0.1.0.1 | [](https://github.com/mileo) | Templates de relatórios contábeis brasileiros: Balanço Patrimonial e DRE
-[l10n_br_nfe](l10n_br_nfe/) | 15.0.2.3.0 | [](https://github.com/rvalyi) [](https://github.com/renatonlima) | Eletronic Invoicing for Brazil / NF-e
-[l10n_br_nfe_spec](l10n_br_nfe_spec/) | 15.0.1.1.0 | [](https://github.com/rvalyi) | nfe spec
+[l10n_br_nfe](l10n_br_nfe/) | 15.0.3.0.0 | [](https://github.com/rvalyi) [](https://github.com/renatonlima) | Eletronic Invoicing for Brazil / NF-e
+[l10n_br_nfe_spec](l10n_br_nfe_spec/) | 15.0.2.0.0 | [](https://github.com/rvalyi) | nfe spec
[l10n_br_nfse](l10n_br_nfse/) | 15.0.2.0.0 | [](https://github.com/mileo) [](https://github.com/luismalta) [](https://github.com/marcelsavegnago) | Root electronic invoice for service / NFS-e module
[l10n_br_nfse_focus](l10n_br_nfse_focus/) | 15.0.1.1.1 | [](https://github.com/AndreMarcos) [](https://github.com/mileo) [](https://github.com/ygcarvalh) [](https://github.com/marcelsavegnago) | NFS-e (FocusNFE)
[l10n_br_purchase](l10n_br_purchase/) | 15.0.1.3.0 | [](https://github.com/renatonlima) [](https://github.com/rvalyi) | Brazilian Localization Purchase
@@ -52,7 +52,7 @@ addon | version | maintainers | summary
[l10n_br_setup_tests](l10n_br_setup_tests/) | 15.0.1.0.0 | [](https://github.com/antoniospneto) | Modules for Odoo's Brazil-focused usability with integration tests.
[l10n_br_stock](l10n_br_stock/) | 15.0.1.0.1 | | Brazilian Localization Warehouse
[l10n_br_zip](l10n_br_zip/) | 15.0.1.2.0 | [](https://github.com/renatonlima) | Brazilian Localisation ZIP Codes
-[spec_driven_model](spec_driven_model/) | 15.0.1.3.1 | [](https://github.com/rvalyi) | Tools for specifications driven mixins (from xsd for instance)
+[spec_driven_model](spec_driven_model/) | 15.0.2.0.0 | [](https://github.com/rvalyi) | XML binding for Odoo: XML to Odoo models and models to XML.
[//]: # (end addons)
diff --git a/l10n_br_account_nfe/README.rst b/l10n_br_account_nfe/README.rst
index 030cb5552f94..6a1d4cf6bad4 100644
--- a/l10n_br_account_nfe/README.rst
+++ b/l10n_br_account_nfe/README.rst
@@ -7,7 +7,7 @@ Account NFe/NFC-e Integration
!! This file is generated by oca-gen-addon-readme !!
!! changes will be overwritten. !!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
- !! source digest: sha256:6115a8ac3eecbb17aa929592c2a45fc6f461c6ebfc2531cfe413f26782a0db3e
+ !! source digest: sha256:1289c004a36f4245c86667b59e5b13163052482f107466a1b1fc1b0d56822efe
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
.. |badge1| image:: https://img.shields.io/badge/maturity-Beta-yellow.png
diff --git a/l10n_br_account_nfe/__manifest__.py b/l10n_br_account_nfe/__manifest__.py
index 86626d72c6a7..bd6a5097bd64 100644
--- a/l10n_br_account_nfe/__manifest__.py
+++ b/l10n_br_account_nfe/__manifest__.py
@@ -13,7 +13,7 @@
"author": "Engenere," "Akretion," "Odoo Community Association (OCA)",
"maintainers": ["antoniospneto", "felipemotter", "mbcosta"],
"website": "https://github.com/OCA/l10n-brazil",
- "version": "15.0.1.1.0",
+ "version": "15.0.2.0.0",
"development_status": "Beta",
"depends": [
"l10n_br_nfe",
diff --git a/l10n_br_account_nfe/static/description/index.html b/l10n_br_account_nfe/static/description/index.html
index 6f67835bd4e8..b17ce565d7d9 100644
--- a/l10n_br_account_nfe/static/description/index.html
+++ b/l10n_br_account_nfe/static/description/index.html
@@ -367,7 +367,7 @@ Account NFe/NFC-e Integration
!! This file is generated by oca-gen-addon-readme !!
!! changes will be overwritten. !!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
-!! source digest: sha256:6115a8ac3eecbb17aa929592c2a45fc6f461c6ebfc2531cfe413f26782a0db3e
+!! source digest: sha256:1289c004a36f4245c86667b59e5b13163052482f107466a1b1fc1b0d56822efe
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
Português
diff --git a/l10n_br_nfe/README.rst b/l10n_br_nfe/README.rst
index f03c8a55ace4..d8bc15975b6c 100644
--- a/l10n_br_nfe/README.rst
+++ b/l10n_br_nfe/README.rst
@@ -7,7 +7,7 @@ NF-e
!! This file is generated by oca-gen-addon-readme !!
!! changes will be overwritten. !!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
- !! source digest: sha256:639ec51f8a504aafbb1f23980234d05f50d3dfab19ee851c4bde4b014d45d3ba
+ !! source digest: sha256:fefe4395a9e0bab30cdfebf05346907253785c770594bac31aa1c95c89079f4e
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
.. |badge1| image:: https://img.shields.io/badge/maturity-Beta-yellow.png
diff --git a/l10n_br_nfe/__manifest__.py b/l10n_br_nfe/__manifest__.py
index dfc211608f1e..1ee7b4bbd0f7 100644
--- a/l10n_br_nfe/__manifest__.py
+++ b/l10n_br_nfe/__manifest__.py
@@ -11,7 +11,7 @@
"maintainers": ["rvalyi", "renatonlima"],
"website": "https://github.com/OCA/l10n-brazil",
"development_status": "Beta",
- "version": "15.0.2.3.0",
+ "version": "15.0.3.0.0",
"depends": [
"l10n_br_fiscal_edi",
"l10n_br_fiscal_certificate",
diff --git a/l10n_br_nfe/static/description/index.html b/l10n_br_nfe/static/description/index.html
index c1ffd7674398..3435a1b68f48 100644
--- a/l10n_br_nfe/static/description/index.html
+++ b/l10n_br_nfe/static/description/index.html
@@ -367,7 +367,7 @@
NF-e
!! This file is generated by oca-gen-addon-readme !!
!! changes will be overwritten. !!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
-!! source digest: sha256:639ec51f8a504aafbb1f23980234d05f50d3dfab19ee851c4bde4b014d45d3ba
+!! source digest: sha256:fefe4395a9e0bab30cdfebf05346907253785c770594bac31aa1c95c89079f4e
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
Este módulo permite a emissão de NF-e.
diff --git a/l10n_br_nfe_spec/README.rst b/l10n_br_nfe_spec/README.rst
index 39d6418eb375..5121f9cf63d8 100644
--- a/l10n_br_nfe_spec/README.rst
+++ b/l10n_br_nfe_spec/README.rst
@@ -7,7 +7,7 @@ nfe spec
!! This file is generated by oca-gen-addon-readme !!
!! changes will be overwritten. !!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
- !! source digest: sha256:b474a18fa598eb0813552c9201117cfff4a74f83cdbb8901dba20612e5ce97a6
+ !! source digest: sha256:ac16ab7e5e25c15c4fb97123350478b3461e37fbb2e9377a9c80f871103aff94
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
.. |badge1| image:: https://img.shields.io/badge/maturity-Mature-brightgreen.png
diff --git a/l10n_br_nfe_spec/__manifest__.py b/l10n_br_nfe_spec/__manifest__.py
index 370567ba21c0..6216d68ee976 100644
--- a/l10n_br_nfe_spec/__manifest__.py
+++ b/l10n_br_nfe_spec/__manifest__.py
@@ -1,6 +1,6 @@
{
"name": "nfe spec",
- "version": "15.0.1.1.0",
+ "version": "15.0.2.0.0",
"author": "Akretion, Odoo Community Association (OCA)",
"license": "LGPL-3",
"category": "Accounting",
diff --git a/l10n_br_nfe_spec/static/description/index.html b/l10n_br_nfe_spec/static/description/index.html
index ca4e6ab3c1c9..dee619915f68 100644
--- a/l10n_br_nfe_spec/static/description/index.html
+++ b/l10n_br_nfe_spec/static/description/index.html
@@ -367,7 +367,7 @@ nfe spec
!! This file is generated by oca-gen-addon-readme !!
!! changes will be overwritten. !!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
-!! source digest: sha256:b474a18fa598eb0813552c9201117cfff4a74f83cdbb8901dba20612e5ce97a6
+!! source digest: sha256:ac16ab7e5e25c15c4fb97123350478b3461e37fbb2e9377a9c80f871103aff94
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
Este módulo contem a estrutura de dados da Nota Fiscal Electrônica (NF-e).
diff --git a/spec_driven_model/README.rst b/spec_driven_model/README.rst
index 0a3d44265827..6f9a8745fb82 100644
--- a/spec_driven_model/README.rst
+++ b/spec_driven_model/README.rst
@@ -7,7 +7,7 @@ Spec Driven Model
!! This file is generated by oca-gen-addon-readme !!
!! changes will be overwritten. !!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
- !! source digest: sha256:789ee3c15335faefd2f51998edc5a9d6584034031a0236263a33915cc9fa9464
+ !! source digest: sha256:b7beb1b8cae500fcdbdeca06ca2f8159c771946878425c2775645a6324f7ad28
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
.. |badge1| image:: https://img.shields.io/badge/maturity-Beta-yellow.png
@@ -31,7 +31,7 @@ Spec Driven Model
Intro
~~~~~
-This module is a databinding framework for Odoo and XML data: it allows to go from XML to Odoo objects back and forth. This module started with the `GenerateDS `_ pure Python databinding framework and is now being migrated to xsdata. So a good starting point is to read `the xsdata documentation here `_
+This module is a databinding framework for Odoo and XML data: it allows to go from XML to Odoo objects back and forth. While having no hard dependency with it, it has been designed to be used with xsdata. So a good starting point is to read `the xsdata documentation here `_
But what if instead of only generating Python structures from XML files you could actually generate full blown Odoo objects or serialize Odoo objects back to XML? This is what this module is for!
@@ -56,7 +56,7 @@ Now that you have generated these Odoo abstract bindings you should tell Odoo ho
Notice you should inherit from `spec_models.SpecModel` and not the usual `models.Model`.
-**Field mapping**: You can then define two ways mapping between fields by overriding fields from Odoo or from the binding and using `_compute=` , `_inverse=` or simply `related=`.
+**Field mapping**: You can then define two ways mapping between fields by overriding fields from Odoo or from the binding using `_compute=` , `_inverse=` or simply `related=`.
**Relational fields**: simple fields are easily mapped this way. However what about relational fields? In your XSD schema, your electronic invoice is related to the `partner.binding.mixin` not to an Odoo `res.partner`. Don't worry, when `SpecModel` classes are instanciated for all relational fields, we look if their comodel have been injected into some existing Odoo model and if so we remap them to the proper Odoo model.
@@ -66,7 +66,7 @@ Notice you should inherit from `spec_models.SpecModel` and not the usual `models
StackedModel
~~~~~~~~~~~~
-Sadly real life XML is a bit more complex than that. Often XML structures are deeply nested just because it makes it easier for XSD schemas to validate them! for instance an electronic invoice line can be a nested structure with lots of tax details and product details. In a relational model like Odoo however you often want flatter data structures. This is where `StackedModel` comes to the rescue! It inherits from `SpecModel` and when you inherit from `StackedModel` you can inherit from all the generated mixins corresponding to the nested XML tags below some tag (here `invoice.line.binding.mixin`). All the fields corresponding to these XML tag attributes will be collected in your model and the XML parsing and serialization will happen as expected::
+Sadly real life XML is a bit more complex than that. Often XML structures are deeply nested just because it makes it easier for XSD schemas to validate them! for instance an electronic invoice line can be a nested structure with lots of tax details and product details. In a relational model like Odoo however you often want flatter data structures. This is where `StackedModel` comes to the rescue! It inherits from `SpecModel` and when you inherit from `StackedModel` you can inherit from all the generated mixins corresponding to the nested XML tags below some tag (here `invoice.line.binding.mixin`). All the fields corresponding to these XML tag attributes will be collected in your model and the XML parsing and serialization will happen as expected. Here is an example inspired from the Brazilian Electronic Invoice where the schema is called `nfe` and where we use the 2 digits `40` for its short version::
from odoo.addons.spec_driven_model.models import spec_models
@@ -75,17 +75,24 @@ Sadly real life XML is a bit more complex than that. Often XML structures are de
class InvoiceLine(spec_models.StackedModel):
_inherit = [
'account.move.line',
- 'invoice.line.binding.mixin',
+ 'nfe.40.det',
]
- _stacked = 'invoice.line.binding.mixin'
+ _nfe40_spec_settings = {
+ "module": "odoo.addons.l10n_br_nfe_spec.models.v4_0.leiaute_nfe_v4_00",
+ "stacking_mixin": "nfe.40.det",
+ "stacking_points": {},
+ # all m2o below this level will be stacked even if not required:
+ "stacking_force_paths": ("det.imposto.",),
+ "stacking_skip_paths": ("nfe40_det_infNFe_id",),
+ }
-All many2one fields that are required in the XSD (xsd_required=True) will get their model stacked automatically and recursively. You can force non required many2one fields to be stacked using the `_force_stack_paths` attribute. On the contrary, you can avoid some required many2one fields to be stacked using the `stack_skip` attribute.
+All many2one fields that are required in the XSD (xsd_required=True) will get their model stacked automatically and recursively. You can force non required many2one fields to be stacked using the `stacking_force_paths` attribute. On the contrary, you can avoid some required many2one fields to be stacked using the `stacking_skip_paths` attribute.
-Hooks
-~~~~~
+Initialization hook
+~~~~~~~~~~~~~~~~~~~
-Because XSD schemas can define lot's of different models, spec_driven_model comes with handy hooks that will automatically make all XSD mixins turn into concrete Odoo model (eg with a table) if you didn't inject them into existing Odoo models.
+Because XSD schemas can define lot's of different models, spec_driven_model comes with a handy _register_hook that will automatically make all XSD mixins turn into concrete Odoo model (eg with a table) if you didn't inject them into existing Odoo models.
**Table of contents**
diff --git a/spec_driven_model/__manifest__.py b/spec_driven_model/__manifest__.py
index 4dded68f3697..a04f213bc8e6 100644
--- a/spec_driven_model/__manifest__.py
+++ b/spec_driven_model/__manifest__.py
@@ -4,7 +4,7 @@
{
"name": "Spec Driven Model",
"summary": """XML binding for Odoo: XML to Odoo models and models to XML.""",
- "version": "15.0.1.3.1",
+ "version": "15.0.2.0.0",
"maintainers": ["rvalyi"],
"license": "LGPL-3",
"author": "Akretion, Odoo Community Association (OCA)",
diff --git a/spec_driven_model/static/description/index.html b/spec_driven_model/static/description/index.html
index 378a1b7ee56c..1259571ed9d6 100644
--- a/spec_driven_model/static/description/index.html
+++ b/spec_driven_model/static/description/index.html
@@ -367,12 +367,12 @@ Spec Driven Model
!! This file is generated by oca-gen-addon-readme !!
!! changes will be overwritten. !!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
-!! source digest: sha256:789ee3c15335faefd2f51998edc5a9d6584034031a0236263a33915cc9fa9464
+!! source digest: sha256:b7beb1b8cae500fcdbdeca06ca2f8159c771946878425c2775645a6324f7ad28
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
Intro
-
This module is a databinding framework for Odoo and XML data: it allows to go from XML to Odoo objects back and forth. This module started with the GenerateDS pure Python databinding framework and is now being migrated to xsdata. So a good starting point is to read the xsdata documentation here
+
This module is a databinding framework for Odoo and XML data: it allows to go from XML to Odoo objects back and forth. While having no hard dependency with it, it has been designed to be used with xsdata. So a good starting point is to read the xsdata documentation here
But what if instead of only generating Python structures from XML files you could actually generate full blown Odoo objects or serialize Odoo objects back to XML? This is what this module is for!
First you should generate xsdata Python binding libraries you would generate for your specific XSD grammar, the Brazilian Electronic Invoicing for instance, or UBL.
Second you should generate Odoo abstract mixins for all these pure Python bindings. This can be achieved using xsdata-odoo. An example is OCA/l10n-brazil/l10n_br_nfe_spec for the Brazilian Electronic Invoicing.
@@ -391,13 +391,13 @@
SpecModel
]
Notice you should inherit from spec_models.SpecModel and not the usual models.Model.
-
Field mapping: You can then define two ways mapping between fields by overriding fields from Odoo or from the binding and using _compute= , _inverse= or simply related=.
+
Field mapping: You can then define two ways mapping between fields by overriding fields from Odoo or from the binding using _compute= , _inverse= or simply related=.
Relational fields: simple fields are easily mapped this way. However what about relational fields? In your XSD schema, your electronic invoice is related to the partner.binding.mixin not to an Odoo res.partner. Don’t worry, when SpecModel classes are instanciated for all relational fields, we look if their comodel have been injected into some existing Odoo model and if so we remap them to the proper Odoo model.
Field prefixes: to avoid field collision between the Odoo fields and the XSD fields, the XSD fields are prefixed with the name of the schema and a few digits representing the schema version (typically 2 digits). So if your schema get a minor version upgrade, the same fields and classes are used. For a major upgrade however new fields and classes may be used so data of several major versions could co-exist inside your Odoo database.
StackedModel
-
Sadly real life XML is a bit more complex than that. Often XML structures are deeply nested just because it makes it easier for XSD schemas to validate them! for instance an electronic invoice line can be a nested structure with lots of tax details and product details. In a relational model like Odoo however you often want flatter data structures. This is where StackedModel comes to the rescue! It inherits from SpecModel and when you inherit from StackedModel you can inherit from all the generated mixins corresponding to the nested XML tags below some tag (here invoice.line.binding.mixin). All the fields corresponding to these XML tag attributes will be collected in your model and the XML parsing and serialization will happen as expected:
+
Sadly real life XML is a bit more complex than that. Often XML structures are deeply nested just because it makes it easier for XSD schemas to validate them! for instance an electronic invoice line can be a nested structure with lots of tax details and product details. In a relational model like Odoo however you often want flatter data structures. This is where StackedModel comes to the rescue! It inherits from SpecModel and when you inherit from StackedModel you can inherit from all the generated mixins corresponding to the nested XML tags below some tag (here invoice.line.binding.mixin). All the fields corresponding to these XML tag attributes will be collected in your model and the XML parsing and serialization will happen as expected. Here is an example inspired from the Brazilian Electronic Invoice where the schema is called nfe and where we use the 2 digits 40 for its short version:
from odoo.addons.spec_driven_model.models import spec_models
@@ -405,15 +405,22 @@ StackedModel
class InvoiceLine(spec_models.StackedModel):
_inherit = [
'account.move.line',
- 'invoice.line.binding.mixin',
+ 'nfe.40.det',
]
- _stacked = 'invoice.line.binding.mixin'
+ _nfe40_spec_settings = {
+ "module": "odoo.addons.l10n_br_nfe_spec.models.v4_0.leiaute_nfe_v4_00",
+ "stacking_mixin": "nfe.40.det",
+ "stacking_points": {},
+ # all m2o below this level will be stacked even if not required:
+ "stacking_force_paths": ("det.imposto.",),
+ "stacking_skip_paths": ("nfe40_det_infNFe_id",),
+ }
-
All many2one fields that are required in the XSD (xsd_required=True) will get their model stacked automatically and recursively. You can force non required many2one fields to be stacked using the _force_stack_paths attribute. On the contrary, you can avoid some required many2one fields to be stacked using the stack_skip attribute.
+
All many2one fields that are required in the XSD (xsd_required=True) will get their model stacked automatically and recursively. You can force non required many2one fields to be stacked using the stacking_force_paths attribute. On the contrary, you can avoid some required many2one fields to be stacked using the stacking_skip_paths attribute.
-
-
Hooks
-
Because XSD schemas can define lot’s of different models, spec_driven_model comes with handy hooks that will automatically make all XSD mixins turn into concrete Odoo model (eg with a table) if you didn’t inject them into existing Odoo models.
+
+
Initialization hook
+
Because XSD schemas can define lot’s of different models, spec_driven_model comes with a handy _register_hook that will automatically make all XSD mixins turn into concrete Odoo model (eg with a table) if you didn’t inject them into existing Odoo models.
Table of contents