Module: spec_driven_model - Odoo Module Metadata

TIP: You can type at any time to perform a new search.

Spec Driven Model

spec_driven_model

REPOSITORY
REPOSITORY	OCA/l10n-brazil
GIT
GIT	https://github.com/OCA/l10n-brazil.git
GIT FOLDER
GIT FOLDER	https://github.com/OCA/l10n-brazil/tree/18.0/spec_driven_model
VERSION
VERSION	1.1.2
CATEGORY
CATEGORY	Uncategorized
LICENSE
LICENSE	LGPL-3
APPLICATION
APPLICATION	No
AUTO-INSTALLABLE
AUTO-INSTALLABLE	No
AUTHORS
AUTHORS	Odoo Community Association (OCA), Akretion
MAINTAINERS
MAINTAINERS	Odoo Community Association (OCA), Akretion
COMMITTERS
COMMITTERS	Raphaël Valyi, OCA-git-bot, oca-ci
WEBSITE
WEBSITE	https://github.com/OCA/l10n-brazil
LAST TRACKING UPDATE
LAST TRACKING UPDATE	2026-07-06 19:30:09
ODOO DEPENDENCIES
ODOO DEPENDENCIES
PYTHON DEPENDENCIES
PYTHON DEPENDENCIES	Not have
SYSTEM DEPENDENCIES
SYSTEM DEPENDENCIES	Not have
DESCRIPTION
DESCRIPTION	## Intro 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 along with xsdata. So a good starting point is to read [the xsdata documentation here](https://xsdata.readthedocs.io/). 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 or any XSD files... Second you should generate Odoo abstract mixins for all these pure Python bindings. This can be achieved using [xsdata-odoo](https://github.com/akretion/xsdata-odoo). An example is OCA/l10n-brazil/l10n_br_nfe_spec for the Brazilian Electronic Invoicing. ## SpecModel Now that you have generated these Odoo abstract bindings you should tell Odoo how to use them. For instance you may want that your abstract model for the recipient of the electronic invoice matches the Odoo `res.partner` object. This is fairly easy, you mostly need to define an override like: ```python from odoo.addons.spec_driven_model.models import spec_models class ResPartner(spec_models.SpecModel): _inherit = [ 'res.partner', 'partner.binding.mixin', ] ``` 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 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 instead. 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: ```python from odoo.addons.spec_driven_model.models import spec_models class InvoiceLine(spec_models.StackedModel): _inherit = [ 'account.move.line', 'nfe.40.det', ] _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 also 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. ## Initialization hook Because XSD schemas can define lot's of different models, spec_driven_model comes with a handy `_register_hook` override (in `spec.mixin`) 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 already.

Code Analysis

Views touched (0)

No views found for this module.

Models touched (5)

New fields (0)

No new fields.

Public methods (1)

spec_module_classes(cls, spec_module)
@classmethod

Cache the list of spec_module classes to save calls to slow reflection API.

New fields (0)

No new fields.

Public methods (0)

No public methods.

New fields (0)

No new fields.

Public methods (0)

No public methods.

New fields (0)

No new fields.

Public methods (4)

build_attrs(self, node, path='', defaults_model=None)
@api.model

Build a new odoo model instance from a Python binding element or sub-element. Iterates over the binding fields to populate the Odoo fields.
build_from_binding(self, spec_schema, spec_version, binding, dry_run=False)
@api.model

Build an instance of an Odoo Model from a pre-populated Python binding object. Binding object such as the ones generated using xsdata can indeed be automatically populated from an XML file. This build method bridges the gap to build the Odoo object. It uses a pre-order tree traversal of the Python bindings and for each sub-binding (or node) it sees what is the corresponding Odoo model to map. Build can persist the object or just return a new instance depending on the dry_run parameter. Defaults values and control options are meant to be passed in the context.
match_or_create_m2o(self, rec_dict, parent_dict, model=None)
@api.model

Often the parent_dict can be used to refine the search. Passing the model makes it possible to override without inheriting from this mixin.
match_record(self, rec_dict, parent_dict, model=None)
@api.model

