[8.0] res.partner and italian localization

[gigidn]

2 module implement some useful extension .. pec and ateco.

But i need extension to fulfill the requirement of the fatturaPA module but this extension should be useful for other module like for example spesometro.

I mean:

1.2.4
1.2.4.1
1.2.4.3
1.2.4.4
1.2.4.5

1.2.1.8

The question is ... the right approach .. implement this extension inside the fatturaPA module or make a single filed extension or make a generic module whit all this extension and maybe pec+ateco?

[eLBati]

What extensions are you referring to?

[gigidn]

i don't know what happen at my post ... something whit enclosure .... the extension are:

On res.partner:

CodEORI
CodIPA

On Company:

REA:
Ufficio - String
NumeroREA - Integer

CapitaleSociale - Integer
SocioUnico - Boolean
StatoLiquidazione - Boolean

RegimeFiscale - Special Code

[eLBati]

In this case I think we should make 3 modules.

• base_eori as it is an European concept, it should probably be added to https://github.com/OCA/stock-logistics-workflow
• l10n_it_ipa adds IPA code to partner
• l10n_it_company_fiscal_data adds the above extra fields to company

[gigidn]

Ummm .. i agree except for base_eori, if we put this field inside the module stock-logistic we make dependence of the fatturaPA module and this module only for the extra field.

Maybe better make an extra-field module only whit base_eori and let the modules (stock-logistic and fatturaPA) force the dependence on this?

[eLBati]

https://github.com/OCA/stock-logistics-workflow is not a module, it is a repository. The module would be named base_eori and it would only contain the extra field (maybe later a code validation could be added)

[eLBati]

l10n_it_ipa #52

[dcorio]

i'm actually not in favor of having new modules that add just a field. unless this field brings some complexity.
just like l10n_it_pec. can't we put this kind of fields in l10n_it_base?

[eLBati]

@dcorio in general I think modules that add just a field should be avoided when such a field can be added manually or through a custom module.
In this case other modules will need this field, so we have to add it. I don't see advantages in adding it to l10n_it_base instead of l10n_it_ipa. I see a disadvantage: installing l10n_it_base users will install fields that maybe they don't need.
Eventually, in case, we could add to l10n_it_ipa some integration with http://www.indicepa.gov.it

[gigidn]

In general i agree whit @dcorio becouse this will grow the number of modules. But in this case i agree whit @eLBati because the field maybe is mandatory for different modules (all the module that interact whit PA) and later we could add extra logic for autocomplete partner based on indicepa and validate the code. This is in my personal plan for future release of the module, but at the moment i need only the filed for the other module.

I'm not sure on fiscal_data module, because this filed are in many cases mandatory for the italian low .. but until this was many and not all ... separate module maybe is the correct way.

[eLBati]

I'm not sure on fiscal_data module, because this filed are in many cases mandatory for the italian low .. but until this was many and not all ... separate module maybe is the correct way

What do you suggest?

PS: I don't think a growing number of modules is a bad thing.

[dcorio]

even though just for fun, i started to work on this, months ago:
https://github.com/dcorio/l10n-italy/tree/7.0-indicepa/l10n_it_indicepa

the idea was to create a module to manage all the stuff needed to integrate PA services.

i also created this:
https://github.com/dcorio/l10n-italy/tree/7.0-opendata/l10n_it_opendata.

Not saying this is the way, but i think that too many inherited views on critical models like res.partner could slow down the system.
This is why i'm not in favor of trillions of small modules.

Anyway, right now we suffer for a lack of features, then it's fine to have this as a stand-alone module.

[eLBati]

REA data: #100