[Erp5-dev] Proposal of improvement for reference handling in Organisation

[Jean-Paul Smets]

Hi,

The form Organisation_viewDetails (wrong naming BTW, should be
Organisation_viewDetail), displays different values related to the
company. Some values such as the registration code or the birth date are
definitely singleton values. Others may not be: VAT registration code
(there can be more than one), social code, etc.

The idea in the original design was that a single company may have
different offices. Each office should be represented in ERP5 as an
Organisation instance. This is fine and is enough to handle for example
multiple social registration codes (ie. 1 per office). Based on this
idea, we thought that VAT registration code is only one per company.

However, we found this not always to be the case. Some companies which
are doing export need in certain cases to register to foreign tax
authorities and obtain a VAT code in each country they operate in
(without subsidiary in that country). This is for example the case with
e-commerce between US and EU.

To handle this, I am thinking of 2 ways to improve the current design:

1- Create a generic code contact information portal type which works
in the same way as phone, address, email, etc. This means that the
couple ("code type", "code value") is stored in subobjects of
Organisation. In the case of VAT, it would be ('vat_code',
'FR3847483836'). Compatibility with current implementation would be
provided through adequate propertysheet definition. By adding some
predicate behaviour to the generic code subbject, "automatic selection"
feature would become also possible in order to guess for example which
code to use for VAT in which case (ex. if we ship to country C and the
client has a local VAT code then use our local VAT else use the one we
obtained in that country if any....). This approach is quite
straightforward. It is only a bit boring to configure because we have to
add codes one by one for each case.

2- Create a generic reference matrix which can be configured in a
similar way as we do with codes in products with variations (ex. EAN13
for each color, size of cloth). For example, the VAT reference matrix
could define a value for a combination of region X activities (ie. the
VAT code depends on where we sell and to which kind of client).
Compatibility with current implementation is a bit harder to get because
the reference is stored here in a subobject of a subobject rather than
in a subobject as in case 1.

Unless someone tells me this is wrong, I think we will go towards 1- and
reuse the same code, classes and types as the ones which are used in
Products to define product codes, but without the matrix. The main
reason for me is that I see no "natural variation dimensions" in
Organisation. However, if someone finds that there are natural variation
dimensons in Organisation which are not covered by creating multiple
Organisations (which is the right way in most cases in ERP5), then I
could think about 2-.

Regards,

JPS.

PS. If a company has 2 offices, create 2 organisations, not 2 addresses
in the same organisation.

[Rafael Monnerat]

I'm not sure if this are coincidence or not, but I was already thinking
about propose the changes that you describe in "1".

For me categories can be used for code classification like:

- social_code:
- br
- pis
- pasep
- fr
- x
- y
..

or:

l10n (not a good name for a root)
- fr
- social_code
- x
- vat_registration_code
- z
- br
- social_code
- pis
- pasep
- vat_registration_code
- cnpj

....

Configured throw person or organization using a localization category,
this makes easy to define with code classifications or label title will
be showed when the organization or person will be inserted.

It's also possible define at preferences with localization category is
the default one for all site or for some person.


Rafael Monnerat