Inspired from match_* methods from https://github.com/OCA/edi/blob/11.0/base_business_document_import /models/business_document_import.py

New fields (0)

No new fields.

Public methods (2)

build_arch(self, lib_node, view_node, fields, depth=0)
@api.model

Creates a view arch from an xsdata lib model arch
fields_view_get(self, view_id=None, view_type='form', toolbar=False, submenu=False)
@api.model

REPOSITORY
REPOSITORY	OCA/l10n-brazil
GIT
GIT	https://github.com/OCA/l10n-brazil.git
GIT FOLDER
GIT FOLDER	https://github.com/OCA/l10n-brazil/tree/17.0/spec_driven_model
VERSION
VERSION	1.1.1
CATEGORY
CATEGORY	Uncategorized
LICENSE
LICENSE	LGPL-3
APPLICATION
APPLICATION	No
AUTO-INSTALLABLE
AUTO-INSTALLABLE	No
AUTHORS
AUTHORS	Odoo Community Association (OCA), Akretion
MAINTAINERS
MAINTAINERS	Odoo Community Association (OCA), Akretion
COMMITTERS
COMMITTERS	Raphaël Valyi, OCA-git-bot, oca-ci
WEBSITE
WEBSITE	https://github.com/OCA/l10n-brazil
LAST TRACKING UPDATE
LAST TRACKING UPDATE	2026-07-06 19:20:03
ODOO DEPENDENCIES
ODOO DEPENDENCIES
PYTHON DEPENDENCIES
PYTHON DEPENDENCIES	Not have
SYSTEM DEPENDENCIES
SYSTEM DEPENDENCIES	Not have
DESCRIPTION
DESCRIPTION	## Intro 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 along with xsdata. So a good starting point is to read [the xsdata documentation here](https://xsdata.readthedocs.io/). 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 or any XSD files... Second you should generate Odoo abstract mixins for all these pure Python bindings. This can be achieved using [xsdata-odoo](https://github.com/akretion/xsdata-odoo). An example is OCA/l10n-brazil/l10n_br_nfe_spec for the Brazilian Electronic Invoicing. ## SpecModel Now that you have generated these Odoo abstract bindings you should tell Odoo how to use them. For instance you may want that your abstract model for the recipient of the electronic invoice matches the Odoo `res.partner` object. This is fairly easy, you mostly need to define an override like: ```python from odoo.addons.spec_driven_model.models import spec_models class ResPartner(spec_models.SpecModel): _inherit = [ 'res.partner', 'partner.binding.mixin', ] ``` 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 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 instead. 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: ```python from odoo.addons.spec_driven_model.models import spec_models class InvoiceLine(spec_models.StackedModel): _inherit = [ 'account.move.line', 'nfe.40.det', ] _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 also 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. ## Initialization hook Because XSD schemas can define lot's of different models, spec_driven_model comes with a handy `_register_hook` override (in `spec.mixin`) 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 already.

Code Analysis

Views touched (0)

No views found for this module.

Models touched (5)

New fields (0)

No new fields.

Public methods (1)

spec_module_classes(cls, spec_module)
@classmethod

Cache the list of spec_module classes to save calls to slow reflection API.

New fields (0)

No new fields.

Public methods (0)

No public methods.

New fields (0)

No new fields.

Public methods (0)

No public methods.

New fields (0)

No new fields.

Public methods (4)

build_attrs(self, node, path='', defaults_model=None)
@api.model

Build a new odoo model instance from a Python binding element or sub-element. Iterates over the binding fields to populate the Odoo fields.
build_from_binding(self, spec_schema, spec_version, binding, dry_run=False)
@api.model

Build an instance of an Odoo Model from a pre-populated Python binding object. Binding object such as the ones generated using xsdata can indeed be automatically populated from an XML file. This build method bridges the gap to build the Odoo object. It uses a pre-order tree traversal of the Python bindings and for each sub-binding (or node) it sees what is the corresponding Odoo model to map. Build can persist the object or just return a new instance depending on the dry_run parameter. Defaults values and control options are meant to be passed in the context.
match_or_create_m2o(self, rec_dict, parent_dict, model=None)
@api.model

Often the parent_dict can be used to refine the search. Passing the model makes it possible to override without inheriting from this mixin.
match_record(self, rec_dict, parent_dict, model=None)
@api.model

Inspired from match_* methods from https://github.com/OCA/edi/blob/11.0/base_business_document_import /models/business_document_import.py

New fields (0)

No new fields.

Public methods (2)

build_arch(self, lib_node, view_node, fields, depth=0)
@api.model

Creates a view arch from an xsdata lib model arch
fields_view_get(self, view_id=None, view_type='form', toolbar=False, submenu=False)
@api.model

REPOSITORY
REPOSITORY	OCA/l10n-brazil
GIT
GIT	https://github.com/OCA/l10n-brazil.git
GIT FOLDER
GIT FOLDER	https://github.com/OCA/l10n-brazil/tree/16.0/spec_driven_model
VERSION
VERSION	3.0.0
CATEGORY
CATEGORY	Uncategorized
LICENSE
LICENSE	LGPL-3
APPLICATION
APPLICATION	No
AUTO-INSTALLABLE
AUTO-INSTALLABLE	No
AUTHORS
AUTHORS	Odoo Community Association (OCA), Akretion
MAINTAINERS
MAINTAINERS	Odoo Community Association (OCA), Akretion
COMMITTERS
COMMITTERS	Raphaël Valyi, Weblate, OCA-git-bot, oca-ci, Antonio Neto, Antônio Neto, CristianoMafraJunior
WEBSITE
WEBSITE	https://github.com/OCA/l10n-brazil
LAST TRACKING UPDATE
LAST TRACKING UPDATE	2026-07-06 19:11:56
ODOO DEPENDENCIES
ODOO DEPENDENCIES
PYTHON DEPENDENCIES
PYTHON DEPENDENCIES	Not have
SYSTEM DEPENDENCIES
SYSTEM DEPENDENCIES	Not have
DESCRIPTION
DESCRIPTION	## Intro 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 along with xsdata. So a good starting point is to read [the xsdata documentation here](https://xsdata.readthedocs.io/). 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 or any XSD files... Second you should generate Odoo abstract mixins for all these pure Python bindings. This can be achieved using [xsdata-odoo](https://github.com/akretion/xsdata-odoo). An example is OCA/l10n-brazil/l10n_br_nfe_spec for the Brazilian Electronic Invoicing. ## SpecModel Now that you have generated these Odoo abstract bindings you should tell Odoo how to use them. For instance you may want that your abstract model for the recipient of the electronic invoice matches the Odoo `res.partner` object. This is fairly easy, you mostly need to define an override like: ```python from odoo.addons.spec_driven_model.models import spec_models class ResPartner(spec_models.SpecModel): _inherit = [ 'res.partner', 'partner.binding.mixin', ] ``` 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 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 instead. 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: ```python from odoo.addons.spec_driven_model.models import spec_models class InvoiceLine(spec_models.StackedModel): _inherit = [ 'account.move.line', 'nfe.40.det', ] _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 also 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. ## Initialization hook Because XSD schemas can define lot's of different models, spec_driven_model comes with a handy `_register_hook` override (in `spec.mixin`) 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 already.

Code Analysis

Views touched (0)

No views found for this module.

Models touched (5)

New fields (0)

No new fields.

Public methods (1)

spec_module_classes(cls, spec_module)
@classmethod

Cache the list of spec_module classes to save calls to slow reflection API.

New fields (0)

No new fields.

Public methods (0)

No public methods.

New fields (0)

No new fields.

Public methods (0)

No public methods.

New fields (0)

No new fields.

Public methods (4)

build_attrs(self, node, path='', defaults_model=None)
@api.model

Build a new odoo model instance from a Python binding element or sub-element. Iterates over the binding fields to populate the Odoo fields.
build_from_binding(self, spec_schema, spec_version, binding, dry_run=False)
@api.model