Post by Jean-Paul Smets
Hi,
The form Organisation_viewDetails (wrong naming BTW, should be
Organisation_viewDetail), displays different values related to the
company. Some values such as the registration code or the birth date are
definitely singleton values. Others may not be: VAT registration code
(there can be more than one), social code, etc.
The idea in the original design was that a single company may have
different offices. Each office should be represented in ERP5 as an
Organisation instance. This is fine and is enough to handle for example
multiple social registration codes (ie. 1 per office). Based on this
idea, we thought that VAT registration code is only one per company.
However, we found this not always to be the case. Some companies which
are doing export need in certain cases to register to foreign tax
authorities and obtain a VAT code in each country they operate in
(without subsidiary in that country). This is for example the case with
e-commerce between US and EU.
1- Create a generic code contact information portal type which works
in the same way as phone, address, email, etc. This means that the
couple ("code type", "code value") is stored in subobjects of
Organisation. In the case of VAT, it would be ('vat_code',
'FR3847483836'). Compatibility with current implementation would be
provided through adequate propertysheet definition. By adding some
predicate behaviour to the generic code subbject, "automatic selection"
feature would become also possible in order to guess for example which
code to use for VAT in which case (ex. if we ship to country C and the
client has a local VAT code then use our local VAT else use the one we
obtained in that country if any....). This approach is quite
straightforward. It is only a bit boring to configure because we have to
add codes one by one for each case.
2- Create a generic reference matrix which can be configured in a
similar way as we do with codes in products with variations (ex. EAN13
for each color, size of cloth). For example, the VAT reference matrix
could define a value for a combination of region X activities (ie. the
VAT code depends on where we sell and to which kind of client).
Compatibility with current implementation is a bit harder to get because
the reference is stored here in a subobject of a subobject rather than
in a subobject as in case 1.
Unless someone tells me this is wrong, I think we will go towards 1- and
reuse the same code, classes and types as the ones which are used in
Products to define product codes, but without the matrix. The main
reason for me is that I see no "natural variation dimensions" in
Organisation. However, if someone finds that there are natural variation
dimensons in Organisation which are not covered by creating multiple
Organisations (which is the right way in most cases in ERP5), then I
could think about 2-.
Regards,
JPS.
PS. If a company has 2 offices, create 2 organisations, not 2 addresses
in the same organisation.

[bartek]

Post by Jean-Paul Smets
Hi,
The form Organisation_viewDetails (wrong naming BTW, should be
Organisation_viewDetail), displays different values related to the
company. Some values such as the registration code or the birth date are
definitely singleton values. Others may not be: VAT registration code
(there can be more than one), social code, etc.
The idea in the original design was that a single company may have
different offices. Each office should be represented in ERP5 as an
Organisation instance. This is fine and is enough to handle for example
multiple social registration codes (ie. 1 per office). Based on this
idea, we thought that VAT registration code is only one per company.
However, we found this not always to be the case. Some companies which
are doing export need in certain cases to register to foreign tax
authorities and obtain a VAT code in each country they operate in
(without subsidiary in that country). This is for example the case with
e-commerce between US and EU.
1- Create a generic code contact information portal type which works
in the same way as phone, address, email, etc. This means that the
couple ("code type", "code value") is stored in subobjects of
Organisation. In the case of VAT, it would be ('vat_code',
'FR3847483836'). Compatibility with current implementation would be
provided through adequate propertysheet definition. By adding some
predicate behaviour to the generic code subbject, "automatic selection"
feature would become also possible in order to guess for example which
code to use for VAT in which case (ex. if we ship to country C and the
client has a local VAT code then use our local VAT else use the one we
obtained in that country if any....). This approach is quite
straightforward. It is only a bit boring to configure because we have to
add codes one by one for each case.
2- Create a generic reference matrix which can be configured in a
similar way as we do with codes in products with variations (ex. EAN13
for each color, size of cloth). For example, the VAT reference matrix
could define a value for a combination of region X activities (ie. the
VAT code depends on where we sell and to which kind of client).
Compatibility with current implementation is a bit harder to get because
the reference is stored here in a subobject of a subobject rather than
in a subobject as in case 1.
Unless someone tells me this is wrong, I think we will go towards 1- and
reuse the same code, classes and types as the ones which are used in
Products to define product codes, but without the matrix. The main
reason for me is that I see no "natural variation dimensions" in
Organisation. However, if someone finds that there are natural variation
dimensons in Organisation which are not covered by creating multiple
Organisations (which is the right way in most cases in ERP5), then I
could think about 2-.

This new feature for sure will improve address handling too, in case
when an Organisation has multiple addresses for various purposes - for
example we have only one office, but the company is registered
elsewhere, so we have an "official" address which should be printed on
invoices, and "real" addres which should be printed on letterheads. Same
can happen for phone numbers and anything else. I think predicates would
be a good solution for this - I don't know if "purpose" is a "natural
variation dimension" or not.

Bartek

Post by Jean-Paul Smets
Regards,
JPS.
PS. If a company has 2 offices, create 2 organisations, not 2 addresses
in the same organisation.