Build an instance of an Odoo Model from a pre-populated Python binding object. Binding object such as the ones generated using xsdata can indeed be automatically populated from an XML file. This build method bridges the gap to build the Odoo object. It uses a pre-order tree traversal of the Python bindings and for each sub-binding (or node) it sees what is the corresponding Odoo model to map. Build can persist the object or just return a new instance depending on the dry_run parameter. Defaults values and control options are meant to be passed in the context.
match_or_create_m2o(self, rec_dict, parent_dict, model=None)
@api.model

Often the parent_dict can be used to refine the search. Passing the model makes it possible to override without inheriting from this mixin.
match_record(self, rec_dict, parent_dict, model=None)
@api.model

Inspired from match_* methods from https://github.com/OCA/edi/blob/11.0/base_business_document_import /models/business_document_import.py

New fields (0)

No new fields.

Public methods (2)

build_arch(self, lib_node, view_node, fields, depth=0)
@api.model

Creates a view arch from an xsdata lib model arch
fields_view_get(self, view_id=None, view_type='form', toolbar=False, submenu=False)
@api.model

REPOSITORY
REPOSITORY	OCA/l10n-brazil
GIT
GIT	https://github.com/OCA/l10n-brazil.git
GIT FOLDER
GIT FOLDER	https://github.com/OCA/l10n-brazil/tree/15.0/spec_driven_model
VERSION
VERSION	2.1.0
CATEGORY
CATEGORY	Uncategorized
LICENSE
LICENSE	LGPL-3
APPLICATION
APPLICATION	No
AUTO-INSTALLABLE
AUTO-INSTALLABLE	No
AUTHORS
AUTHORS	Odoo Community Association (OCA), Akretion
MAINTAINERS
MAINTAINERS	Odoo Community Association (OCA), Akretion
COMMITTERS
COMMITTERS	Raphaël Valyi, Weblate, OCA-git-bot, oca-ci
WEBSITE
WEBSITE	https://github.com/OCA/l10n-brazil
LAST TRACKING UPDATE
LAST TRACKING UPDATE	2026-07-06 00:46:31
ODOO DEPENDENCIES
ODOO DEPENDENCIES
PYTHON DEPENDENCIES
PYTHON DEPENDENCIES	Not have
SYSTEM DEPENDENCIES
SYSTEM DEPENDENCIES	Not have
DESCRIPTION
DESCRIPTION

Code Analysis

Views touched (0)

No views found for this module.

Models touched (5)

New fields (0)

No new fields.

Public methods (1)

spec_module_classes(cls, spec_module)
@classmethod

Cache the list of spec_module classes to save calls to slow reflection API.

New fields (0)

No new fields.

Public methods (0)

No public methods.

New fields (0)

No new fields.

Public methods (0)

No public methods.

New fields (0)

No new fields.

Public methods (4)

build_attrs(self, node, path='', defaults_model=None)
@api.model

Build a new odoo model instance from a Python binding element or sub-element. Iterates over the binding fields to populate the Odoo fields.
build_from_binding(self, spec_schema, spec_version, node, dry_run=False)
@api.model

Build an instance of an Odoo Model from a pre-populated Python binding object. Binding object such as the ones generated using xsdata can indeed be automatically populated from an XML file. This build method bridges the gap to build the Odoo object. It uses a pre-order tree traversal of the Python bindings and for each sub-binding (or node) it sees what is the corresponding Odoo model to map. Build can persist the object or just return a new instance depending on the dry_run parameter. Defaults values and control options are meant to be passed in the context.
match_or_create_m2o(self, rec_dict, parent_dict, model=None)
@api.model

Often the parent_dict can be used to refine the search. Passing the model makes it possible to override without inheriting from this mixin.
match_record(self, rec_dict, parent_dict, model=None)
@api.model

Inspired from match_* methods from https://github.com/OCA/edi/blob/11.0/base_business_document_import /models/business_document_import.py

New fields (0)

No new fields.

Public methods (2)

build_arch(self, lib_node, view_node, fields, depth=0)
@api.model

Creates a view arch from an xsdata lib model arch
fields_view_get(self, view_id=None, view_type='form', toolbar=False, submenu=False)
@api.model

REPOSITORY
REPOSITORY	OCA/l10n-brazil
GIT
GIT	https://github.com/OCA/l10n-brazil.git
GIT FOLDER
GIT FOLDER	https://github.com/OCA/l10n-brazil/tree/14.0/spec_driven_model
VERSION
VERSION	6.1.0
CATEGORY
CATEGORY	Uncategorized
LICENSE
LICENSE	LGPL-3
APPLICATION
APPLICATION	No
AUTO-INSTALLABLE
AUTO-INSTALLABLE	No
AUTHORS
AUTHORS	Odoo Community Association (OCA), Akretion
MAINTAINERS
MAINTAINERS	Odoo Community Association (OCA), Akretion
COMMITTERS
COMMITTERS	Raphaël Valyi, Renato Lima, OCA Transbot, Luis Felipe Miléo, oca-travis, Weblate, OCA-git-bot, Magno Costa, oca-ci, Marcel Savegnago, Neto, Renan Hiroki Bastos, Antônio Neto
WEBSITE
WEBSITE	https://github.com/OCA/l10n-brazil
LAST TRACKING UPDATE
LAST TRACKING UPDATE	2026-07-06 00:40:54
ODOO DEPENDENCIES
ODOO DEPENDENCIES
PYTHON DEPENDENCIES
PYTHON DEPENDENCIES	Not have
SYSTEM DEPENDENCIES
SYSTEM DEPENDENCIES	Not have
DESCRIPTION
DESCRIPTION

Code Analysis

Views touched (0)

No views found for this module.

Models touched (5)

New fields (0)

No new fields.

Public methods (1)

spec_module_classes(cls, spec_module)
@classmethod

Cache the list of spec_module classes to save calls to slow reflection API.

New fields (0)

No new fields.

Public methods (0)

No public methods.

New fields (0)

No new fields.

Public methods (0)

No public methods.

New fields (0)

No new fields.

Public methods (4)

build_attrs(self, node, path='', defaults_model=None)
@api.model

Build a new odoo model instance from a Python binding element or sub-element. Iterates over the binding fields to populate the Odoo fields.
build_from_binding(self, spec_schema, spec_version, node, dry_run=False)
@api.model

Build an instance of an Odoo Model from a pre-populated Python binding object. Binding object such as the ones generated using xsdata can indeed be automatically populated from an XML file. This build method bridges the gap to build the Odoo object. It uses a pre-order tree traversal of the Python bindings and for each sub-binding (or node) it sees what is the corresponding Odoo model to map. Build can persist the object or just return a new instance depending on the dry_run parameter. Defaults values and control options are meant to be passed in the context.
match_or_create_m2o(self, rec_dict, parent_dict, model=None)
@api.model

Often the parent_dict can be used to refine the search. Passing the model makes it possible to override without inheriting from this mixin.
match_record(self, rec_dict, parent_dict, model=None)
@api.model

Inspired from match_* methods from https://github.com/OCA/edi/blob/11.0/base_business_document_import /models/business_document_import.py

New fields (0)

No new fields.

Public methods (2)

build_arch(self, lib_node, view_node, fields, depth=0)
@api.model

Creates a view arch from an xsdata lib model arch
fields_view_get(self, view_id=None, view_type='form', toolbar=False, submenu=False)
@api.model

REPOSITORY
REPOSITORY	OCA/l10n-brazil
GIT
GIT	https://github.com/OCA/l10n-brazil.git
GIT FOLDER
GIT FOLDER	https://github.com/OCA/l10n-brazil/tree/13.0/spec_driven_model
VERSION
VERSION	1.0.0
CATEGORY
CATEGORY	Uncategorized
LICENSE
LICENSE	LGPL-3
APPLICATION
APPLICATION	No
AUTO-INSTALLABLE
AUTO-INSTALLABLE	No
AUTHORS
AUTHORS	Odoo Community Association (OCA), Akretion
MAINTAINERS
MAINTAINERS	Odoo Community Association (OCA), Akretion
COMMITTERS
COMMITTERS	Raphaël Valyi, oca-travis, Weblate
WEBSITE
WEBSITE	https://github.com/OCA/l10n-brazil
LAST TRACKING UPDATE
LAST TRACKING UPDATE	2026-07-06 00:34:11
ODOO DEPENDENCIES
ODOO DEPENDENCIES
PYTHON DEPENDENCIES
PYTHON DEPENDENCIES	odoo_test_helper
SYSTEM DEPENDENCIES
SYSTEM DEPENDENCIES	Not have
DESCRIPTION
DESCRIPTION

Code Analysis

Views touched (0)

No views found for this module.

Models touched (5)

New fields (0)

No new fields.

Public methods (5)

build(self, node, dry_run=False)
@api.model

Builds an instance of an Odoo Model from a pre-populated Python binding object. Binding object such as the ones generated using generateDS can indeed be automatically populated from an XML file. This build method bridges the gap to build the Odoo object. It uses a pre-order tree traversal of the Python bindings and for each sub-binding (or node) it sees what is the corresponding Odoo model to map. Build can persist the object or just return a new instance depending on the dry_run parameter. Defaults values and control options are meant to be passed in the context.
build_attrs(self, node, path='')
@api.model

Builds a new odoo model instance from a Python binding element or sub-element. Iterates over the binding fields to populate the Odoo fields.
get_concrete_model(self, comodel_name)
@api.model

Lookup for concrete models where abstract schema mixins were injected
match_or_create_m2o(self, rec_dict, parent_dict, model=None)
@api.model

Often the parent_dict can be used to refine the search. Passing the model makes it possible to override without inheriting from this mixin.
match_record(self, rec_dict, parent_dict, model=None)
@api.model

Inspired from match_* methods from https://github.com/OCA/edi/blob/11.0/base_business_document_import /models/business_document_import.py

New fields (0)

No new fields.

Public methods (1)

spec_module_classes(cls, spec_module)
@classmethod

Cache the list of spec_module classes to save calls to slow reflection API.

New fields (0)

No new fields.

Public methods (0)

No public methods.

New fields (0)

No new fields.

Public methods (2)

build_arch(self, lib_node, view_node, fields, depth=0)
@api.model

Creates a view arch from an generateds lib model arch
fields_view_get(self, view_id=None, view_type='form', toolbar=False, submenu=False)
@api.model

New fields (0)

No new fields.

Public methods (2)

export_ds(self)
export_xml(self, print_xml=True)

REPOSITORY
REPOSITORY	OCA/l10n-brazil
GIT
GIT	https://github.com/OCA/l10n-brazil.git
GIT FOLDER
GIT FOLDER	https://github.com/OCA/l10n-brazil/tree/12.0/spec_driven_model
VERSION
VERSION	5.0.1
CATEGORY
CATEGORY	Uncategorized
LICENSE
LICENSE	LGPL-3
APPLICATION
APPLICATION	No
AUTO-INSTALLABLE
AUTO-INSTALLABLE	No
AUTHORS
AUTHORS	Odoo Community Association (OCA), Akretion
MAINTAINERS
MAINTAINERS	Odoo Community Association (OCA), Akretion
COMMITTERS
COMMITTERS	Raphaël Valyi, Renato Lima, Luis Felipe Mileo, oca-travis, Weblate, OCA-git-bot, Gabriel Cardoso de Faria, Marcel Savegnago, Renan Hiroki Bastos
WEBSITE
WEBSITE	https://github.com/OCA/l10n-brazil
LAST TRACKING UPDATE
LAST TRACKING UPDATE	2026-07-06 00:29:15
ODOO DEPENDENCIES
ODOO DEPENDENCIES
PYTHON DEPENDENCIES
PYTHON DEPENDENCIES	Not have
SYSTEM DEPENDENCIES
SYSTEM DEPENDENCIES	Not have
DESCRIPTION
DESCRIPTION

Code Analysis

Views touched (0)

No views found for this module.

Models touched (5)

New fields (0)

No new fields.

Public methods (5)

build_attrs(self, node, path='', defaults_model=None)
@api.model

Builds a new odoo model instance from a Python binding element or sub-element. Iterates over the binding fields to populate the Odoo fields.
build_from_binding(self, node, dry_run=False)
@api.model

Builds an instance of an Odoo Model from a pre-populated Python binding object. Binding object such as the ones generated using generateDS can indeed be automatically populated from an XML file. This build method bridges the gap to build the Odoo object. It uses a pre-order tree traversal of the Python bindings and for each sub-binding (or node) it sees what is the corresponding Odoo model to map. Build can persist the object or just return a new instance depending on the dry_run parameter. Defaults values and control options are meant to be passed in the context.
get_concrete_model(self, comodel_name)
@api.model

Lookup for concrete models where abstract schema mixins were injected
match_or_create_m2o(self, rec_dict, parent_dict, model=None)
@api.model

Often the parent_dict can be used to refine the search. Passing the model makes it possible to override without inheriting from this mixin.
match_record(self, rec_dict, parent_dict, model=None)
@api.model

Inspired from match_* methods from https://github.com/OCA/edi/blob/11.0/base_business_document_import /models/business_document_import.py

New fields (0)

No new fields.

Public methods (1)

spec_module_classes(cls, spec_module)
@classmethod

Cache the list of spec_module classes to save calls to slow reflection API.

New fields (0)

No new fields.

Public methods (0)

No public methods.

New fields (0)

No new fields.

Public methods (2)

build_arch(self, lib_node, view_node, fields, depth=0)
@api.model

Creates a view arch from an generateds lib model arch
fields_view_get(self, view_id=None, view_type='form', toolbar=False, submenu=False)
@api.model

New fields (0)

No new fields.

Public methods (2)

export_ds(self)
export_xml(self, print_xml=True)

Spec Driven Model

Code Analysis

Views touched (0)

Models touched (5)

spec.mixin_export New model AbstractModel 0 fields 0 methods SpecMixinExport · A mixin providing serialization features.

spec.mixin_view New model AbstractModel 0 fields 2 methods SpecViewMixin

Code Analysis

Views touched (0)

Models touched (5)

spec.mixin_export New model AbstractModel 0 fields 0 methods SpecMixinExport · A mixin providing serialization features.

spec.mixin_view New model AbstractModel 0 fields 2 methods SpecViewMixin

Code Analysis

Views touched (0)

Models touched (5)

spec.mixin_export New model AbstractModel 0 fields 0 methods SpecMixinExport · A mixin providing serialization features.

spec.mixin_view New model AbstractModel 0 fields 2 methods SpecViewMixin

Code Analysis

Views touched (0)

Models touched (5)

spec.mixin_export New model AbstractModel 0 fields 0 methods SpecMixinExport · A mixin providing serialization features.

spec.mixin_view New model AbstractModel 0 fields 2 methods SpecViewMixin

Code Analysis

Views touched (0)

Models touched (5)

spec.mixin_export New model AbstractModel 0 fields 0 methods SpecMixinExport · A mixin providing serialization features.

spec.mixin_view New model AbstractModel 0 fields 2 methods SpecViewMixin

Code Analysis

Views touched (0)

Models touched (5)

spec.mixin New model AbstractModel 0 fields 0 methods SpecMixin · root abstract model meant for xsd generated fiscal models putting this mixin here makes it possible for generated schemas mixins to be installed without depending on the fiscal module.

spec.mixin Extends AbstractModel 0 fields 2 methods SpecViewMixin · inherits spec.mixin

spec.mixin Extends AbstractModel 0 fields 2 methods AbstractSpecMixin · inherits spec.mixin

Code Analysis

Views touched (0)

Models touched (5)

spec.mixin New model AbstractModel 0 fields 0 methods SpecMixin · root abstract model meant for xsd generated fiscal models putting this mixin here makes it possible for generated schemas mixins to be installed without depending on the fiscal module.

spec.mixin Extends AbstractModel 0 fields 2 methods SpecViewMixin · inherits spec.mixin

spec.mixin Extends AbstractModel 0 fields 2 methods AbstractSpecMixin · inherits spec.mixin